@Flole - What is your vision for TVH?
@Flole - How can we, the user/developer community, help you achieve that vision?
That being said: What follows is my, admittedly unsolicited, opinion. No offense is meant, none will be taken.
Step 1 - Perform a risk assessment.
What are the risks if TVH continues along its current path?
Are these risks acceptable?
I think that the project risks being forked off by other parties who what to fix some bugs or add some features. This could eventually end up with multiple and potentially incompatible versions of TVH floating around.
There may be other risks too.
Step 2 - Start a project and give it a name.
It could be v4.3.0, or it could be a code name, it does not really matter as long as we are all talking about the same thing.
Step 3 - Communications
* Create a forum section to discuss this, and only this, topic.
* Create a Wiki page to keep track of common data and centralised progress pertaining to the project.
Step 4 - Assess the current situation.
* Extract a list of merged PRs since that last stable release from GitHub.
* Match the PRs to bugs/issues recorded by TVH.
* Assign each change a category such as 'bug fix', 'enhancement' or 'new feature'.
* Determine which sub-system the change affects (DVB, EPG, API, etc).
* If the change impacts the WebUI, what translations have been done or are required.
This will give the project team an indication of the potential scope of the project as well as the areas of expertise that may be required.
Step 5 - Risk assessment (again) and Prioritisation
I may be slightly naïve, however, I see pretty much the only risk as being 'System Instability'.
For each change identified above, assess the likelihood that it will cause system instability and the impact that the instability will have on the average user. This will help provide an estimate of the testing effort required.
If the audit has shown a huge backlog, perhaps each change can be prioritised 'low', 'medium' and 'high' in terms of importance to the release.
Step 6 - Testing / Translating
Depending on the risk assessment and prioritisation above plus the state of the translations, changes can be prioritised and testing can commence.
I know that when I make changes, I test that feature on my system and do a quick sanity check, but I do not do exhaustive regression testing. I would appreciate at least one other person testing my code prior to release.
Also, if there are other forks in the wild: When was the fork made? How stable are these forks? How many of the identified 'changes' have been incorporated? We may be able to reduce some testing overhead by assessing how changes have performed on other forks.
With the translations: If we can not enlist the help of any appropriate native speakers, I have had success with online translations in the past. I use two independent services and perform a round-trip check. System 1 English -> Foreign -> System 2 Foreign -> English. If the English that comes back is 'close enough' then it is probably safe-ish to use.
Step 7 - Release
Make an official release. Perhaps it could be labelled 'Beta' as a safety precaution.
<<
