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

Reply via email to