Design Process

Hi all,

I sent a note to Mitch volunteering to help out with Chandler discussions.
Mitch asked me what my ideas were which I list (almost verbatim) below.

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.

The posting is fairly long, so here's a rough summary:
1) Let's focus on 4 or 5 design issues that are both "important" & "urgent"
(as Kaitlin Duck Sherwood may put it). An example of an issue is Andy's
"auto secure email" proposal.
2) Appoint a moderator and try to channel the community's intelligence and
wisdom to solving each issue
3) Each week, moderator poses summary and conclusion of the week's
discussions. Moderator also decides if issue is sufficiently closed to move
on. In this way, conclusions from each week help drive the next week's
discussions.
4) We should think about organizing the discussions in anticipation of the
day we will be using Chandler to drive such discussions. I illustrate with a
rough category framework example.

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?

Thanks,
chao

-----Original Message-----
From: Chih-Chao Lam [mailto:[email protected]]
Subject: RE: Design Process

At 11:31 AM 10/31/2002, Mitch Kapor wrote:
> On second thought, I'd be very interested to hear your ideas about a good
> process for organizing and facilitating internal and external
> discussions.  It seems to me there are two interlinked components: what
> software tools are used (and why), what the process is about who
> does what
> and why.  If you're interested in giving it some thought and sending
> something to me, that would be great.  Feel to follow up with
> questions or
> requests for clarification if you think that will help.
>

Hi Mitch and John,

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.

But first a few questions to set the context:
1) Apart from the Game Plan posted as part of OSAF's Mission Statement, can
you share a more detailed timeline and roadmap for Chandler?
	- what are the key milestones/challenges/obstacles?
	- what are the different subprojects? how do they all fit together?
2) What are the main reasons to do Chandler as an open source project?
3) How open do you feel OSAF should be to the open source community?
	- What and when would you not share externally?
	- In the game plan, are there/will there be issues that are proprietary to
OSAF?
4) What are the goals for each mailing list? what does OSAF want to get out
of each list?
5) Longer term, do you see Chandler itself being used as a tool to
facilitate such discussions? Is project management within the scope of
Chandler?
6) What is the structure, roles & responsibilities within OSAF? How do see
that evolving?

Would appreciate your thoughts and guidance on these issues.

Depending on your answers, what I'm going to say below may not make any
sense but here's a probably still half-baked perspective:

I think you have assembled a surprisingly large group of eager and talented
people. The challenge is to continually channel this pent-up energy to
productive and meaningful causes. I believe one way to keep this energy up
is to be as open and communicative as possible. The goal is to 1) lead with
a compelling vision (which you've done a great start), 2) communicate and
discuss a game plan to achieving this vision by highlighting challenges and
obstacles to overcome 3) assign different groups to tackle these challenges
4) iterate over the game plan as we see results and feedback in (2) & (3)

To paraphrase Andy Grove, we should "let chaos reign" by being as open as
possible. At the same time, we should "rein in the chaos" by offering
structure and organization to focus people's energies on the critical issues
and challenges.

So, as an example: I love Andy Hertzfeld's new posting about the Vista
prototype. It obviously shows a lot of quality work has gone into Chandler
already. I'm sure it will elicit a lot of feedback and discussions. However,
I'm also sure the prototype has uncovered a lot of new questions and
challenges so far unanswered by the group. What are these questions (e.g.
security issues in jabber communication)? How about explicitly posing these
issues to the group? Maybe even with tentative answers? This way you will
get the community focused on the issues you yourself are focused on
addressing; and most probably you will also get pretty decent answers. Of
course, by organizing such issues explicitly, it doesn't mean you won't hear
feedback outside of these issues. I don't think people are that shy in this
community! :)

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.

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

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

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.

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!

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

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.

Each posting can be associated to one or more categories. This will allow
Chandler to create lots of interesting views to slice and dice the
discussion threads. Paul Snively's and Bill Seitz's suggestion to peer rate
postings ala SlashDot style may also be worth looking into to further
increase signal-to-noise ratio.

...

chao



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

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