Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Wed, 26 Apr 2006 17:43:18 +1000
From: David Crossley <crossley@apache.org>
To: dev@forrest.apache.org
Subject: [Proposal] Project Management Roles
Message-ID: <20060426074318.GA25932@igg.indexgeo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i

An idea has occurred to me recently. Each of you will see
parts of your recent statements and ideas incorporated.
Let us discuss this and see if it would work for us.

--------------------------------------
Background
----------

Each project PMC is tasked with "creation of a set of
bylaws intended to encourage open development and
increased participation in the Forrest Project".
See the "resolution" link in
http://forrest.apache.org/guidelines.html#pmc

We have partially completed our Guidelines. It is up to us
how we define our Guidelines. Each project is deliberately
given scope to do whatever they see fit.

At Forrest we don't seem to be gaining sufficient momentum
with the "increased participation" side of things. We seem
to be relying on various capable and over-dedicated people.
If this situation continues, then i see the project would
dwindle and certain individuals would become burnt out.

--------------------------------------
Proposal
--------

Establish "Project Management Roles" for various
well-defined tasks (see below).

The concept is to have one particular PMC member to
volunteer for each role. No limit to the number of roles
that one can do.

Having responsibility seems to enable people to feel
more a part of the project. People feel more responsible
for doing a job when they officially have that function.
That helps the jobs to get done.

This is not intended to put pressure on people to force
them to do work nor "pull their weight". If they fail to
do their task, then someone else will be able to do it.
By virtue of having a well-defined role, it will get done
somehow.

Most roles have minimal tasks and are not too onerous.
For example, for the "Documentation Coordinator", the only
job might be to publish the documentation every Friday.
Sure it can be done at other times and other people can
do it too, but at least it gets done once per week.

Having a person doing a role does not mean that everyone
can leave it to them and rely on them. Anyone else can
dive in and do the job (for example, publish the docs
twice per week). The more people who are familiar with
the role, the better. Perhaps the person actually doing
that role will notice that there can be improvements to
how they are doing it.

Having the roles regularly fulfilled means that the
project will be able to flow more smoothly.

These are not elected positions. They are filled only
by volunteers. If no-one valunteers then we stumble along
as we do now, i.e. rely on some other poor bugger.

If a person is dissatisfied with the way a particular
role is being done, then they can volunteer to take over.

If a person feels that someone else has been doing a
stirling effort, but might need a rest, then offer to
take over. The current person might say "no it is okay,
you concentrate on so-and-so". Perhaps the current person
should relunctantly give up their role that they think
they are doing a good job at. Give someone else a chance.
You can always still assist the old role.

No need for a time limit. Keep going until someone else
wants to do it, or you ask to be replaced.

Each role should have some continually enhanced
documentation about it, so that if the person is away,
then some other PMC member can more easily do it.

Find a way to offer constructive criticism, perhaps by
assisting or enhancing the role documentation.

There are no roles for "leadership" of technical areas.
We don't have the concept of leadership at the ASF.
Rather these are "functional roles".

--------------------------------------
The Roles
---------

There are two roles that we have already defined:
PMC Member and PMC Chair. There are two other roles that
we already do, but are not yet formalised: Release Manager
and ForrestFriday Coordinator. These first four roles are
already well-defined.

There are a number of other roles that are currently being
done in a haphazard fashion. When we look further, there
are probably some other roles that we can define.

PMC Member
----------
This is well-defined in our Guidelines and in the top-level
ASF docs.

PMC Chair
---------
This is well-defined in our Guidelines and in the top-level
ASF docs.

Release Manager
---------------
This has been a de-facto role. Recently we held a
discussion to formalise it.

Tasks are being defined in etc/RELEASE_PROCESS.txt

ForrestFriday Coordinator
-------------------------
This has been a de-facto role. The tasks are defined in
http://forrest.apache.org/forrest-friday.html

Issue Tracker Coordinator
-------------------------
Add new Components, e.g. for each new plugin.
Other general Admin tasks.
Add new committers to the forrest-administrators group.
Add/enhance Filters.
Each month get the project to review the outstanding
major issues that are scheduled for the upcoming release.

Documentation Coordinator
-------------------------
Publish the documentation at least once per week.

Currently various people make edits to the source files,
but often the documentation is not generated and published.
This role is not actually about doing the documentation.
That should be up to everyone.

It is very easy:
cd site-author
forrest -f publish.xml build
forrest -f publish.xml deploy

Subversion Monitor
------------------
Ensure that svn:eol-style settings are appropriate.
Ensure no line-endings issues.
Regularly run xml-tidy.
Regularly run java-tidy.

There are already some Perl scripts and other tools in
the "committers" SVN and Forrest SVN.

Legal Monitor
-------------
Regularly run a script which verifies and inserts missing
license headers to source files.

Regularly ensure that there are appropriate matching
licenses to accompany each supporting product that we
redistribute.

This should have continual oversight by all PMC Members,
but the monitoring is something that needs to be done
regularly, and definitely prior to each release.

There are already some Perl scripts and other tools in
the "committers" SVN.

Developer Role
--------------
The above roles are only for PMC Members. How can the
Developers be involved? That is easy: do the Developer Role.

Help out with commenting on the Issue Tracker, fixing the
issues, contributing to discussion, contributing patches,
turning discussion into clear documentation.

This is incredibly valuable and will enable the project
to grow. After time, you will probably be elected as
Committer/PMC Member and when comfortable, can take on
one of the Project Management Roles.

--------------------------------------