Roadmap, goals and philosophy
2016-03-31
Transvision does not have a fixed release schedule like Firefox which is released every 6 weeks. However, between the reboot of the project on GitHub in July 2012 and the last version we put to production mid-March 2016, there were 36 releases in total. Which means a 5 weeks release cycle on average.
In this context, that means that any new feature or important change to Transvision can be included if it is ready in the next release and since we don't have a fixed release schedule, we can push a new release in a matter of days if we find a regression in our code or if we think that localizers or localization tools that consume our public API would benefit significantly from a new feature.
What determines a new release is a balance between these constraints:
- Are there new features that would benefit our user base and make a difference?
- Are there technical changes on Mozilla repositories side that mandate a release?
- Are we confident that we don't have any functional regression?
- Are we generally happy with the quality of the code base? Is it better than what it was in the previous version?
- Do we currently have time to make a release and potentially have to deal with any regression we introduce?
We try not to push any code that is not associated with a bug describing the issue we want to fix or the improvement we want to make, we use GitHub issues for that. At the time of writing this document, we have 23 issues opened and 286 issues fixed.
Issues are either filed by Transvision code contributors or by Transvision users that report a bug or request an improvement. 45% of issues opened were fixed within a day, 14% within a week, 19% within a month. The remaining 22% issues that took more than a month to be fixed are usually the complex features that require significant development time or that introduce UX challenges. That means that if you file an issue, there are very high chances that the fix will be in the next version just a few weeks later and that you will be able to test it on the beta site (https://transvision-beta.mozfr.org) in a question of days.
Our approach to the development of Transvision is inspired by the Extreme Programming agile software development methodology. We privilege short development cycles thanks to continuous integration and automated testing and simplicity of design so as to keep meet our goals of shipping features to users regularly while keeping a code base with as little technical debt as possible.
The simplicity of our code base also means that contributing to Transvision remains doable for amateur Web developers. A localizer with technical skills can participate in the development of Transvision. As a matter of fact, Transvision was created by Philippe Dessante, former French Firefox localizer and math teacher, and is mostly maintained today by Théo Chevalier, Francesco Lodolo and Pascal Chevrel, l10n-drivers and also localizers. Having this Translation Memory and Quality Assurance tool hackable by Mozilla localizers is by itself one of the goals of the project as they know best what Mozilla-specific day to day l10n issues Transvision could solve for them
Now that we have described roughly how we develop Transvision and the philosophy behind it, let's see what it means in terms of roadmap. As we mentioned above, we develop Transvision following an agile methodology based on frequent releases and a feedback loop with our users ("Release early. Release often. And listen to your customers" said Eric Raymond). We don't have features landing in a specific release planned in advance, like "feature X will be part of release 4.12". Features are part of a release when they meet the following criteria:
- The feature seems helpful even if initially unpolished
- The code quality is correct, there are unit and functional tests if needed
- We are confident we didn't introduce any functional regression in the application
Usually, new views get an experimental label at the top which usually means that the view is not feature complete or that we are not sure that the view will actually be popular. Unpopular views end up being eventually removed while popular ones get more love and loose their "experimental" label over time.
Some issues remain open for a very long time as they present some challenges we are not necessarily able to implement for a number of reasons, we could label them as "Future" if we were following a roadmap and a Waterfall model of development.
They are often the features that get summed up as "It would be really nice if…" but that are very hard to implement either because they are challenging at the technical level or, more commonly, because they are a User Experience headache and implementing the new feature would degrade the general user experience. This is often the reason why we create specialized views so as to not make the main interface too complex.
If you are reading this document and would like to get involved into the development of Transvision, please get in touch with the team on IRC (#transvision channel on irc.mozilla.org) 