Hi everybody.
As the project has grown in the last two years, we have more
committers, so we thought it might be nice to have something which
described more "formally" what the committers do and how one becomes
a committer of the project. This is a preliminary list, based on an
email David wrote to the PPMC and some added comments from others,
with my own modifications:
----
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.
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.
---
We did not discuss any formal processes earlier, but I'm thinking
perhaps the following:
1. To become a committer, to write one of the existing commiters to
be nominated. Then the nomination will be forwarded to the ofbiz-
ppmc, discussed and voted upon there.
2. Should the PPMC do an annual review of the committers and
community members to see if any of the committers have "left the
project" and if any new developers should be invited to join?
Si
_______________________________________________
Dev mailing list
[EMAIL PROTECTED]
http://lists.ofbiz.org/mailman/listinfo/dev
