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