You are viewing a plain text version of this content. The canonical link for it is here.
Posted to svn@forrest.apache.org by cr...@apache.org on 2006/03/18 16:14:28 UTC
svn commit: r386854 - /forrest/trunk/site-author/content/xdocs/guidelines.xml
Author: crossley
Date: Sat Mar 18 07:14:25 2006
New Revision: 386854
URL: http://svn.apache.org/viewcvs?rev=386854&view=rev
Log:
Expanded our definition of the Apache Way. Please amend if you think that
you can do better.
Added a new paragraph to explain why we have these "project guidelines".
The content of this paragraph is from the ASF Board resolution that
created our PMC, so not much scope for changing its words.
Modified:
forrest/trunk/site-author/content/xdocs/guidelines.xml
Modified: forrest/trunk/site-author/content/xdocs/guidelines.xml
URL: http://svn.apache.org/viewcvs/forrest/trunk/site-author/content/xdocs/guidelines.xml?rev=386854&r1=386853&r2=386854&view=diff
==============================================================================
--- forrest/trunk/site-author/content/xdocs/guidelines.xml (original)
+++ forrest/trunk/site-author/content/xdocs/guidelines.xml Sat Mar 18 07:14:25 2006
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
-Copyright 2002-2005 The Apache Software Foundation or its licensors,
+Copyright 2002-2006 The Apache Software Foundation or its licensors,
as applicable.
Licensed under the Apache License, Version 2.0 (the "License");
@@ -28,7 +28,7 @@
how voting works, how conflicts are resolved, etc.
Apache Forrest is a project of the Apache Software Foundation
(<link href="http://www.apache.org/foundation/">ASF</link>) which is a
- non-profit corporation. As with all such organistions there are some
+ non-profit corporation. As with all such organisations there are some
procedures to be followed.
The ASF website explains the
operation and background of the ASF. These project guidelines supplement that
@@ -49,9 +49,26 @@
<title>The Apache Way</title>
<p>
Forrest is typical of Apache projects, in that it operates under a set of
- principles known collectively as the "Apache Way". This facilitates
- open collaborative development, with respect for others.
- For more information about how Apache projects operate, please refer to
+ principles known collectively as the "Apache Way". There is no clear definition
+ (perhaps that is part of it) and it is ever-evolving. Each ASF project is different
+ in its own way - there is healthy diversity rather than uniformity across all projects.
+ The main principles are to facilitate open collaborative development, with respect for
+ others; to ensure that there is a healthy community (even to give community issues
+ higher priority than code issues); to ensure that each contributor is recognised and
+ feels a productive part of the community; to encourage diversity; to make the project a nice place to be.
+ </p>
+ <p>
+ Each project, as part of the
+ <link href="http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_05_26.txt">resolution</link>
+ that formed its Project Management Committee (<link href="#pmc">PMC</link>),
+ creates its set of project guidelines intended to encourage open development and
+ increased participation. These facilitate the project to conduct its main charge,
+ which is the creation and maintenance of open-source software for distribution at no
+ charge to the public with the purpose of its
+ <link href="#mission">mission</link>.
+ </p>
+ <p>
+ For more information about the way that Apache projects operate, please refer to
the
<link href="http://www.apache.org/foundation/">ASF foundation</link>
and
Re: svn commit: r386854 - /forrest/trunk/site-author/content/xdocs/guidelines.xml
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
>
> Now to my observation. Davids definition of the "Apache Way" is very
> good, IMHO. Let me highlight one specific part...
>
> >+ to ensure that each contributor is recognised and
> >+ feels a productive part of the community; to encourage diversity;
Good stuff. That is my next installment - a section
about "Contribution and acknowledgement". I have used
a whole paragraph of your words as-is, along with snippets
and ideas of other people. Thanks.
-David
Re: svn commit: r386854 - /forrest/trunk/site-author/content/xdocs/guidelines.xml
Posted by Ross Gardler <rg...@apache.org>.
crossley@apache.org wrote:
> Author: crossley
> Date: Sat Mar 18 07:14:25 2006
> New Revision: 386854
>
> URL: http://svn.apache.org/viewcvs?rev=386854&view=rev
> Log:
> Expanded our definition of the Apache Way. Please amend if you think that
> you can do better.
Thanks David. I can't do better but I would like to make some *general*
observations.
For the benefit of all readers, let me stress the word *general* again,
these observations have nothing to do any specific incidents or any
specific individuals here in Forrest (other than one specific reference,
which is clearly noted), they are just general observations that I have
drawn from many years of experience in Open Source Software and Open
Development in various forms.
For some context with respect to other forms of Open Development I refer
to readers should know that I also have a background in academic
research, which is often an Open Process, involving researchers from
multiple backgrounds, nationalities, industries, universities and
companies. The academic open processes, unlike open source software
development, has many *hundreds* of years of process development.
During that time some fairly rigorous conventions for the recognition of
individuals in a open research project have been developed.
Whilst these open development processes are not directly transferable to
Open Source Software, I think there are some transferable lessons.
Now to my observation. Davids definition of the "Apache Way" is very
good, IMHO. Let me highlight one specific part...
> + to ensure that each contributor is recognised and
> + feels a productive part of the community; to encourage diversity;
I think this is the "sticking point" in any open development. The
problem is that it is natural for individuals to feel that recognition
involves seeing their name in lights.
In an Open Source Project, or more importantly, a project developed
using an open process, such as Forrest, most contributions of actual
code are supported by, or at least *should* be supported by, design
discussion, oversight, testing, documentation, bug fixes and much more.
No code contribution is an independent unit of work (or should not be).
It is therefore impossible to credit individual contributors, it is
simply unmanageable, even if it is possible to identify each part of a
contribution.
These observations have been made many times on this list. Most recently
they have been been referred to as FUD, and as individual opinion. Let
me be absolutely clear, in my (not so humble) opinion, this is *not*
FUD. It is an observation informed by many years of experience within
Open Source and Open Development communities. Further, it is an
observation repeated by many such experienced individuals both here in
Forrest and across the ASF as a whole.
Could I/we be wrong? Yes, of course I/we can. Nevertheless, I restate my
conviction that the current meritocracy process is recognition enough in
a healthy community. This meritocracy process is amazingly similar to
the academic research meritocracy in which people are awarded titles in
recognition of their contributions to their field.
Perhaps, more importantly...
Whilst Forrest is a great tool, it is unlikely to go down as an
important advancement in the development of computer software.
Is there really anything in here that is such a leap forward that we
need to claim individual ownership?
If there is, then we can trust to history to figure out who gets the
credit. That is the point of an Open Development process, everything is
documented and openly available.
Since I find myself repeating myself, I ought to shut up until someone
comes up with an argument that is convincing to me.
Ross