...
- Follow coding conventions. Make sure that your files do not have tabs where they should have spaces.
- Install the OFBIZ Subversion client configuration file
- 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 would 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.
- 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.
- 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 Do I Become a Committer Myself?
If you're interested in becoming a committer, that's great! We would love to have you and the whole community will really appreciate your help.
Being a committer can be a great help to your employer and/or clients. It can also be a great asset in your personal and career growth. There is a guarantee that in the course of your activities you will learn and grow. You'll learn about building enterprise applications, both the technical and business sides of them. You'll also learn a lot about working with other people, especially working with other people remotely.
For more information and to get started see the Committers Roles and Responsibilities page.
How to Send in Your Contributions
...
if you only want to make a patch file of the entity/ sub-directory and the ShipmentServices.xml file.
For consistency, please make your patch files from the OFBIZ_HOME directory (usually ofbiz/) and with relative file paths. Your patch file should have file names like:
applications/party/widget/partymgr/PartyScreens.xml
framework/webtools/config/WebtoolsErrorUiLabels.properties
and should not have file names like:
...