Vote on change to repository governance
Jacob Farber
jacob.farber at utoronto.ca
Tue Jun 16 17:23:23 UTC 2009
+1
-----Original Message-----
From: fluid-work-bounces at fluidproject.org [mailto:fluid-work-bounces at fluidproject.org] On Behalf Of Colin Clark
Sent: Monday, June 15, 2009 10:49 PM
To: Colin Clark
Cc: fluid-work at fluidproject.org
Subject: Vote on change to repository governance
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