Re: Design Process

Hi Michael,

Thanks for your prompt response.

"Michael R. Bernstein" wrote in message
news:<1036933511.16377.662.camel@fiawol>...

[snip]
> > 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)
> >
> 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. :-)
>
I'm in complete agreement with your philosophy of 'release early - release
often'. Your wiki proposal sounds like a very reasonable way to go about it.

However, the point I'm trying to make is: there are some issues that are
more *important* and *urgent* to Chandler than others. These are ones (by
definition) that help OSAF achieve its goals faster than others. We should
have a process to focus our energies on figuring out what these issues are
and then solving them.

> 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.
No argument here except possibly in semantics. I see "stimulating
discussions about OSAF design process and tools to adopt" as part of
"organizing"

Again, main goal of "organizing" or "stimulating", is to focus our energies
on critical Chandler issues and to allow newcomers to quickly come up to
speed.

> > 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.
>

Yes, I think we're in agreement here too. You're more focused on tools that
drive discussion and I'm more focused on the process itself (and they're
very intertwined).

[snip]

> > 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.
>

I like the term 'self-hosting', more positive than 'eating your own dog
food' :)

I wasn't thinking about what tools we should use yet (as I said in another
post, you're leagues ahead of me :) More simply, I was thinking we should
agree on a common category semantics tree and how that tree should evolve
over time.

I think, in general, coordinating shared schemas for Chandler is an
interesting problem that can solve lots of issues.

[snip]
> 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.
>
Again, wasn't thinking which exact tools to use. However, I do thinking
tagging each posting with keywords is a good idea. After all, that appears
to be a strong design point of Chandler. Agreeing on a shared taxonomy is
fraught with issues, tho'. Perhaps, that's a role of our BDfL?

> 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.
>

Your view proposal is a good idea but may be too fine-grained for what I'm
thinking. This is from my experience of using "Six Degrees"
(http://www.creo.com/sixdegrees/) which offers a similar view for Outlook
and other email packages.

[snip]
> 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.
>

I have to say I'm reaching that point of not keeping myself. However, I
wasn't proposing we split the list or that we adopt other tools. I think
your earlier posting addresses those issues more succinctly.

You do bring up good proposals on how we should split the group here tho'.

Best regards,

chao


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

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