Some days ago, Matt started a thread on haiku-inc mailing list about solving the problem of patches stacking up in trac. We are also talking about 'moving away from subversion'. I spent some time thinking about all of this and I think I changed my mind about it. So I'll try to explain and analyze the problems and get some ideas of possible solutions.
The problem we are trying to solve is gaining more 'core' contributors. This is a good thing for obvious reasons : Haiku is still a really small project with less than 50 committers, and less than half of them being really active, this leads to development time longer than it should be, low 'bus factor', and people having to handle too much parts of the system. However, aving more contributors can also be a bad thing, with some of the concerns I heard in past discussions : * Granting access to people that can't keep the code quality as good as it is * Granting commit access is the same as granting 'project member' status with vote right
This has two drawbacks : it makes getting commit access a big step in the process, giving you the right to mess with any part of the sourcecode but also a voice in every decision making progress. Commit access means a lot of power for each newcomer. As long as the team keeps small, this power is important. With 100 devs voting important decisions, one more wouldn't make the outcome of a vote change, but with 20 active devs or less, it is an important balance change. There is no trial period whatsoever, one day you are a patch maker as any other and in one operation you become a full project member with a full voice in every decision. This is exciting, but sometimes people don't feel ready for it. I know sometimes I don't, with all the build breakages and other problems I introduced into Haiku, I still feel like I'm hacking around in the code rather than actually designing it.
I'm currently working on another project in a research lab at scool and they gave me the 'junior developper' status. What this exactly does means should be defined according to our workflow, but I believe the idea of introducing a new status, something between 'patch submitter' and 'core project member', is a good move. It means we have to make the project management slightly more complicated, but this time we can't get around it without changing the workflow, anyway. I'm going to list the things that should/could be changed, with possible solutions if I have some.
* Commit access != Vote right : people could get commit access without getting the right to take parts into votes. This could be used for contractors from outside the project, that could take part into the development work for a thing they are paid on, without necessarily connecting to the Haiku community. This never hapenned before as Haiku, inc chose to pay only people that were core contributors. But I believe it could work, also for people coming/getting paid from elsewhere. The problem with this is we need to answer a question : who gets vote rights ?
* Moving away from trunk : all of the development of Haiku is done in svn trunk. This allows everyone to get the latest changes, but it means there is no such thing as a stable version. we ar enot backporting fixes into the alpha branches nor making them move on ; instead we create a new branch from trunk at each alpha. This means some unfinished things can easily get included in the alpha releases and could be in the R1 too if we keep doing it that way. It also means we have to keep the very high code quality standards in the trunk. at a first glance it is a good thing : who would want badly designed and written code ? The problem is the code gets written anyway, in the form of patches that land on trac and never get committed. We would like people to improve their patches, but they just want the bug to get fixed. They already tried to help us by submitting their hack, it is up to us to clean it up and make it really work. What we need her eis some kind of 'playground area' or sandbox where people can put their patches, I believe svn trunk would be a good place for that, with the core committers working on porting these fixes to the stable branch. When an alpha version is released, the next one should be branched seconds after, and the integration of features from trunk should start there. The 'commit review' process would be more painful, but we could trust the whole 'core commiter' team to do it. The problem is it is boring work and not everyone would like to do it. The current team may prove too small already to keep up with all the patches and proposal that would land in the now more open trunk. Moving away from subversion could be a way to improve things in this area.
* More formal mentoring : there are two types of patch committers : people that want to become commiters, and people that just hacked things up to get them work and decided to release their patches in the hope it would get useful for someone else. We have no way of differenciating these patches in trac. This is important because 'hackers' will not fix the coding style issues or anything else, they expect commiters to make the patch work properly themselves ; while the wanabe commiters would like hints on how they can improve their work. Adding a field to request review on a patch on trac would be a solution, but compilcates the process of submitting a patch (less checkboxes makes less confusion). Assigning a mentor to people that request it would be another possibility.
* Keeping track of patch submitters : if someone submits patches in different areas, these patches may be reviewed by different people. We are not keeping track of the work done, so none of the reviewer may see that there was a lot of other good patches done before and it is time for commit access allowance. The process, viewed from te outside, also sounds a bit random and arbitrary. Keep submitting your work and hope someone will grant you commit access. A small tool to keep track of patches submitted by someone with a status for each patch (applied without any changes, commiter made some fixes, was reworked by patcher after review process, commiter had to do an almost full rewrite) would help score patchers and see when it's time for commit access. The bigger the team grows, the more useful this will be.
* Looking out of the code : writing code is not the only way people can contribute to Haiku. Designing flyers and other graphical work, writing scripts, working on the websites and online tools, moderating the IRC channel or the forums, writing documentation and other articles, triaging tickets in trac are tasks that could be granted to people not knowing C++. Some of these tasks could also grant you a vote right. Writing docs currently needs commit access. trac tickets need the appropriate permissions. They could all be granted on a process similar to the one we are using for commit access : submit patches, write helpful message in trac or the forum, help people and try to stay on topic on irc, ... should be watched for and turned into real rights. Some of these could also be paid work.
* Throwing money in : Haiku,inc. is handling the money, but is tightly tied to the project. Currently most of the money goes to funding events and contracts for committers. Bounties would be a good way to get more people involved : the money is not actually given to anyone unless the bounty is completed, but a perfectly unknown coder coming out of nowhere can fulfill a bounty and get the money, then hopefully become a contributor. It would be possible to make bounties with the only payment being a commit access, maybe ?
* Keeping some low hanging fruits for newcomers : easy tickets get fixed so fast by the most active commiters that newcomers get no chance to look at them. Maybe we should refrain from fixing these and mark them as easy to help people getting started with Haiku. This means these bug may be left open for a longer time, however.
Ok, I think that's all for today. Feel free to comment on them or add new ones.
-- Adrien.
