Vote on change to repository governance

[Justin]

+ 1

Something that I should probably have mentioned during the suggestion  
phase, but I don't think really has any impact on the voting, would be  
to create at least one additional mailing list for commits. This will  
help filter commits against trunk and those in the sketchpad.

- Justin
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