Dev - OFBIZ Committers' Roles and Responsibilities
Locked
12
12
 
|
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 |
Re: Dev - OFBIZ Committers' Roles and Responsibilities
|
|
Excellent! I like the proposed nomination process - it seems fair.
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 |
Re: Dev - OFBIZ Committers' Roles and Responsibilities
|
|
In reply to this post by Si Chen-2
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 |
|
|
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 |
|
|
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 |
|
|
In reply to this post by Si Chen-2
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 |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
In reply to this post by Si Chen-2
On 6/23/06, Si Chen <[hidden email]> wrote:
> No other comments? So everybody agrees with this? They look like good guidelines to me, and in terms of the incubation process, it's good to see that you guys generated them yourselves. The process isn't supposed to be about 'do things this way', so I'd say good job all around. -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
In reply to this post by Si Chen-2
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 |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
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 2) follow the project's coding and formatting conventions (we should create a separate Wiki page for these) 3) always try to follow the project's best practices (we should reference to a separate document for these) 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 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; 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 > |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
Administrator
|
+1
Jacques > 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 > > 2) follow the project's coding and formatting conventions (we should > create a separate Wiki page for these) > > 3) always try to follow the project's best practices (we should > reference to a separate document for these) > > 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 > > 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; > > 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 > > |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
Hi to all the committers,
also if I'm not a committers of OFBIZ I would like to suggest also one more rule: a committers will apply patch about UI only if it's i18n compliance. I have revisioned all the OFBIZ applications to be translatable in different languages and it took to me about 4 months (not dedicated) to perform it. I can say also it is more difficult in term of time and know-how to change an application that has hard-coded labels than do it when the application was created. So I think it's better to not accept or change a patch that is not i18n than commit it and change when someone wants to do it. I think also if we want that OFBIZ become more visible it must be compliance to internazionalization. There are only my opinion that you can follow or not. Thanks to all and have a great weekend Marco Risaliti ----- Original Message ----- From: "Jacques Le Roux" <[hidden email]> To: <[hidden email]> Sent: Saturday, June 24, 2006 3:46 PM Subject: Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities > +1 > > Jacques > > >> 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 >> >> 2) follow the project's coding and formatting conventions (we should >> create a separate Wiki page for these) >> >> 3) always try to follow the project's best practices (we should >> reference to a separate document for these) >> >> 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 >> >> 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; >> >> 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 >> > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.394 / Virus Database: 268.9.2/370 - Release Date: 20/06/06 > > |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
Marco Libero wrote: > Hi to all the committers, > > also if I'm not a committers of OFBIZ I would like to suggest also one > more rule: > > a committers will apply patch about UI only if it's i18n compliance. It's a nice thought, but this just isn't going to happen. I18n is a priority in OFBiz, but there are many other higher priorities. This also places a higher burden on committers, who typically are not experiencing such an abundance of time and money that they are looking for whatever they can to work on... > I have revisioned all the OFBIZ applications to be translatable in > different languages and it took to me about 4 months (not dedicated) to > perform it. > I can say also it is more difficult in term of time and know-how to > change an application that has hard-coded labels than do it when the > application was created. From my (limited) experience, this isn't true. It's easier to review code and move the text into labels. It does depend on the artifacts being created, but for the most part i18n is done after the initial implementation is done anyway. > So I think it's better to not accept or change a patch that is not i18n > than commit it and change when someone wants to do it. > > I think also if we want that OFBIZ become more visible it must be > compliance to internazionalization. Visibility and adoption is a 2-way street in a community driven project. We do want more adoption, but mostly more adoption from people like you who can and want to help with things! -David |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
In reply to this post by Jacopo Cappellato
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 >> > |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
David, Si, all,
I've started to gather information about coding/formatting standards in a new Wiki page: http://docs.ofbiz.org/display/OFBIZ/Coding+Conventions At the moment it is only a draft; any help is much appreciated. For example it would be nice to add, under the "Entity Definitions" paragraph, information about the maximum length of entity/entity names/fk, naming conventions about fk etc... I've noticed that Si has already created a Wiki page about committers' roles: http://docs.ofbiz.org/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities Si, could you please review my notes and integrate them into that page? Thanks, Jacopo 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 >>> >> > |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
Any objections to putting this in the admin space (OFBADMIN) instead of the wiki space (OFBIZ)? We want anyone to be able to read and comment on it, but anything that is approaching the domain of policy should not be publicly edit-able... Si and Jacopo you both have permissions to edit in that space. -David Jacopo Cappellato wrote: > David, Si, all, > > I've started to gather information about coding/formatting standards in > a new Wiki page: > > http://docs.ofbiz.org/display/OFBIZ/Coding+Conventions > > At the moment it is only a draft; any help is much appreciated. > For example it would be nice to add, under the "Entity Definitions" > paragraph, information about the maximum length of entity/entity > names/fk, naming conventions about fk etc... > > I've noticed that Si has already created a Wiki page about committers' > roles: > > http://docs.ofbiz.org/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities > > > Si, could you please review my notes and integrate them into that page? > > Thanks, > > Jacopo > > > > 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 >>>> >>> >> > |
|
|
In reply to this post by David E. Jones
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 >>> |
|
|
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 >>>> > |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
In reply to this post by Si Chen-2
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 |
Re: [OFBiz] Dev - OFBIZ Committers' Roles and Responsibilities
|
|
In reply to this post by Si Chen-2
Hola,
> 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. +1. There are two other reasons for having patches submitted via the issue tracker (best option) or the public mailing list (not as good an option as the issue tracker, but still better than private email to committers): 1. A publicly-documented submission relieves us of the need to seek an iCLA from that individual, and 2. It reduces the burden on individual committers. If committer X was involved with OFBiz for a while and then doesn't have time for it for whatever reason, we don't want committer X to have to receive OFBiz emails, nor do we want committer X to be a bottleneck in forwarding patches / ideas / emails to the mailing list(s). Yoav |
|
|
In reply to this post by Jacopo Cappellato
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 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |