Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4BF68B05.4080705@apache.org>
Date: Fri, 21 May 2010 14:30:45 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB;
 rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: dev@community.apache.org
Subject: Re: What are the basic, invariant rules of Apache projects?
References: <AANLkTimfZ4ow4oEOF9A88TuZhjdrDF1pW3lBUf_VJ7Nt@mail.gmail.com>
In-Reply-To: <AANLkTimfZ4ow4oEOF9A88TuZhjdrDF1pW3lBUf_VJ7Nt@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Bertrand,

I don't want to get into painting the bikeshed this excellent proposal 
gets posted in. Anywhere is good.

I think it's a great idea.

I'd encourage a comdev blog but I'm not sure we have the momentum to 
keep it alive at this point. However, I will do what I can when I can to 
help move things along.

I think any level of visibility for these issues is good. The wider the 
better.

I agree we need to make sure that the summary presented here is inline 
with other documentation.

I think we (comdev) should consider taking collective ownership of ASF 
wide documentation about how we work. I've always wanted to create a 
"template" website for ASF projects which has all this stuff clearly 
described in it. Projects could then take the template and adapt it to 
their specific needs.

There are some external resources that could be leveraged here:

Why governance models are important and what they are:
http://www.oss-watch.ac.uk/resources/governanceModels.xml

Description of a meritocratic governance model:
http://www.oss-watch.ac.uk/resources/meritocraticGovernanceModel.xml

I also have an evaluation technique that measures the openness of a 
project. At present it is very generic and deals with all aspects of 
openness and freedom, but it could adapt it to provide a self evaluation 
tool for committers to evaluate how they think a project operates.

I think that is a huge job and its about documentation, so not too 
exciting and arguably not that useful. The production of endless 
documentation does not increase levels of education.

I think this is a great mentored project for a student (and yes, I think 
I may have a route to finding a candidate - more on this when things 
solidify in 2-4 weeks)

In the meantime +1 on Bertrands proposed post as is.

Ross

On 21/05/2010 09:55, Bertrand Delacretaz wrote:
> Hi,
>
> I'd like to write a blog post (on the foundation blog, or might be a
> good opportunity to start the comdev blog) about the basic rules of
> Apache projects.
>
> Trying to keep it as short as possible, with links to more info.
>
> Feedback/corrections/additions are welcome - I will invite our PMCs
> and members to this thread to try and get a nice
> bikeshedding^H^H^H^H^H^H consensus.
>
> -Bertrand
>
>
>
> DRAFT: What are the basic, invariant rules of Apache projects?
>
> The below rules and best practices aim to make ASF projects
> sustainable and open to new community members, and to make sure source
> code is released in a legally clean way.
>
> Projects enter the ASF via the Incubator, anyone can suggest a new
> project as described on the Incubator website.
>
> Each project is led by its elected Project Management Committee (PMC).
>
> New committers and PMC members are elected by the PMC based on merit.
>
> Committers and PMC members are not necessarily ASF members, they have
> to be elected separately for that (LINK).
>
> Each project has at least one private and one public (development,
> "dev") mailing list which are the only official communication channels
> for the PMC members and committers.
>
> Discussions and decisions about people (such as the above elections)
> usually happen on the project's private list, but that's not a hard
> rule, the PMC can decide.
>
> All other decisions happen on the dev list, discussions on the private
> list are kept to a minimum.
>
> "If it didn't happen on the dev list, it didn't happen" - which leads
> to two sub-rules:
>
> a) Elections of committers and PMC members are published on the dev
> list once finalized.
>
> b) Out-of-band discussions (IRC etc.) are summarized on the dev list
> as soon as they have impact on the project, code or community.
>
> All decisions are made by consensus, following the ASF's voting rules (LINK).
>
> ASF releases consist of source code, binaries are provided as a
> convenience only (LINK).
>
> Release artifacts are created according to the ASF's release rules (LINK).
>
> A formal PMC vote is required to publish a release.
>
> Each PMC reports to the board of directors, at least every three
> months, mentioning progress, problems and perspectives in terms of
> community, releases, code and compliance with the above rules.
>
> Trademarks and logos used by ASF projects belong to the ASF.
>
> That being said: have fun at the ASF, and commit early, commit often,
> and let everything happen in the open.
>
> (this is just a draft to kickoff the discussion...)


-- 
TransferSummit/UK - Open Innovation, Development, Collaboration
Oxford 24-25 June 2010 - Register now! http://www.transfersummit.com