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 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 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 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 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 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 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 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 youwant 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 besensitive to areas where you are not familiar with the code and checkwith 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 orreview 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 consensusof 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 thinking perhaps the following: 1. To become a committer, to write one of the existing commiters to be nominated. Then the nomination will be forwarded to the ofbiz- ppmc, discussed and voted upon there. 2. Should the PPMC do an annual review of the committers and community members to see if any of the committers have "left the project" and if any new developers should be invited to join? Si _______________________________________________ Dev mailing list [EMAIL PROTECTED] http://lists.ofbiz.org/mailman/listinfo/dev_______________________________________________ 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
