Re: Design Process

Hi Chao,

Thank you for a very thoughtful and detailed proposal. 

On Fri, 2002-11-08 at 15:21, Chih-Chao Lam wrote:
> 
> [snip]
> 
> There are many holes and hand waving in my suggestions. Would definitely
> appreciate feedback and advice from the group, especially to come up with a
> list of actionable first steps.
> 
> [snip]
> 
> In this spirit, would especially like direct feedback on:
> a) Does this process make sense? What are better modifications and
> alternatives?
> b) If it makes sense, what are Chandler's urgent and important issues today?
> c) What is the criteria for discussion tools if we adopt a process like
> this?
> d) What should first steps be?
> 
> -----Original Message-----
> From: Chih-Chao Lam [mailto:[email protected]]
> Subject: RE: Design Process
> 
> [snip]
> 
> I'll take a stab with thoughts on organizing EXTERNAL discussions. I feel I
> don't know enough about OSAF internally to be sufficiently brave and offer
> an opinion about internal discussions yet.
> 
> [snippage]
> 
> DISCUSSION PROCESS
> So, I'll like to propose that we:
> i) Provide a more detailed game plan for achieving Chandler's vision
> ii) Highlight near-term and crucial/difficult longer-term challenges we need
> to meet (topics)
> iii) Organize discussions around topics of (i) & (ii)
> 
> Once these topics(ii) are decided, we appoint a moderator for each topic
> (ideally an OSAF staff or committed volunteer). Each week, the moderator
> seeds the discussion by starting out with issues surrounding the topic that
> we need input on. At the end of the week, the moderator summarizes the
> discussions of that week and conclusions the group has arrived (with
> moderator discretion but also explicit reasons for chosen conclusions). The
> summary is then disseminated to entire community and drives the next week's
> discussions. If there are no more issues surrounding that topic, then the
> topic can be closed. In many cases, these summaries can then be fed into
> later product specs as we begin to build Chandler.

Ok, this is where I'll start adding commentary.

i) just dump out an incomplete outline to a wiki (as a single document),
and some folks will start annotating it directly with requests for
clarification, other folks will expand the structure where they think
more detail is needed, and still others will add in some minor detail
that their boss knew when they wrote the outline, but forgot to put in.

Heck, you'll even get some anal-retentive person who just goes through
the whole thing correcting other folks' spelling and grammar mistakes.
:-)

So, my recommendation on this is 'release early - release often'. It's
OK to not wait until the document is 'done' before posting it where we
can start messing with it.

ii) Again, just dump out an incomplete list, and it will start evolving.
People *love* to point out problems. :-)

iii) I'm not a big fan of 'organizing' discussions. I prefer to
'stimulate' them, as you can't really know what turns the conversation
will take. I'll have more related comments below. Simply by providing
the appropriate venues and tools, what happens naturally is that someone
posts a question to the mailing list, and either receives an answer, or
a discussion ensues. In most cases, whoever asked the question is the
de-facto ad-hoc moderator for that thread (after all, it's their
question!). After the conversation dies down, whoever asked the question
should probably summarize what they learned to the wiki. If they don't,
someone else can.

Another pattern of behavior is that of a *proposal*. Here, the
conversation starts off by someone adding a proposal document to the
wiki, and post an announcement to the mailing list for comment.
Discussion ensues on the mailing list while annotation ensues on the
wiki. Occasionally someone will be prompted to post a counter-proposal
to the wiki, but this doesn't happen very often.

> How we choose topics and moderators should also be influenced by structure
> of OSAF as posed in Q(6) above.

As I've outlined above, moderators will tend to self-select themselves
and their topics. As a self-referential macro-example, I was at least
partially responsible for prompting the creation of the 'process'
mailing list. Had a public wiki already been available, I would have
simply started a 'process and infrastructure' group of pages, and
pointed to it on the design and dev lists.

> Once we adopt a design process, the process itself should drive a list of
> criteria for choosing the discussion tools we will use (e.g. Wiki, NNTP,
> etc.)

As I see it, the process is currently constrained by the limitations of
the mailing list as a medium. Imposing more structure on a mailing-list
driven process will likely just raise a barrier to participation.

One of the main advantages of an NNTP server is the ability to create
heirarchies of topics, similar to the heirarchy you outline below.

> TOOLS
> My feeling is that discussion boards are more suited when things are in flux
> and there is a divergence in opinions and when facts are still being
> unearthed and discussed. Wikis (and I have little experience here) are more
> suitable in stating plans, issues and conclusions (i.e. as a central
> repository of info that is continually updated).
> 
> So, Wiki's will be used to document and browse roadmaps, FAQs, status and
> problem statements (and solutions to date) and perhaps weekly summaries.
> Mailing lists (structured in a more fine grained manner than today) are used
> for ongoing discussions and debates. Of course, there will be lots of cross
> references between the two tools.

You've got it largely correct. The only point I'd like to expand on here
is that the use of the two tools isn't just cross referenced, it's
synergistic: The discussion provides consensus that drives the creation
of more permanent documents, and the existence of those documents
informs and drives discussion.

> CHANDLER/AGENDA-STYLE CATEGORY SUPPORT
> Finally, I feel we should plan now for the day that we'll be using Chandler
> to design and build Chandler. Thus, we should attempt a category framework
> that we will associate to each Chandler message in preparation for the day
> we will all use Chandler!

Ah. This is a very astute observation. In common open source parlance,
this would be the point at which Chandler becomes 'self-hosting'.

I've thought of suggesting that Chandler should be an NNTP client, in
part because both Netscape/Mozilla Mail-News and Outlook Express support
this functionality, but I came up against a stumbling block: NNTP
newsgroups are very strongly hierarchical, with discussions occurring in
nested topical groups, and Chandler's design philosophy (as I understand
it) is almost antithetical to this sort of explicit containment
hierarchy.

> Looking retroactively at the discussions so far, an example of a framework
> (not comprehensive) could be:
> 
> * root: chandler discussion framework
> 	* design
> 		* UI
> 		* Usage Scenarios
> 		* Planned Features
> 		* Feature Requests
> 			e.g. TimeTracker/ProjectMgmt
> 		* "Philosophy/Guiding principles"
> 		* "Other PIM Designs pros/cons"
> 			* ECCO
> 			* Agenda
> 			etc.
> 	* dev
> 		* "architecture"
> 		* "data model"
> 		* "chosen tech"
> 		* "other open source projects to consider"
> 		* "non open source technologies to look at"
> 	* issues
> 		* "monolithic app vs. platform of services (daemons)"
> 		* "automatic categorization"
> 			* "Spam filtering"
> 		* "interoperability with other apps"
> 		* "collaborating with peers"
> 			* "sharing information"
> 		* "PDA support"
> 		* "offline replication support"
> 		* "internationalization & localization"
> 		* security & authentication
> 	* components
> 		* editor
> 		* calendar view
> 		* etc.
> 	* Organizing the Community (as recommended by Michael Bernstein)
> 		* Philosophy
> 		* Process
> 		* Tools
> 			* Wiki
> 			* NNTP
> 			* Mailing List
> 			* Chandler

While overall, I think this is a pretty good starting point for an
outline of the sort of documentation we require, I *don't* think that
this is a particularly good structure for organizing the discussion.

As I understand it, what you're proposing is a taxonomy of keywords that
can be used to tag individual postings. A formalized taxonomy seems
overkill to me.

Since these keywords will likely appear of their own accord in the
relevant postings, wouldn't it be best if Chandler simply has the
capability to display a view of threads that mention a keyword or
phrase? The key is to include postings in the view that don't contain
the keyword, but that appear in the same thread as postings that do.

If Chandler has the capability to import view settings, then we can use
the wiki as a distribution point for these as well, directly from the
relevant pages.

> The trick is to strike a balance where categories are not too fine grained
> but enough to focus people on a specific area. I feel [design] and [dev] are
> too coarse grained today.

You raise a very valid point. The current lists *are* too
coarse-grained.

However, that does not mean that the lists should be split just yet. In
my experience, you should only consider splitting a list (or creating a
sub-group) when someone utters the key phrase "There is too much traffic
on the list, I can't keep up". This is the point at which it becomes
impossible even to skim the postings, much less read them all.

it would help to try and plan out in advance how those splits should
happen, and to that end, here are some discussion areas that will kick
in eventually:

* Development *of* Chandler the platform

* Development of Chandler the application *on top of* the platform

* (Development of other applications on top of the platform?)

* Development on top of Chandler the application (third party add-ons)

* Development of various components

* Use of Chandler components outside of Chandler (parallel example: Use
of ZODB outside of Zope)

* End users wanting assistance.

* Infrastructure development and maintenance

* Discussion of specific standards and protocols in context of Chandler
(ie. RDF, Jabber, HTTP, OpenPGP)

* Here's a question: Do we want separate UI discussion areas for design
of UI vs. development and implementation of UI?

* Platform specific discussion/development (Windows, Linux, OSX)

One interesting example to look at are the mozilla newsgroups:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=netscape.public.mozilla

Another example are the Zope mailing lists:
http://www.zope.org/Resources/MailingLists

At one point last year, I was advocating that the Zope mailing lists be
gatewayed to a hierarchy of newsgroups like so:

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

    development-of-zope groups:
    
    zope.dev.checkins       <-> [email protected]
    zope.dev.cmf            <-> [email protected]
    zope.dev.coders         <-> [email protected]
    zope.dev.cvs            <-> [email protected]
    zope.dev.general        <-> [email protected]
    zope.dev.xml            <-> [email protected]
    zope.dev.xml.parsed-xml <-> [email protected]
    zope.dev.zodb           <-> [email protected]
    zope.dev.zpt            <-> [email protected]
    
    
    discussion-of-development-with-zope groups (note that 'zope.discuss'
    should be considered a placeholder):
    
    zope.discuss.general    <-> [email protected]
    zope.discuss.rdbms      <-> [email protected]
    
    
    other groups/lists:
    
    zope.moderated.announce ?? <->  [email protected]
    zope.discuss.italian ??    <-> [email protected]
    zope.discuss.web ??        <-> [email protected]
    
    ??                      <-> [email protected]
    
    ??                      <-> [email protected]
    
    ??                      <-> [email protected]
    
    Note that several lists that I am classifying under zope.dev.* are
    currently doing double duty as their non-existent equivalents under
    zope.discuss.*, for example zope.dev.zpt and zope.dev.xml .
    
-8<----------------------------------------------------

This attempt fell through due to circumstances beyond my control,
unfortunately, and eventually the Zope mailing lists were gatewayed to
news.gmane.org:
http://news.gmane.org/?match=zope

Whew. It's late, and I think I've brain-dumped enough for one email. Let
me know what you all think.

Cheers,

Michael Bernstein.

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

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