community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: What are the basic, invariant rules of Apache projects?
Date Fri, 21 May 2010 14:48:58 GMT
On 21/05/2010 15:36, Michael McCandless wrote:
> I'd love to see some of the more "cultural" aspects of The Apache Way
> somehow spelled out.  For example things like:

I'd hate to see the excellent stuff in here go to waste in our mail 

I think these items have a different objective to that of Bertrands 
post. For me Bertrands proposal is short, snappy descriptions of the 
*rules*. What Michael has here is more like the justification for these 

I agree with Shane, we should post stuff to the foundation blog. 
Michael, perhaps you would like to follow up Bertrands proposed post 
with some of this content. Perhaps organised under the broad themes 
Shane suggests.

I've made a few comments inline...

> Health of the community is top priority.  Protect/nurture/grow it at
> all costs.  A good chunk of a committer's time should be spent trying
> to grow the community.  EG, when you see a new person post a neat
> idea, a patch, whatever, jump on it quickly, be exited, encourage
> them, since they are "new".  Likewise you have to defend the community
> if a poisonous person shows up.  You also have to do ongoing
> "education" / preaching of the Apache Way, so new members learn&
> spread the word.
> Consensus from the community is a fragile thing and is hard to reach
> for big/bold changes.  Many ideas will temporarily stall/die (from
> thread fatigue) because consensus could not be reached.  This is
> normal!  It is still progress -- people's positions will have
> softened/changed; the next time the topic comes up again (and it
> will), the discussion will be different.
> For smaller issues, lazy consensus still counts as consensus.
> After community is the health of the source code.  Source code is
> always alive... it needs constant care, pruning, refactoring, etc.
> "Progress not perfection": if the patch improves things, commit it.
> Don't be too picky; it can be further improved/iterated over time.
> Design for today / take baby steps.
> After that are the individuals: people come and go with time.  A
> project should never become "singular" (rely too much on any one
> person or any one "sponsor").  Names are not attached to code ("your
> ideas will go further if you don't insist on going with them").
> People don't "own" any part of the code.  If a new person shows up
> with new ideas, let them run free. While there are always strong egos
> here, decisions must still be made for technical reasons, never by ego.
> Finally, after that are the generous sponsors that allow us all to be
> here.  Sure we can focus on the things that are important to each of
> our sponsors, but never to the net detriment of the project.

Probably reiterating Shanes observation about neutrality here. Sponsors 
do not buy influence they just enable us to exist.

> Email is a dangerously poor medium for collaboration.  Never attribute
> to malice that which can be explained by something else, eg a language
> barrier, simple misconception, etc.  No question is stupid!
> Beware the vocal minority.
> Things fall through the cracks all the time.  We all get way too much
> email.  If an idea / issue / patch didn't get a response, gently bump
> it, even if you weren't the one who sent the email.  Gentle
> persistence / nagging is vital.
> A healthy project should in fact have raging debates/disagreements
> ("if two people always agree, one of them isn't needed").  But these
> debates must be about the objective technical tradeoffs of the idea,
> never devolving into personal attacks or "email rage", etc. -- step in
> to protect the community if it does.
> Beggars can't be choosers!  We committers are the beggars; there are
> never enough people to review patches/commit/etc, so when any
> idea/contribution comes alone, welcome it with open arms, and be
> responsive.  Yonik's law ("A half-baked patch with no documentation,
> no tests and no backwards compatibility is better than no patch at
> all.") applies.
> Patches should not languish: a patch arrives, it gets a critique
> "please fix XYZ and here's why", or, it gets committed.
> I imagine some of these will be contentious :)  And I'm sure I left many
> important things off...

I don't see anything contentious, I'm sure we could create more if we 
worked at it.

Great stuff!


> Mike
> On Fri, May 21, 2010 at 9:30 AM, Ross Gardler<>  wrote:
>> 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:
>> Description of a meritocratic governance model:
>> 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!

TransferSummit/UK - Open Innovation, Development, Collaboration
Oxford 24-25 June 2010 - Register now!

View raw message