- It begins - trying to make changes to Flock by lilmatt
- The secret life of a thunderbird patch by cwright
To be able to make changes to an Open Source project, it takes a really long time and a lot of proper communication.
In these two posts, one of them talks about what to have in mind to get people to review your patches and the other post talks about how long it took that person to get reviewed his patch for Thunderbird, that all it did was to add "Add to BCC" button but it took much longer that expected.
Once Dave talked about somebody who wrote a book talking about a world in which people would not use money but something like "credit" (I can't recall the proper word), which was how much credit you have earned by helping others, but the problem in here for Mozilla what is the right way to measure contributing to the community? What does stop someone to contirbute easily?
We know that there are celebrities inside the community that have helped a lot and they have the possibility to commit changes to the tree.
We also have in the community collaborators that might not have committing privileges but they still know who to go to, to get their patches reviewed and they get it done because they know how to promote it.
I can speak about my own experience; I do not know who is who in the localization part of the Mozilla community and how they work and who is working on what.
The person who helped us the most was Axel (the module owner) and he probably has way too much to worry than having to deal with a minor project like ours.
If you look at "Bug 399014 – we need an l10n-merge tool", it took 17 days to receive any feedback and then it seemed that we posted on the wrong bug :(
There is another reference I want to make to one of the FSOSS lectures (usability lecture by Jay Goldman and David Crow) and they were suggesting that the best bugs to fix are the ones that have more value for your customers/users. I believe that not having the "Add to BCC" button was not worrying about what it is important for the users rather than knowing that their application runs a little bit faster (in some situations) because there have been some performance bugs fixed or that they have spent more time adding new features that most of the users won't appreciate except those that are developers, because most of the bugs fixed are the ones that insiders or developers want to be fixed rather than regular users.
Please feel free to add your comment in favor or opposing to see the bigger picture
No comments:
Post a Comment