Vote on change to repository governance

Michelle D'Souza michelle.dsouza at utoronto.ca
Tue Jun 16 12:47:26 UTC 2009


+1

I find it a lot easier to review smaller commits and this will allow  
new contributors to work in that way.

Michelle

On 15-Jun-09, at 10:48 PM, Colin Clark wrote:

> Hello again,
>
> We've had a week or so to ponder this proposal, so now seems like a  
> good time to call a formal vote on it.
>
> As a reminder, Fluid votes on major governance, architectural, and  
> design issues using a process directly inspired by the Apache voting  
> process. Here's a refresher:
>
> http://wiki.fluidproject.org/display/fluid/Voting
> http://apache.org/foundation/voting.html
>
> In short, we vote +1 to support a proposal, and -1 if we have  
> objections. For formal votes, -1s are an automatic veto, but they  
> also imply a commitment to get involved and refine the proposal to a  
> point where it will be accepted.
>
> Respond on list to this thread to cast your vote. We'll leave the  
> voting open until Friday to give people time to think about it and  
> respond.
>
> Colin
>
> On 5-Jun-09, at 3:38 PM, Colin Clark wrote:
>
>> Hi everyone,
>>
>> It's exciting to see the Fluid community growing, with a number of  
>> new prospective committers getting involved. After talking with a  
>> number of community members about how we organize and govern our  
>> source code repository, I'd like to propose a change to our approach.
>>
>> New members of the community are starting to explore deliverables  
>> that will be on the critical path for our Engage project as well as  
>> the Infusion product. At the moment, prospective committers are not  
>> given any commit access to the repository until they've gone  
>> through a process of submitting patches and earning the respect of  
>> the community. Overall, this process works well to ensure the  
>> quality of our code.
>>
>> On the other hand, we want to foster increased collaboration and  
>> make newcomers feel welcome, giving them space to play even before  
>> they've earned committer status. To this end, I'd like to propose  
>> splitting our source code repository into three separate areas:
>>
>> 1. A space for our current, shipping products. This area will be  
>> fully governed by all the familiar coding and commit standards used  
>> so far to ensure quality in Fluid releases. Prospective committers  
>> will be nominated and voted on for access to this space as usual.
>>
>> http://wiki.fluidproject.org/display/fluid/Process+for+Granting+Commit+Access
>> http://wiki.fluidproject.org/display/fluid/Coding+and+Commit 
>> +Standards
>>
>> 2. A space for incubated projects. This is a place for growing code  
>> that we expect to some day include in our releases. Anyone can ask  
>> for commit access to this space, and will be paired with a current  
>> committer as a mentor. Code reviews will be a requisite part of  
>> the  incubation process, and we'll expect a growing standard of  
>> quality over time.
>>
>> 3. A scratch pad space. This area will provide anyone with a space  
>> to experiment and sketch in code. It is assumed that work here will  
>> either be entirely experimental or will be promoted to another  
>> space as soon as it has taken reasonable shape. No release  
>> deliverables should be worked on here.
>>
>> Comments, suggestions, and refinements are much appreciated. After  
>> we've all had a chance to think about it and talk it through, I  
>> hope we can put it to a formal vote sometime next week.
>>
>> Colin
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

------------------------------------------------------
Michelle D'Souza
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto