Yes, re-reading my words I can see it might be read as "get consensus" I agree with Sylvain. My intention was that 1) and 3) happen in quick succession. Proceed with the assumption that no objection will be raised. If one is raised we have a wonderful time machine (subversion) to resolve the issue.
Sent from my mobile device. On 25 Mar 2011, at 18:37, Sylvain Wallez <[email protected]> wrote: > Le 25/03/11 17:32, Ross Gardler a écrit : >> On 25/03/2011 15:07, Scott Wilson wrote: >>> >>> On 25 Mar 2011, at 14:48, Franklin, Matthew B. wrote: > [...] >>>> 4. Discuss working agreements for coding practices, quality, unit >>>> testing, coverage, CI, sandbox environments, etc (Some of this is >>>> probably standard Apache practice) >>> >>> I don't think there is such a thing as a standard Apache coding >>> practice :-) >> >> Scott is correct. There is no "standard" but there are a whole bunch of >> common practices that you'll find here. I'm not sure how the other >> mentors plan to tackle this issue. My own style is to let you get on >> with it and pipe up if I believe either a) something is potentially >> harmful to an ASF project or b) there is a way to do something that I >> believe will help. > > Well, I personally have two important rules : > - use spaces for indentation and not tabs > - choose a consistent coding standard that nobody is strongly against (which > is very different from "everybody agrees on") and stick with it. > > That's it :-) > >> For your mentors to do this effectively you need to discuss everything >> here on the list. I don't think there will be much of a problem with >> that in these team. >> >>>> 7. Agree on process for "cherry picking" features and >>>> integrating them into the Rave code base >>> >>> Well, we can pick things we want to work on and mail the list to say >>> we're doing it, but beyond that I don't think we can have that much >>> of a process - anyone can implement any features they want and submit >>> patches for them, its up to committers whether to commit them. >> >> Yes, this is probably the best approach. >> >> 1) say I'm going to work on getting feature X implemented I know how the >> code in foo does that so I'm going to use that as a starting point. This >> means I will implement it like this [pseudo code/UML/whatever] >> >> 2) community sits back and lets it happen or shouts "no - bar does it better >> because.." >> >> 3) regular, frequent and early commits to give people chance to sound a word >> of caution early >> >> One of the approaches I like in some of our projects is for someone to post >> a "Random Thought". This is a very early stage proposal for a solution. The >> fact that it is a Random Thought means that people know it is not supposed >> to be fully thought out and so constructive criticism and enhancements are >> welcome. >> >> These are posed to the list with [RT] in the subject and will typically >> define a use case, a problem preventing the use case from being carried out >> today, a rough idea that will satisfy the use case, a rough proposal for how >> it might be implemented >> >> Often such an RT can start the above 1-2-3 cycle going. > > You can also ready a blog post I wrote long ago about "I-will-do-it-o-cracy" > that discusses how informing that you _will_ do something before actually > doing it keeps the community rolling by allowing people to voice their > opinion before too much work has been done, which can lead both to technical > problems (reverts, etc) and more harmfully community problems : > http://bluxte.net/musings/2005/03/21/meritocracy-doocracy-and-iwilldoitocracy > > Note that this is a bit different from trying to constantly seek consensus > and agreement, which can lead a projet to stall. > > Sylvain > > -- > Sylvain Wallez - http://bluxte.net >
