Project Management, The Apache Way [long]

[Ted Husted <te...@gmail.com>]

Since we've had some methodology discussions of late, I thought it
might be helpful to post a few notes about how things generally work
on Apache Projects.

First, there's a good general introduction on the Foundation site now 

* http://apache.org/foundation/how-it-works.html

The telling characteristic of an Apache Project is that there is not a
"benign dictator" as described in Raymond's Cathedral and Bazaar.
Apache Projects are not developer-centric, or even code-centrict, but
community-centric.

We are trying to create and maintain codebases that outlive the
interest of any one developer. To the ASF, a good product doesn't have
a lifecycle of a few years, but of decades. Essentially, we believe
that great code is a byproduct of great communities. If you build a
great community, great code follows.

Like many open source environments, we are strong believers in
infrastructure. Our infrastructure is much like SourceForge or Tigris,
or any other

* Mailing lists, one for end-user support, another for development
conversations.
* Repository
* Issue Tracker
* Website and/or Wiki 

A key ASF principle is that all development conversations are
reflected on the DEV mailing list. It is our communal memory. If it
doesn't happen on the list, then it didn't happen.

Because of this, all of our other resources are tied into the list.
The Repository and Issue Tracker mails change logs to the list. The
Website is maintained in the Respository, so those changes are logged
too, and Wiki sends its change logs to the directly DEV list.

The omnibus DEV list is great because if you watch the list, you are
appraised of absolutely everything that happens on the the project.

This omnibus DEV list is not-so-great because much of the information
is not threaded.  It's sometimes hard to link up a conversation on DEV
with a later commit to the Repository.

(There is a nifty way to link to mailing lists posts, since they are
numbered. But it's neither intuitive nor automatic.)

One key element of the Apache Way that most of the teams, including
Struts, don't use well enough is the STATUS file.

Here's the STATUS file for the Apache HTTPD 2.x team 

* http://cvs.apache.org/viewcvs.cgi/httpd-2.0/STATUS?view=markup

And the one for the Incubator

* http://svn.apache.org/viewcvs.cgi/incubator/public/trunk/STATUS?view=markup

I think the STATUS file may be the "missing project management link"
mentioned elsewhere. If a team does make use of the STATUS file, then
there is a quick rundown of where we stand.

But, as you will note, neither of these files is particularly up to date. :( 

(Unsurprisingly, open source coders are usually too busy driving to get gas.) 

Struts does have a STATUS file of its own, but like most others, it's
months out of date:

* http://svn.apache.org/viewcvs.cgi/struts/build/trunk/STATUS.txt?view=markup

(Mea culpa. I started it, and I should be maintaining it. (David
Graham warned me there would be days like this.))

The Roadmap and Milestones pages are somewhat current, but do lag
behind the latest conversations.

* http://struts.apache.org/roadmap.html
* http://struts.apache.org/milestones.html

If someone did want to help out with project management, a good place
to start would to submit patches for the Status, Roadmap, and Versions
pages.

The other, very real, problem we have is that Bugzilla runneth over.
We have way too many tickets posted, many of them obsolete, and it's
hard to see the forrest for the trees. This is another area where
someone with a project manager bent could do some good.

We could get a lot more use out of Bugzilla if someone took the
initiative to post tickets as things are mentioned. For example,
people have pointed out that, on the website, we've managed to hide
the link to the Mailing Lists. Anyone could post a ticket about that
to Bugzilla.

(But shouldn't someone on the team be handling this, you say? Yep, and
this is how people get on the team. First, you have to pitch in.)

In my own work, I've been experimenting with using an issue tracker
like JIRA in lieu of a DEV list. We have a separate JIRA project open
for Conversations. Since the numbers issue trackers assign are
obvious, it's easier to link things up later, or move a issues from
the Conversation project to the actual development project. To
continue the threading, JIRA has a Subversion plugin. We can can
reference a JIRA ticket in the Subversion log and the log is
automatically linked to a tab on the ticket.

Confluence also has a nifty Maril Archive feature, that I'm starting
to play with. You can hook up a page to a pop account, and it
incorporates the messages into a wiki page. Confluence also has a JIRA
reporting feature, so you can embed a dynamic ticket filter into a
wiki page.

Issue trackers, wikis, and mailing list archives are starting to merge
into a single application. This is a trend that will make things
easier for open source development, since we will have a one-stop-shop
instead of a strip mall.

-- HTH, Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org