Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

The committers of OFBiz are a core group of developers who have the ability to commit changes into the OFBiz source code repository. As the project has grown over the years, there have been more committers of projects, so we thought it be a good idea to define what the roles and responsibilities of the committers are. These points below are based on discussions we recently had on the developers' list:

General Responsibilities of Committers

OFBiz is a community driven project, and the point of a community-driven project is to build software that would work in a large variety of situations with a large group of other other people. Therefore, it is really important than the project is written in a way which would benefit many potential users, and that the community works together towards that goal.

This is especially important for the commiters of the project to remember, since they would be making decisions not just for your own organization or your own clients, but for all current and future users of OFBiz as well. Thus, commit privileges carry with them a responsibility for "the greater good" of the project.

Nothing should be committed that breaks existing functionality just to make something easier for a particular client or customization effort. This means, in particular, that if some progress is made on a certain effort but you can't finish it in the time you have available, then don't commit it if it breaks anything that was there, just keep it local or attach it to a Jira issue or something if you want others to be able to get involved (or just it to the point where the stuff it broke works again, then commit it.)

To avoid code ownership, anyone can work on anything, but please be sensitive to areas where you are not familiar with the code and check with others who have worked in the area before doing something. A good practice is to ask someone who is more familiar with something to review it before you commit it, and if they have objections respect it and find a compromise that works for everyone.

Becoming a Committer

To become a committer, you should be highly familiar with OFBiz and should already have had a significant number of contributions accepted into the project.

Committers should be actively involved in contributing new code or review patches from the community. If someone has stopped making new contributions for a while, we should find out why.

Committers should be nominated by another committer and should be accepted by all the other committers without serious objection. In other words, not just a majority of other committers but a consensus of all the other committers. I'm not saying that we must always like everything somebody has done, but if there are serious objections, we would need to address those first.

Committing Changes

When committing changes, all committers should follow these general guidelines:

  1. Committers should set up their SVN client to use the official OFBIZ Subversion client configuration file
  2. Committers should review contributions to ensure that they follow good coding standards, are well-commented and understandable, and follow our coding conventions
  3. Committers should write a meaningful description of the feature being committed in the commit log so other developers and committers could understand what is happening.

In addition, all committers must do the following to ensure licensing compliance:

  1. Make sure the contribution is posted publicly on the Apache OFBIZ JIRA issue tracker. Please do not commit changes that were sent to you privately. If you receive a patch, open a JIRA issue and then ask the submitter to post his patch there. This way, we can avoid having to get an iCLA for the contributor, as well as let everybody in the community view and comment on the contribution.
  2. If it is a new file, the file must have the Apache 2.0 license header.
  3. The commit log must identify the name of the contributor and, if relevant, the JIRA issue for it.
  • No labels