Dev - OFBIZ Committers' Roles and Responsibilities

[Jacopo Cappellato]

Exactly: all the iCLAs that we have gathered are needed because of the
license change.

Jacopo

Si Chen wrote:

> Ok, fixed link to the config.
>
> About #1 - what should it say?  Do we no longer need icla's once the
> files have Apache headers?
>
> Si
>
>
> On Jun 27, 2006, at 10:00 AM, Jacopo Cappellato wrote:
>
>> Hi Si,
>>
>> Si Chen wrote:
>>> A couple of questions:
>>> 1.  Where is the Subversion client file?
>>
>> http://svn.ofbiz.org/svn/ofbiz/trunk/website/svn/config
>>
>>> 2.  Is what I have under "licensing compliance" good?  Should we
>>> clarify major vs. minor contribution?
>>
>> About #1: this is not necessary if the modified files are under the ASL.
>>
>> Jacopo
>
>

[David E. Jones]

Right up at the top of the "Edit" tab for a page there is a drop-down to change the "Space" that the page is in. I'll do this for the R&R page you created.

-David


Si Chen wrote:

> Also, David -
>
> I didn't see how I could move this to OFBIZ Administration Workspace.
>
> Si
>
> On Jun 27, 2006, at 9:47 AM, Si Chen wrote:
>
>> Hi David, Jacopo -
>>
>> I think a lot of this actually belongs to a "best practices guide" for
>> contributors which I'll try to get a start on later today.
>>
>> I do believe we'd be better if patches are submitted via JIRA than
>> directly to the committers, so they could be viewed by all (including
>> non-committers) and also in case one of us is out, the project is not
>> held up.  However, I didn't put this in because it doesn't seem like
>> we have a consensus on it yet.
>>
>> So I've updated the page:
>> http://docs.ofbiz.org/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities 
>>
>>
>> A couple of questions:
>> 1.  Where is the Subversion client file?
>> 2.  Is what I have under "licensing compliance" good?  Should we
>> clarify major vs. minor contribution?
>>
>> Si
>>
>> On Jun 24, 2006, at 9:31 AM, David E. Jones wrote:
>>
>>>
>>>
>>> Jacopo Cappellato wrote:
>>>> Hi,
>>>> what about adding a few more rules about committing best practices?
>>>> Something like:
>>>> 1) when committing a patch contributed by another person, always put a
>>>> comment in the commit log with the name of the person and (possibly)
>>>> the
>>>> Jira id to which the patch was attached; contributions should be
>>>> explicitly donated by the author to the project and so the best way to
>>>> receive them is thru Jira; committers should not committ patches
>>>> received by them thru a private channel
>>>
>>> Legally the patch falls under the Apache license because it is a
>>> change to a file with an ASL2 header, or a new file that is
>>> contributed with such a header. The little question on the Jira
>>> server is nice, but only means so much.
>>>
>>> In other words, it is what is in the patch and what it is being
>>> applied to that is more important than how it gets to a committer.
>>>
>>>> 2) follow the project's coding and formatting conventions (we should
>>>> create a separate Wiki page for these)
>>>
>>> Yeah, this would be nice... Basically the sun standard conventions
>>> are the ones we go with, as listed here:
>>>
>>> http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
>>>
>>> These have been around for a while and are stable and well thought out.
>>>
>>>> 3) always try to follow the project's best practices (we should
>>>> reference to a separate document for these)
>>>
>>> This would be the Best Practices Guide, which could use some feedback
>>> and probably some updating. This is yet another preemptive
>>> documentation attempt that seems to not actually have much demand....
>>>
>>>> 4) before a commit make sure that there are no license issues with it
>>>> and always add the ASL2.0 header to new source files
>>>
>>> Yeah, related to #1, this is very critical, and in fact required. New
>>> files without this will be rejected (or should be rejected...).
>>>
>>>> 5) committers should setup their svn client to use the official OFBiz
>>>> Subversion client configuration file
>>>> 6) each commit's log should be meaningful and descriptive
>>>> 7) it’s very important to commit related changes together in a
>>>> single revision (if a single logical change is spread over several
>>>> commits, it becomes more difficult to revert the change and also
>>>> more difficult to track which files the change touched); each commit
>>>> should represent an indipendent logical unit; for example, when
>>>> possible, try to commit separately a bug fix and a new feature;
>>>> formatting changes should be kept separated from functional changes;
>>>
>>> Sounds good.
>>>
>>> So how do we get this party started? Si: do you want to post your
>>> stuff in the admin space on docs.ofbiz.org and then Jacopo can change
>>> it? Or, Jacopo: feel free to throw this stuff in along with Si's or
>>> whatever. I guess it doesn't matter. Like most things someone just
>>> has to find a place to put stuff and then put it there.
>>>
>>> -David
>>>
>>>
>>>
>>>> Jacopo
>>>> David E. Jones wrote:
>>>>>
>>>>> I think this is certainly good enough to put on docs.ofbiz.org, and
>>>>> you should have permissions to write in the admin section (if you
>>>>> don't let me know and I'll hook you up).
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> Si Chen wrote:
>>>>>> No other comments?  So everybody agrees with this?
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>>> _______________________________________________
>>>>>>>> Dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Dev mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>
>>>>>>  _______________________________________________
>>>>>> Dev mailing list
>>>>>> [hidden email]
>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>
>>
>

[Si Chen-2]

I see it!  It's the little yellow "EDIT" button after you click on  
the "Edit" tab.  Ok, I'll remember it for next time.

On Jun 27, 2006, at 12:30 PM, David E. Jones wrote:

>
> Right up at the top of the "Edit" tab for a page there is a drop-
> down to change the "Space" that the page is in. I'll do this for  
> the R&R page you created.
>
> -David
>
>
> Si Chen wrote:
>> Also, David -
>> I didn't see how I could move this to OFBIZ Administration Workspace.
>> Si
>> On Jun 27, 2006, at 9:47 AM, Si Chen wrote:
>>> Hi David, Jacopo -
>>>
>>> I think a lot of this actually belongs to a "best practices  
>>> guide" for contributors which I'll try to get a start on later  
>>> today.
>>>
>>> I do believe we'd be better if patches are submitted via JIRA  
>>> than directly to the committers, so they could be viewed by all  
>>> (including non-committers) and also in case one of us is out, the  
>>> project is not held up.  However, I didn't put this in because it  
>>> doesn't seem like we have a consensus on it yet.
>>>
>>> So I've updated the page:
>>> http://docs.ofbiz.org/display/OFBIZ/OFBiz+Committers+Roles+and 
>>> +Responsibilities
>>>
>>> A couple of questions:
>>> 1.  Where is the Subversion client file?
>>> 2.  Is what I have under "licensing compliance" good?  Should we  
>>> clarify major vs. minor contribution?
>>>
>>> Si
>>>
>>> On Jun 24, 2006, at 9:31 AM, David E. Jones wrote:
>>>
>>>>
>>>>
>>>> Jacopo Cappellato wrote:
>>>>> Hi,
>>>>> what about adding a few more rules about committing best  
>>>>> practices?
>>>>> Something like:
>>>>> 1) when committing a patch contributed by another person,  
>>>>> always put a
>>>>> comment in the commit log with the name of the person and  
>>>>> (possibly) the
>>>>> Jira id to which the patch was attached; contributions should be
>>>>> explicitly donated by the author to the project and so the best  
>>>>> way to
>>>>> receive them is thru Jira; committers should not committ patches
>>>>> received by them thru a private channel
>>>>
>>>> Legally the patch falls under the Apache license because it is a  
>>>> change to a file with an ASL2 header, or a new file that is  
>>>> contributed with such a header. The little question on the Jira  
>>>> server is nice, but only means so much.
>>>>
>>>> In other words, it is what is in the patch and what it is being  
>>>> applied to that is more important than how it gets to a committer.
>>>>
>>>>> 2) follow the project's coding and formatting conventions (we  
>>>>> should
>>>>> create a separate Wiki page for these)
>>>>
>>>> Yeah, this would be nice... Basically the sun standard  
>>>> conventions are the ones we go with, as listed here:
>>>>
>>>> http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
>>>>
>>>> These have been around for a while and are stable and well  
>>>> thought out.
>>>>
>>>>> 3) always try to follow the project's best practices (we should
>>>>> reference to a separate document for these)
>>>>
>>>> This would be the Best Practices Guide, which could use some  
>>>> feedback and probably some updating. This is yet another  
>>>> preemptive documentation attempt that seems to not actually have  
>>>> much demand....
>>>>
>>>>> 4) before a commit make sure that there are no license issues  
>>>>> with it
>>>>> and always add the ASL2.0 header to new source files
>>>>
>>>> Yeah, related to #1, this is very critical, and in fact  
>>>> required. New files without this will be rejected (or should be  
>>>> rejected...).
>>>>
>>>>> 5) committers should setup their svn client to use the official  
>>>>> OFBiz
>>>>> Subversion client configuration file
>>>>> 6) each commit's log should be meaningful and descriptive
>>>>> 7) it’s very important to commit related changes together in a
>>>>> single revision (if a single logical change is spread over  
>>>>> several commits, it becomes more difficult to revert the change  
>>>>> and also more difficult to track which files the change  
>>>>> touched); each commit should represent an indipendent logical  
>>>>> unit; for example, when possible, try to commit separately a  
>>>>> bug fix and a new feature; formatting changes should be kept  
>>>>> separated from functional changes;
>>>>
>>>> Sounds good.
>>>>
>>>> So how do we get this party started? Si: do you want to post  
>>>> your stuff in the admin space on docs.ofbiz.org and then Jacopo  
>>>> can change it? Or, Jacopo: feel free to throw this stuff in  
>>>> along with Si's or whatever. I guess it doesn't matter. Like  
>>>> most things someone just has to find a place to put stuff and  
>>>> then put it there.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>> Jacopo
>>>>> David E. Jones wrote:
>>>>>>
>>>>>> I think this is certainly good enough to put on  
>>>>>> docs.ofbiz.org, and you should have permissions to write in  
>>>>>> the admin section (if you don't let me know and I'll hook you  
>>>>>> up).
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> Si Chen wrote:
>>>>>>> No other comments?  So everybody agrees with this?
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>>>> _______________________________________________
>>>>>>>>> Dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>> Dev mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>
>>>