Well, first of all I want to thanks all people contributing code, money and other efforts to Haiku. It’s a great Os to use, and a great project to work with.
Yes, we have some problems with getting newcomers involved. Our workflow is clearly suboptimal. But, Maxim, I spent hours on IRC explaining you why we ended up doing things this way, and I still believe the resons are valid:
We had problems with berlios, our previous code hosting service, and we don’t want this to happen again. Had we chosen to continue using a 3rd-party forge at the time, we would probably have gone with Google Code Project Hosting. By now, that’s mostly a dead-end and we would have to migrate to github again. In a few years, github will lose momentum and maybe we’ll have to go with something else. On the other hand, providing our own server is the safer and most future proof solution.
We explained you over IRC that no, you DON’T need to attach your patch to Trac. You can commit your work on a github branch, and put a link to that on Trac. This way, we can work with people that use github (we even have a mirror of our code there), but also with people not using it, and hosting their own git repo, or using bitbucket, or gitorious, or nothing at all and sending patches. If you’re not willing to listen to something as simple as this (and you endup ragequitting IRC or something), there’s no way anyone is going to take you seriously.
It still seems very unclear to you how the project works: Haiku, Inc. has absolutely no decision power over Haiku. The only thing they can do is pay the bills, and decide wether they want to hire coders to get some code written. So far, no one outside of the developers already having commit access asked for a contract, but should that happen, they could consider it as well. On the project side, there is a known list of people which are considered part of the project. These get commit access, and a vote right when a decision is needed (the votes happen publicly, on the haiku-development mailing list). One thing we vote for is allowing more people to enter the project. We have very high quality standards, maybe too high, because this list of people is what defines the so-called “Haiku way”. This is made of things like coding style guidelines, attitude towards problem solving (don’t hide the bug, hunt it and squash it), and the general idea of what the system should look like. You seem to understand at least part of this, as you have worked hard to make Haiku Chat match the guidelines and some of the Haiku Way.
As this team of developers get bigger, there are a few unwanted consequences. From the outside, it looks like things are really slow. When you ask them something, it may require a lot of discussion to try to get everyone to agree. If that doesn’t work, we resort to a vote. Then we get the results back to you. The process at Haiku, Inc. is similar. You have to also remember (almost) all these people are working on their free time, and in different timezones, making communication even more difficult.
Finally, we currently don’t really have someone in charge of the website. The situation on this side is really unclear, and yes, this is something we should improve. We have heard your complaints, and I don’t think the general answer was initially “we don’t care”, but more like “we know there’s a problem, but either we don’t have a solution yet, or we have designed one, but didn’t get it running”. We considered using Gerrit as a way to review and approve patches, for example. This would be a very good tool given our workflow, allowing the people with commit access to review patches there, add comments, and approve or reject them. This works well in other projects and has a good integration with git, making it easy to work with. Yet, we don’t have people with enough free time and competences to set this up, and it’s been on the TODO list for months.
Instead of getting angry at how wrong we’re doing things, one way you can contribute is halping with some of these non-development tasks. Editing content for the website is a way to do that. Answering posts on this forum is another. People even became part of the project like this, for example Diver does an excellent work of reviewing tickets, testing apps and finding many bugs, and doing mockups of how the UI could be improved. This is very appreciated by everyone and he is now a project member, including commit access even if he uses that very rarely.
So, the first step in being part of the project is to learn how to interact with others, and try to understand why things are the way they are, and try to improve them yourself where you can. That’s the best you can do if you still want to help Haiku.
