Infrastructure needs

Both the core team and the community have certain shared infrastructure
needs that we've been discussing. Here is a summary. Feel free to fork
off discussion threads for each of these separately, but please change
the subject if you do. 


Threaded Discussion Space 
------------------------- 

We need to have a place where long lived (days/weeks/months) discussions
can take place. Currently this need is being filed by the mailing lists,
which are serviceable. A strong alternative (or addition) would be the
use of an NNTP server. NNTP has the following advantages over mailing
lists: 

* Access to the archive of past conversations is by the same means as
access to the current discussion. This makes it easy for a newcomer or
infrequent reader to follow conversation threads backward for context. 

* Threading is explicit, creating a stronger sense of structure in the
discussion. 

* The discussion groups can more easily be organized into a hierarchy. 

Mailing lists have the following advantages over NNTP: 

* More people are familiar with Email than News. Some people will need
to install a News reader, if their Email client is not a News client as
well. 

* The mailing lists are already set up. 

A gateway between the mailing list and an NNTP server (both ways) is
possible, and gives us the advantages of both mediums, except that
messages to the mailing list that are gatewayed to the news server can
break the threading, if the user's mail client doesn't support
'In-Reply-To:' or 'References:' headers. 



Collaborative Authoring Space 
----------------------------- 

Besides talking among ourselves, It's also important that we be able to
create various design artefacts together, leveraging each others
efforts. Feature lists, benefits, use-cases, scenarios, APIs, and
interaction diagrams are all examples of documentation that to a greater
or lesser extent needs to be worked out before code is written. 

A Wiki would seem to be the best bet for this purpose, and can mesh well
with the ongoing discussion by providing both a place to write down
conclusions reached on the mailing lists, and a place to point to from
those discussions. 

Mitch has already commited to setting up some form of wiki, but I am
unsure what criteria are being used to select the implementation to be
deployed. Here are some criteria I would suggest: 

* Implemented in Python, to make customization easier for the core team
and community to implement, if necessary. 

* A simple syntax for editing wiki-pages. The fewer typographical
oddities required for adding structure to the text, the lower the
barrier to entry. 

* Support for external editors. Frequent contributors will want to be
able to use their own preferred editing environment, and should not be
forced to use a browser text-area. 

* History and diff views, to be able to easily see what changes were
made, and by whom. 

* Undo. It is especially important to be able to undo changes made by
vandals. Vandalism *will* occur, and the easier the community can deal
with the problems as they arise, the better. 

* Structure. Wiki webs are ultimately hypertext webs, and don't usually
conform to a hierarchy. Nevertheless, some wiki tools do allow an
outline structure to overlay the wiki-web, making it easier to navigate
without having to maintain navigation pages by hand.

* Access Control. If a wide-open wiki proves unsuitable, it should be
easy to add restrictions on who is permitted to add and edit pages.
Ideally, these restrictions can be adjusted on a per-page basis, if
necessary.


Source Code Revision Control 
---------------------------- 

I'll let others more qualified than myself discuss their relative
merits, but there seem to be three contenders for this piece of
infrastructure: 

* CVS - http://www.cvshome.org/

* Subversion - http://subversion.tigris.org/

* arch - http://www.fifthvision.net/open/bin/view/Arch/WebHome

Comparison chart (seemingly slanted towards arch): 

http://www.fifthvision.net/open/bin/view/Arch/SubVersionAndCvsComparison

One thing I would recommend regardless of the source control solution is
several 'announce' mailing lists specifically for source code checkin
announcements. 


Documentation Space 
------------------- 

Besides a collaborative authoring solution, which is good for "what
we're going to build" documentation artefacts, we also need
infrastructure for "what we built" documentation, such as programmer's
API references and end-user manuals and help systems. 

Texts such as these are highly structured, and don't lend themselves
well to the relatively unstructured nature of a wiki web, at least not
without a great deal of 'shepherding'. Exceptions would be short
tutorials and how-tos that can easily live on a single page. 

There are several systems for creating developer documentation from
commented Python source code: 

Docutils: http://docutils.sourceforge.net/

HappyDoc: http://happydoc.sourceforge.net/

PyDoc: http://web.pydoc.org/2.2/pydoc.html

Since the need for end-user documentation isn't imminent, I'm punting. 


Bug-Tracking Space 
------------------ 

Bugzilla has been proposed as the OSAFs bug-tracking solution, but I'm
not sure that we need such a heavy weight solution, especially as I've
seen moderately technical people intimidated by the Bugszilla UI. I'm
personally familiar with several lighter weight solutions, but there are
plenty of these, and I see no need to advocate any particular one. I'd
be interested in hearing what features/qualities the core developers
would prefer to see in the system. In particular, should bug assignments
be 'pushed' to a developer, or 'pulled' by them?

Some requirements that will increase the utility of the bug0tracking
system are as follows:

* Bugs addressable by a URL. This makes sure that a bug can be easily
referenced from a wiki-page or from an email. This seems almost to
fundamental to mention, but occasionally I still run across bug- and
issue-tracking systems (even web-based ones) that do not have this.

* Easy for newcomers to enter a bug, with appropriate handholding to
properly characterize it.

* email notification of changes to bugs, both to the submitter, as well
as to subscribers, and the assigned developer.

* Extra bonus feature (I'm not aware of any bug-tracking system that
currently offers this): RSS feeds per-bug, per-category, and
per-everything that people can subscribe their news aggregators to.


Ok, that's it. Have I forgotten some category of infrastructure? 

Cheers, 

Michael Bernstein.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process