rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@bluxte.net>
Subject Re: Next Steps
Date Fri, 25 Mar 2011 18:37:24 GMT
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


Mime
View raw message