Re: Infrastructure needs

Michael,

This is a great contribution.

As a reminder, there is already an NNTP gateway for the OSAF mailing lists 
which has been set up independent of us.  It can be found at 
gmane.org.osaf.design for the design list and similarly for the other 
lists.  By registering there, it is also possible to post directly to the 
newsgroup and have it mirrored to the mailing list.  It seems reliable, but 
we haven't been able to fully test it. We are considering putting a link to 
it on the main OSAF web site.  I don't think it solves the problem of a 
convenient way to search the archive, so we're looking into options for 
doing just that.

We're working on the collaborative authoring space along the lines of your 
list of bullet points.  The main hold-up is a lack of personnel to get this 
going.  As we add more staff, which we are in the process of doing, things 
will move more quickly.  I'm all in favor of having volunteers do as much 
as possible of the coordination, but even that requires someone here to be 
involved.  We expect to have one new person starting next week, 
announcement to come, which is going to help.

On the subject of source code control, we're using CVS.  Questions about 
CVS vs. other approaches should be posted to the dev list.  I know it's a 
process issue, but the developers are attending to the dev list, not to 
process. They or I will cross-post anything about source code control here.

Mitch

At 03:19 PM 11/8/2002, Michael R. Bernstein wrote:
>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

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

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