RE: Infrastructure needs

Hi Michael,

Thank you for a very thoughtful and to-the-point summary. This is exactly
what I was hoping for, when I suggested a strawman process [1] - but you're
already leagues ahead of me. [1]:
http://lists.osafoundation.org/pipermail/process/2002-November/000022.html

> Threaded Discussion Space
> -------------------------
>
Very well put pros and cons. From my personal experience, I lean towards an
NNTP solution with an email gateway. Some extra reasons: in the digest mode,
there is no way to continue a thread (that I know of), currently doesn't
seem to be a way to switch between digest and non-digest modes except to
bother Morgen.

Perhaps an extra consideration: I think we should plan for the day we are
going to use Chandler itself to organize such discussions. As such, we
should come up with a "Chandler discussion" category framework and see how
it can be applied to both News and Email mesages we will create in the
future. Also, how should such categories be embedded in the messages?

> Collaborative Authoring Space
> -----------------------------
>
Would like to repeat something Bill Seitz's advocated: Let's release
something first even if it's not perfect. The need for more communication
far outweighs the niceties that the perfect authoring space may provide for
us right now.

If you buy that, then another consideration is that the chosen Wiki should
be easily exportable e.g. to other future tools for collaboration, since
Wiki's are still improving and evolving everyday.

Finally, would be neat if users can subscribe to changes in Wiki pages as
they occur. For example, do wiki's support RSS syndication?

> 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.
>
Yes, agree wholeheartedly. Perhaps we need to start creating a list of the
different forms of documentation. e.g. Product and technical specs, FAQ for
both developers and end users, etc.

> 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.
>
OTOH, because there is so much work to do, I would advocate starting with
simple, "one-size-fits-all" tools until just before things get unwieldy.
However, we should definitely plan for future doc tools and a migration
path.

> Ok, that's it. Have I forgotten some category of infrastructure?
>
As we continue to make progress on Chandler, we should think about how
newcomers get quickly get up to speed. Are there new tools we need or would
the existing infrastructure suffice?

Finally, perhaps a discussion to arrive at a timeline of what needs to be
done when should help drive things forward?

Thanks again for your wonderful summary. I've enjoyed reading your postings
over the last few weeks, especially the ones gently & politely prodding
Mitch towards more openness.

chao

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

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