You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Si Chen <si...@opensourcestrategies.com> on 2006/06/23 18:14:11 UTC

Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities

On Jun 20, 2006, at 10:16 AM, Si Chen wrote:

> You're right.  I think that's actually how most projects do it.
>
>
> On Jun 19, 2006, at 7:10 PM, David E. Jones wrote:
>
>>
>> Si,
>>
>> This looks pretty good and the body of the text is fine for a first
>> pass in my opinion, with just a few editorial fixes perhaps.
>>
>> For the new committer guidelines this isn't quite the process that
>> is generally followed. Usually committer privileges are given on an
>> invitation only basis. If someone is clearly getting involved a lot
>> with the project and helping with issues and submitting lots of
>> patches that look good, then the invitation to be a committer is
>> pretty natural. If someone asks for commit privileges we should
>> certainly consider the request, but the more natural progression of
>> it is that it happens on an invitation basis from one or more
>> existing committers, and then the PPMC would vote on it if that
>> person is interested and accepts the offer. That's way it has
>> worked in that past anyway...
>>
>> -David
>>
>>
>> Si Chen wrote:
>>> 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
>>> Dev@lists.ofbiz.org
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>> _______________________________________________
>> Dev mailing list
>> Dev@lists.ofbiz.org
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
> _______________________________________________
> Dev mailing list
> Dev@lists.ofbiz.org
> http://lists.ofbiz.org/mailman/listinfo/dev