...
The following guidelines are meant to help contributors work with the committers and the community as a whole:
| Tip |
|---|
|
- Follow coding conventions. Seriously, read that document.
- Install the OFBIZ Subversion client configuration file
- Follow the 2 main rules for committers:
- Rule #1 for a committer is the same as for a doctor: first do no harm. Nothing should be committed that breaks existing functionality without replacing it either before or in the same commit. Whatever you are working with someone developed it and chances are someone is using it, and possibly MANY people.
- Rule #2 for a committer is the same as for a scientist: read before you write. When you're getting started a good time ratio for read to write is around 20 to 1. Once you're a total OFBiz pro who knows as much as any living person about the project, you can probably reduce that to about 3 to 1.
- 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.
- 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.
- When you prepare a patch, do your best to avoid to mix formatting changes with relevant changes (if possible, provide a separate patch containing only formatting changes): in this way the reviewer's work will be easier
- When you prepare a patch, do not insert in the code comments with author information since your name will be recorded in the commit log (that is the place were we store this kind of information)
- Internationalize your code with UI labels.
- Start out with small contributions which are easier to review. In the process, get familiar with the project's coding style and "thought process."
- Keep patches and contributions easy to review and commit. Even if a lot of code is touched, try to keep things isolated and the intent of the patch(es) clear. Remember that most committers can find 20 minutes here and there, but it is very hard to fit in the 2-4 hour time block required to review and commit a larger patch (especially if it touches ANY lower level or more sensitive or complex artifacts, and this requires more thorough review).
- Put your contributions on JIRA instead of emailing it directly to the committers, so everybody can review and comment on it. Though it is not necessary this makes contributions more traceable for the licensing through the Apache Software Foundation.
- Get other members of the community to try your patch. Write the dev list and tell them what you've done and ask them to try it out and vote for it. This will help the committers when they are reviewing your patches as there will be more confidence that the patch does what it is intended to do, and doesn't break anything else.
|
If you are planning a larger contribution, please follow the following tips to facilitate both licensing and collaboration. These tips will make it easier for committers to review and incorporate your work, and will overall speed up your development process as you'll be asking the OFBiz team to do a number of small, simple tasks rather than a couple of large tasks that a committer will have to find significant time to review and commit.
| Note |
|---|
|
- Do not implement large blocks of artifacts (code, etc) on your own and then contribute them to OFBiz.
- If you have a large block of code to contribute we can work with you on that, but it requires a different review and legal vetting process than normal contributions, as described on http://incubator.apache.org/ip-clearance/index.html.
- When a method is deprecated, it should be explained which method should be used, and what has changed.
- Instead develop and contribute as you go. This means develop as you would normally, but interact with the OFBiz community through mailing lists and contribute patches regularly. # If you are do not have a committer on your team this can slow down development, so do what you can to "sell" one of the committers on your project and get an ally on the committing team to regularly review and commit your patches. Note that if you let us know in advance that you are planning a larger effort of this nature, we can perhaps find a volunteer beforehand to work with you on this.
- Just please remember that there is no paid staff on OFBiz, all are volunteers. You may see your patch sit in Jira for a long time while committers work on other things. This usually happens because a committer is working on a priority for the project that has been a problem for a while, or on a paid contract in order to survive and to be able to continue helping with OFBiz.
- It might be tempting to run your effort without getting an OFBiz committer involved, but keep in mind that committers can help you with technical, business, and legal concerns either on their own or through collaboration with others in the project on in the ASF more generally.
|
How to Send in Your Contributions (or how to create and apply patches)
...