Re: best practices for contributors
Posted by
Si Chen-2 on
Jun 27, 2006; 8:26pm
URL: http://ofbiz.116.s1.nabble.com/best-practices-for-contributors-tp168876p168885.html
Yeah, you're right. This actually is very important.
Also I was thinking of adding Marco Risalti's suggestion about
internationalizing code in here. While I don't think we should make
it a requirement that contributions should be internationalized, we
should suggest that everybody do it as much as possible.
Ok, I'll work on creating this page later on docs.ofbiz.org
Si
On Jun 27, 2006, at 12:12 PM, David E. Jones wrote:
>
> As general feedback on this: it would also be nice to have a
> distinction in the document between committers and contributors,
> and to make it clear that you do not need commit privileges or
> special privileges in any system in order to contribute, and that
> if you want to become a committer then start by working on various
> contributions. This is something I've thought about writing a
> number of times given various random questions from people who want
> to contribute to the project and are therefore requesting commit
> privileges and what not.
>
> -David
>
>
> Si Chen wrote:
>> Ok, so as a follow up to the write up of guidelines for
>> committers, I thought we should have some guildelines for
>> contributors as well to help them work with the project.
>> 1. Send in a signed ICLA to Apache.
>> 2. Follow coding conventions.
>> 3. Install the OFBIZ Subversion client configuration file (where
>> is this?)
>> 4. Discuss your features with the community. What are you trying
>> to implement, and how are you planning to do it? This is
>> especially important if you are new to the project.
>> 5. Write clear, well-commented and understandable code. Don't
>> take shortcuts, especially around variable names and error or
>> warning messages. Use understandable data structures. Remember,
>> somebody else will be working with your code down the road.
>> 6. Start out with small contributions which are easier to
>> review. In the process, get familiar with the project's coding
>> style and "thought process."
>> 7. Put your contributions on JIRA instead of emailing it directly
>> to the committers, so everybody can review and comment on it.
>> 8. Get other members of the community to try your patch. Write
>> the users list and tell them what you've done and ask them to try
>> it out and vote for it. This would help the committers when they
>> are reviewing your patches.
>> Si