You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2010/05/21 10:55:50 UTC
What are the basic, invariant rules of Apache projects?
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...)
Re: What are the basic, invariant rules of Apache projects?
Posted by Nick Burch <ni...@apache.org>.
On Fri, 21 May 2010, Bertrand Delacretaz wrote:
> 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.
Looks promising to me. I've only a couple of points
> ASF releases consist of source code, binaries are provided as a
> convenience only (LINK).
I'd be tempted to say something different, since it's a contentious topic.
Maybe something like:
"ASF releases must include the source code, since we're an open source
foundation. Different projects place different weights on binaries to
accompany releases, and so many (but not all) projects will subject their
binary releases to the same degree of scrutiny as their sources"
> A formal PMC vote is required to publish a release.
May add the all-important reason for this:
"By voting to accept and bless the release, the PMC then makes the release
one of the foundation, rather than simply one by the release manager, thus
granting the foundation's protection to the release"
or something like that...
> 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.
I think this is a topic for another, 2nd blog post! I think it would be
helpful to review a few reports from past board reports, and highlight the
things that help the board, and the ones where the board needs to know
more. I've certainly had people on my pmc ask me why I've included things
in the report, especially things that highlight issues, and it'd be great
to be able to point them at a blog post with examples rather than having
to write an email from scratch!
Nick
Re: What are the basic, invariant rules of Apache projects?
Posted by Ross Gardler <rg...@apache.org>.
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
archives.
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
rules.
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!
Ross
>
> Mike
>
> On Fri, May 21, 2010 at 9:30 AM, Ross Gardler<rg...@apache.org> 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:
>> 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
>>
--
TransferSummit/UK - Open Innovation, Development, Collaboration
Oxford 24-25 June 2010 - Register now! http://www.transfersummit.com
Re: What are the basic, invariant rules of Apache projects?
Posted by Michael McCandless <lu...@mikemccandless.com>.
I'd love to see some of the more "cultural" aspects of The Apache Way
somehow spelled out. For example things like:
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.
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...
Mike
On Fri, May 21, 2010 at 9:30 AM, Ross Gardler <rg...@apache.org> 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:
> 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
>
Re: What are the basic, invariant rules of Apache projects?
Posted by Ross Gardler <rg...@apache.org>.
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
Re: What are the basic, invariant rules of Apache projects?
Posted by Ross Gardler <rg...@apache.org>.
On 24/05/2010 14:47, Bertrand Delacretaz wrote:
> On Mon, May 24, 2010 at 1:50 PM, Nick Burch<ni...@apache.org> wrote:
>> ...Will also let people know when I've written some more (mentoring, and who
>> drives a project are the two I've in mind), so we can decide if they're
>> worth going on the comdev blog too...
>
> Great, go for it!
+1
Ross
Re: What are the basic, invariant rules of Apache projects?
Posted by Nick Burch <ni...@apache.org>.
On Mon, 24 May 2010, Bertrand Delacretaz wrote:
> On Mon, May 24, 2010 at 1:50 PM, Nick Burch <ni...@apache.org> wrote:
>> ...Will also let people know when I've written some more (mentoring, and who
>> drives a project are the two I've in mind), so we can decide if they're
>> worth going on the comdev blog too...
>
> Great, go for it!
Annoyingly, I'm blocked at work pending a configuration decision, but
handily this has left me time to fix some POI bugs and write some more
blog posts :)
Who drives, directs and supports projects within the Apache Software
Foundation
http://gagravarr.livejournal.com/140745.html
Mentoring and Incubation at the Apache Software Foundation
http://gagravarr.livejournal.com/140928.html
As before, feedback appreciated! If people feel either of them are useful
enough for the comdev blog, then when that's up I can put them there as
drafts ready for tweaking and publishing
Nick
Re: What are the basic, invariant rules of Apache projects?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, May 24, 2010 at 1:50 PM, Nick Burch <ni...@apache.org> wrote:
> ...Will also let people know when I've written some more (mentoring, and who
> drives a project are the two I've in mind), so we can decide if they're
> worth going on the comdev blog too...
Great, go for it!
-Bertrand
Re: What are the basic, invariant rules of Apache projects?
Posted by Nick Burch <ni...@apache.org>.
On Mon, 24 May 2010, Bertrand Delacretaz wrote:
>> Why not just post it to the foundation (or comdev) blog? I'm sure we can
>> review it properly for you....
>
> I'd say comdev, as we seem to have some momentum to start this.
OK. I'll ask infra for a blog for comdev (we don't seem to have one), and
will then re-post it there
Will also let people know when I've written some more (mentoring, and who
drives a project are the two I've in mind), so we can decide if they're
worth going on the comdev blog too
Nick
Re: What are the basic, invariant rules of Apache projects?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, May 24, 2010 at 12:59 AM, Ross Gardler <rg...@apache.org> wrote:
> On 23/05/2010 16:24, Nick Burch wrote:
>> ...Inspired by your idea, I've sat down and written a blog post about the
>> CLAs and release votes, trying to cover the Why rather than the What:
>> http://gagravarr.livejournal.com/140493.html
>>
>> Corrections gratefully received, otherwise do feel free to pinch bits
>> for a foundation post if it looks useful :)
>
> Why not just post it to the foundation (or comdev) blog? I'm sure we can
> review it properly for you....
I'd say comdev, as we seem to have some momentum to start this.
-Bertrand (traveling this week, might take a few days to finalize my post)
Re: What are the basic, invariant rules of Apache projects?
Posted by Ross Gardler <rg...@apache.org>.
On 23/05/2010 16:24, Nick Burch wrote:
> On Fri, 21 May 2010, Bertrand Delacretaz wrote:
>> 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.
>
> Inspired by your idea, I've sat down and written a blog post about the
> CLAs and release votes, trying to cover the Why rather than the What:
> http://gagravarr.livejournal.com/140493.html
>
> Corrections gratefully received, otherwise do feel free to pinch bits
> for a foundation post if it looks useful :)
Why not just post it to the foundation (or comdev) blog? I'm sure we can
review it properly for you.
(I've skimmed it, it looks great)
Ross
Re: What are the basic, invariant rules of Apache projects?
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
Hi Nick;
Good and nice article that sums up the general concepts!
Thanks;
--Gurkan
________________________________
From: Nick Burch <ni...@apache.org>
To: dev <de...@community.apache.org>
Sent: Sun, May 23, 2010 6:24:01 PM
Subject: Re: What are the basic, invariant rules of Apache projects?
On Fri, 21 May 2010, Bertrand Delacretaz wrote:
> 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.
Inspired by your idea, I've sat down and written a blog post about the CLAs and release votes, trying to cover the Why rather than the What:
http://gagravarr.livejournal.com/140493.html
Corrections gratefully received, otherwise do feel free to pinch bits for a foundation post if it looks useful :)
I might try to do one on mentoring later, time permitting....
Nick
Re: What are the basic, invariant rules of Apache projects?
Posted by Nick Burch <ni...@apache.org>.
On Fri, 21 May 2010, Bertrand Delacretaz wrote:
> 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.
Inspired by your idea, I've sat down and written a blog post about the
CLAs and release votes, trying to cover the Why rather than the What:
http://gagravarr.livejournal.com/140493.html
Corrections gratefully received, otherwise do feel free to pinch bits for
a foundation post if it looks useful :)
I might try to do one on mentoring later, time permitting....
Nick
Re: What are the basic, invariant rules of Apache projects?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, May 31, 2010 at 1:43 PM, Benson Margulies <bi...@gmail.com> wrote:
> You might also cast a gander at the patch I added to INFRA-2715.
Ok - best might be to add a link to
http://www.apache.org/dev/release-publishing.html once your patch is
applied, maybe as an update to the blog post.
-Bertrand
Re: What are the basic, invariant rules of Apache projects?
Posted by Benson Margulies <bi...@gmail.com>.
You might also cast a gander at the patch I added to INFRA-2715.
On Mon, May 31, 2010 at 6:17 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi everybody,
>
> Thanks very much for all your comments and additions - here's my final
> draft for review.
> I plan to post it on Thursday as I'm offline tomorrow and Wednesday.
>
> I haven't taken all your suggestions into account, tried to keep the
> post short, and found a way to not speak about "rules" as this is
> really just information at this point.
>
> This thread seems to contain enough material for a few other comdev
> blog post, so don't by shy ;-)
>
> -Bertrand
>
> Final draft:
>
> DRAFT: What makes Apache projects different?
>
> Sharing a code repository with some other programmers might seem
> enough to create an open source project, but the Apache Software
> Foundation focuses on making projects sustainable in the long term,
> and ensuring that our code is legally clean.
>
> This means that our projects have to follow a (small) number of rules,
> and a number of best practices have been established over the years.
>
> Here's a quick description of how Apache projects are born and live on
> - some of the items below are derived from the ASF's bylaws
> (http://www.apache.org/foundation/bylaws.html), others are just best
> practices that evolved over time.
>
> Projects enter the ASF via the Incubator, anyone can suggest a new
> project as described on the Incubator website
> (http://incubator.apache.org).
>
> A Project Management Committee (PMC) oversees each project on behalf
> of its users, contributors, committers and the foundation itself.
>
> New committers and PMC members are elected by the PMC based on merit.
>
> Committers and PMC members are not necessarily ASF members, to be
> members they have to be elected separately (see "roles" in
> http://www.apache.org/foundation/how-it-works.html).
>
> 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 elections
> mentioned above) usually happen on the project's private list, but
> that's not a hard rule, each 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:
>
> 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.
>
> Where possible, decisions are made by consensus. The ASF has voting
> procedures that projects can use to determine whether consensus has
> been reached (http://www.apache.org/foundation/voting.html).
>
> Releases are created according to the ASF's release rules
> (http://www.apache.org/dev/release.html), and all released software
> uses the Apache License (http://www.apache.org/licenses/).
>
> A formal PMC vote is required to publish a release. By voting to
> accept the release, the PMC makes the release one of the foundation,
> rather than simply one of the release manager.
>
> Each PMC reports to the ASF's board of directors, usually quarterly.
> The PMC's report mentions progress made, and any problems encountered.
> Items of particular relevance to the board include community,
> releases, development work and compliance with the ASF's rules and
> best practices.
>
> Trademarks and logos used by ASF projects belong to the ASF.
>
> Don't hesitate to ask on the community development mailing list
> (http://community.apache.org/) if you have questions about this - and
> in the meantime, have fun at the ASF, commit early and communicate
> often!
>
Re: What are the basic, invariant rules of Apache projects?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, May 31, 2010 at 12:17 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> ...Thanks very much for all your comments and additions - here's my final
> draft for review....
Now online at https://blogs.apache.org/comdev/entry/what_makes_apache_projects_different
with minor tweaks.
-Bertrand
Re: What are the basic, invariant rules of Apache projects?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi everybody,
Thanks very much for all your comments and additions - here's my final
draft for review.
I plan to post it on Thursday as I'm offline tomorrow and Wednesday.
I haven't taken all your suggestions into account, tried to keep the
post short, and found a way to not speak about "rules" as this is
really just information at this point.
This thread seems to contain enough material for a few other comdev
blog post, so don't by shy ;-)
-Bertrand
Final draft:
DRAFT: What makes Apache projects different?
Sharing a code repository with some other programmers might seem
enough to create an open source project, but the Apache Software
Foundation focuses on making projects sustainable in the long term,
and ensuring that our code is legally clean.
This means that our projects have to follow a (small) number of rules,
and a number of best practices have been established over the years.
Here's a quick description of how Apache projects are born and live on
- some of the items below are derived from the ASF's bylaws
(http://www.apache.org/foundation/bylaws.html), others are just best
practices that evolved over time.
Projects enter the ASF via the Incubator, anyone can suggest a new
project as described on the Incubator website
(http://incubator.apache.org).
A Project Management Committee (PMC) oversees each project on behalf
of its users, contributors, committers and the foundation itself.
New committers and PMC members are elected by the PMC based on merit.
Committers and PMC members are not necessarily ASF members, to be
members they have to be elected separately (see "roles" in
http://www.apache.org/foundation/how-it-works.html).
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 elections
mentioned above) usually happen on the project's private list, but
that's not a hard rule, each 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:
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.
Where possible, decisions are made by consensus. The ASF has voting
procedures that projects can use to determine whether consensus has
been reached (http://www.apache.org/foundation/voting.html).
Releases are created according to the ASF's release rules
(http://www.apache.org/dev/release.html), and all released software
uses the Apache License (http://www.apache.org/licenses/).
A formal PMC vote is required to publish a release. By voting to
accept the release, the PMC makes the release one of the foundation,
rather than simply one of the release manager.
Each PMC reports to the ASF's board of directors, usually quarterly.
The PMC's report mentions progress made, and any problems encountered.
Items of particular relevance to the board include community,
releases, development work and compliance with the ASF's rules and
best practices.
Trademarks and logos used by ASF projects belong to the ASF.
Don't hesitate to ask on the community development mailing list
(http://community.apache.org/) if you have questions about this - and
in the meantime, have fun at the ASF, commit early and communicate
often!
Re: What are the basic, invariant rules of Apache projects?
Posted by Noirin Shirley <no...@apache.org>.
On Sat, May 29, 2010 at 5:24 PM, Ross Gardler <rg...@apache.org> wrote:
>
> "A Project Management Committee (PMC) oversees each project on behalf of its
> users, contributers, committers and the foundation itself."
s/contributers/contributors/, then perfect :-)
N
Re: What are the basic, invariant rules of Apache projects?
Posted by Ross Gardler <rg...@apache.org>.
On 29/05/2010 22:01, Noirin Shirley wrote:
> On Fri, May 21, 2010 at 4:55 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
...
>> Each project is led by its elected Project Management Committee (PMC).
>
> I think it's worth being a little clearer what's meant by "led" - or
> removing that word entirely. Otherwise it's easy to miss the "JFDI"
> side of things and get hung up on the corporate structure.
+1
> As a very simple edit, how about
> "A Project Management Committee (PMC) is appointed by the board of the
> ASF to oversee each project."
-1 this sounds like there is top down control. How about:
"A Project Management Committee (PMC) oversees each project on behalf of
its users, contributers, committers and the foundation itself."
Ross
Re: What are the basic, invariant rules of Apache projects?
Posted by Noirin Shirley <no...@apache.org>.
On Fri, May 21, 2010 at 4:55 AM, Bertrand Delacretaz
<bd...@apache.org> 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).
I think it's worth being a little clearer what's meant by "led" - or
removing that word entirely. Otherwise it's easy to miss the "JFDI"
side of things and get hung up on the corporate structure.
As a very simple edit, how about
"A Project Management Committee (PMC) is appointed by the board of the
ASF to oversee each project."
> 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).
This reads a little oddly to me - also, not all decisions are
consensus (I've often heard "you can't veto a release").
How about "Where possible, decisions are made by consensus. The ASF
has voting procedures that projects can use to determine whether
consensus has been reached:
http://www.apache.org/foundation/voting.html"
> ASF releases consist of source code, binaries are provided as a
> convenience only (LINK).
Someone else has edited this downthread, I think - anyway, I'm not
sure that this statement is entirely true or agreed upon?
> 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.
This seems like a complicated sentence... How about
"Each PMC reports to the board, usually quarterly. The PMC's report
should mention progress made, and any problems encountered. Items of
particular relevance to the board include community, releases,
development work and compliance with the rules above."
> 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.
Just a style thing, but I would rephrase as something like:
"However, the Apache Way is better learnt by joining in than by
reading a list of rules. Get involved, have fun! Commit early and
communicate often. And remember that if it's open, it's probably
Apache!"
That last bit might be a bit much, but I find "let everything happen
in the open" hard to swallow in a 101 post like this. It's a very good
rule of thumb for established folk, but it can be hugely problematic
for people coming here at first, and disproportionately off-putting to
minorities. If you want the full explanation, we should probably start
another thread, but
http://geekfeminism.org/2009/11/29/questioning-the-merit-of-meritocracy/
includes some of the reasons.
Noirin
Re: What are the basic, invariant rules of Apache projects?
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 5/21/2010 3:56 AM, Bertrand Delacretaz wrote:
> Hi Isabel,
>
> On Fri, May 21, 2010 at 12:33 PM, Isabel Drost<is...@apache.org> wrote:
>
>> On 21.05.2010 Bertrand Delacretaz wrote:
>>
>>> 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.
>>>
>>
Thank you Bertrand for doing this. One rule I would like to suggest and
maybe some would say it is too detailed is *Never* cross-post. If
multiple groups need your email, post to the most public appropriate
list and then send individual mails with a link to the other lists and
invite them to join or monitor the thread. I think this is the best way
to keep communication open and unfragmented.
Thanks
Kathey
Re: What are the basic, invariant rules of Apache projects?
Posted by jean-frederic clere <jf...@gmail.com>.
On 05/21/2010 02:06 PM, Bertrand Delacretaz wrote:
> On Fri, May 21, 2010 at 1:06 PM, Christian Grobmeier
> <gr...@gmail.com> wrote:
>> ...a blog post reflects the understanding of the authors as
>> you said. I think it would be good to have different authors on this
>> post ...
>
> That's why I'm posting my draft here, for collaborative editing. I
> have no problem signing the blog post with the names of whoever helps
> writing it.
Well collaborative editing = wiki or something like that.
>
> Judging the enthusiasm so far, I might also just post on my own blog.
> That can also be useful even if it's then only my own view on things.
blog = private view :D
Cheers
Jean-Frederic
Re: What are the basic, invariant rules of Apache projects?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Christian,
On Tue, May 25, 2010 at 1:42 PM, Christian Grobmeier
<gr...@gmail.com> wrote:
> Hi,
>
>>> ...a blog post reflects the understanding of the authors as
>>> you said. I think it would be good to have different authors on this
>>> post ...
>>
>> That's why I'm posting my draft here, for collaborative editing. I
>> have no problem signing the blog post with the names of whoever helps
>> writing it.
>>
>> Judging the enthusiasm so far, I might also just post on my own blog.
>> That can also be useful even if it's then only my own view on things.
>
> I think you got me wrong because i expressed badly. I didn't want to
> say that this is bad - I like the idea and I think its necessary to do
> things like this. What I meant was more, we need more posts of that
> kind, from various authors (various blog posts)....
Ok, agree with that - I did get you wrong indeed.
> ...Also I think that official resources should link to this blog article and others...
Yes, cross-linking will help.
>
> OK, just wanted to say clear: I like it...
Thanks!
-Bertrand
Re: What are the basic, invariant rules of Apache projects?
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi,
>> ...a blog post reflects the understanding of the authors as
>> you said. I think it would be good to have different authors on this
>> post ...
>
> That's why I'm posting my draft here, for collaborative editing. I
> have no problem signing the blog post with the names of whoever helps
> writing it.
>
> Judging the enthusiasm so far, I might also just post on my own blog.
> That can also be useful even if it's then only my own view on things.
I think you got me wrong because i expressed badly. I didn't want to
say that this is bad - I like the idea and I think its necessary to do
things like this. What I meant was more, we need more posts of that
kind, from various authors (various blog posts).
Also I think that official resources should link to this blog article and others
OK, just wanted to say clear: I like it.
Cheers
Christian
Re: What are the basic, invariant rules of Apache projects?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, May 21, 2010 at 1:06 PM, Christian Grobmeier
<gr...@gmail.com> wrote:
> ...a blog post reflects the understanding of the authors as
> you said. I think it would be good to have different authors on this
> post ...
That's why I'm posting my draft here, for collaborative editing. I
have no problem signing the blog post with the names of whoever helps
writing it.
Judging the enthusiasm so far, I might also just post on my own blog.
That can also be useful even if it's then only my own view on things.
-Bertrand
Re: What are the basic, invariant rules of Apache projects?
Posted by Christian Grobmeier <gr...@gmail.com>.
>> Another question would be to define what is the purpose of the project: Should
>> the reader take some kind of specific action (e.g. restructure the project he is
>> working on), should frequent questions concerning how software is developed at
>> Apache be answered (than the post should maybe not be just a blog post but
>> somehow integrated in the official documentation?)....
>
> My goal is mostly for volunteer Apache community members to discuss
> and agree on the list of "rules", and publish the results. No hidden
> agenda, just trying to start clarifying what we mean by "the Apache
> Way".
>
> To me the big advantage of a blog post is that it can safely rot - it
> only reflects the understanding of its authors as of today, as opposed
> to official documentation which is supposed to be the Final Truth (and
there are already several documents around which should describe the apache way:
http://incubator.apache.org/learn/theapacheway.html
http://www.apache.org/foundation/how-it-works.html
A blog post would of course increase the visibility of this topic, but
having offical documentation and blog posts which are possibly
conflicting each other might not be a good idea. So, I would think
that there needs to be something offical.
Additionally, a blog post reflects the understanding of the authors as
you said. I think it would be good to have different authors on this
post or even have several posts to different topics or views, which
are basically expressing the same.
That being said, an official documentation is good in my opinion. If
this documentation points people to blog posts which describe what it
means in practice, I think this would be enjoyable.
Cheers
Christian
Re: What are the basic, invariant rules of Apache projects?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Isabel,
On Fri, May 21, 2010 at 12:33 PM, Isabel Drost <is...@apache.org> wrote:
> On 21.05.2010 Bertrand Delacretaz wrote:
>> 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.
>
> Hmm - one question that came to my mind reading the list: Who is the intended
> reader of that blog post? Users of Apache projects, contributors, committers,
> PMC members? I would guess that users might be interested in a slightly
> different perspective than say committers....
The audience is committers and PMC members, and you're right that this
should be mentioned.
>
> Another question would be to define what is the purpose of the project: Should
> the reader take some kind of specific action (e.g. restructure the project he is
> working on), should frequent questions concerning how software is developed at
> Apache be answered (than the post should maybe not be just a blog post but
> somehow integrated in the official documentation?)....
By "purpose of the project" do you mean purpose of that blog post?
My goal is mostly for volunteer Apache community members to discuss
and agree on the list of "rules", and publish the results. No hidden
agenda, just trying to start clarifying what we mean by "the Apache
Way".
To me the big advantage of a blog post is that it can safely rot - it
only reflects the understanding of its authors as of today, as opposed
to official documentation which is supposed to be the Final Truth (and
is also much harder to agree on, for that reason).
-Bertrand
Re: What are the basic, invariant rules of Apache projects?
Posted by Isabel Drost <is...@apache.org>.
On 21.05.2010 Bertrand Delacretaz wrote:
> 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.
Hmm - one question that came to my mind reading the list: Who is the intended
reader of that blog post? Users of Apache projects, contributors, committers,
PMC members? I would guess that users might be interested in a slightly
different perspective than say committers.
Another question would be to define what is the purpose of the project: Should
the reader take some kind of specific action (e.g. restructure the project he is
working on), should frequent questions concerning how software is developed at
Apache be answered (than the post should maybe not be just a blog post but
somehow integrated in the official documentation?).
Isabel