On Jun 27, 2006, at 12:30 PM, David E. Jones wrote:
Right up at the top of the "Edit" tab for a page there is a drop- down to change the "Space" that the page is in. I'll do this for the R&R page you created.-David Si Chen wrote:Also, David - I didn't see how I could move this to OFBIZ Administration Workspace. Si On Jun 27, 2006, at 9:47 AM, Si Chen wrote:Hi David, Jacopo -I think a lot of this actually belongs to a "best practices guide" for contributors which I'll try to get a start on later today.I do believe we'd be better if patches are submitted via JIRA than directly to the committers, so they could be viewed by all (including non-committers) and also in case one of us is out, the project is not held up. However, I didn't put this in because it doesn't seem like we have a consensus on it yet.So I've updated the page:http://docs.ofbiz.org/display/OFBIZ/OFBiz+Committers+Roles+and +ResponsibilitiesA 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) theJira id to which the patch was attached; contributions should beexplicitly donated by the author to the project and so the best way toreceive them is thru Jira; committers should not committ patches received by them thru a private channelLegally 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 shouldcreate 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.htmlThese 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 itand always add the ASL2.0 header to new source filesYeah, 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 OFBizSubversion client configuration file 6) each commit's log should be meaningful and descriptive 7) it’s very important to commit related changes together in asingle 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.-DavidJacopo 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 firstpass 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 ofit is that it happens on an invitation basis from one or moreexisting committers, and then the PPMC would vote on it if thatperson 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 morecommitters, 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 communityworks 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 aresponsibility 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 ona certain effort but you can't finish it in the time you haveavailable, 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 wherethe 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 objectionsrespect it and find a compromise that works for everyone.To become a committer, you should be highly familiar with OFBiz andshould 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 newcontributions 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, wewould need to address those first. ---We did not discuss any formal processes earlier, but I'm thinkingperhaps 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 andcommunity members to see if any of the committers have "left theproject" and if any new developers should be invited to join? Si _______________________________________________ Dev mailing list [EMAIL PROTECTED] http://lists.ofbiz.org/mailman/listinfo/dev_______________________________________________ Dev mailing list [EMAIL PROTECTED] http://lists.ofbiz.org/mailman/listinfo/dev_______________________________________________ Dev mailing list [EMAIL PROTECTED] http://lists.ofbiz.org/mailman/listinfo/dev_______________________________________________ Dev mailing list [EMAIL PROTECTED] http://lists.ofbiz.org/mailman/listinfo/dev
