All:
We have been really surprised at the growth and adoption of Eclipse Che. We are now getting >10K downloads per week and there are projects happening at many major companies. This week Red Hat has declared the project a strategic platform, and we anticipate more vendors making this sort of announcement soon.
Since this project was initiated by Codenvy and then transitioned into an Eclipse project, there are still some lingering elements of the process that are not done entirely in a transparent way. We anticipate having an addtional 20 committers on the project by the end of the year most of those people working in companies all around the world.
So, we have to double down on making sure we govern the project in the open with a process that is well documented and consumable by anyone.
We have documented the following items that need to be altered for us to get to this level of transparency.
1. Codenvy will be hiring a product manager dedicated to release manage of Eclipse Che. They will ensure that we execute a clean open source project process around our releases, issue management, sprint planning, milestone planning, and the so forth.
2. We will be moving Codenvy team sprint definitions, which span Eclipse Che + Codenvy issues into the open. We will be executing our first sprints and the Eclipse Che 4.6 milestone entirely in the open. We just made the 4.4 milestone today, so this will be the release after 4.5 which is primarily a bug fix release. We hope that by August, all issues, sprints, and milestones are documented entirley on Github.com/eclipse/che.
3. This requires, in turn, for us to mine any remaining issues that are on Codenvy's internal systems and get them migrated into GitHub. We have been doing this opportunistically as user requests come in, but now it must be a systematic migration. We will ensure that all issues for any Codenvy-team sprints and the 4.6+ milestones have all issues documented on GitHub well in advance of the issues.
4. We will be experimenting with some tools that layer onto GitHub issues to help with sprint planning, epic management, and agile management.
5. We will be updating the CUSTOMIZING.md and SUPPORT.md to have much more clarity on the processes followed. Part of this will include refining the lables being used on GitHub with clear definitions of what each label is intended for. We will also provide GitHub issue templates to standardize all issues on a common reporting format. We will reject any user-support, enhancement, or development issue that is not formatted against the template. All issues for a new major release must be documented against the template with an appropriately detailed specification attached to it.
FWIW, we do document our milestone plans and weekly meetings today in the GitHub wiki. But what hasn't been documented are the issues that many engineers in Codenvy are working on for Che. Those issues are in our Jira and we have to do a forced migration.
Separately, we are moving towards a release planning model where each upcoming release is driven by the pull requests / epics that are ready for merging into master. So the definition of what actually goes into a release will be a function of what is ready to merge, rather than any particular customer-driven objective. Teams and outside contributors can work in their own sprint methodology on major features and when those features have been issued as a pull request, then they will be eligible for inclusion into a particular milestone.
![]() | Tyler Jewell | CEO | tyler@codenvy.com | 978.884.5355 |
