[Zope-Moz] ANNOUNCE: Zope management tree in Mozilla

[Paul Everitt]

Shalabh Chaturvedi wrote:
> Sure. I hereby grant you permission ;-).
> I am an ignoramus on license issues, though - maybe you can mention if
> there are any.

I propose that we adopt the Zope license.  More on proposed organization
in a moment.

> > - Include a toolbar, menus and contextual menus. They don't have to be
> > functional yet, their just there for the idea, and to see what kind of
> > commands we can come up with.

Sorry Martijn, I didn't see "contextual menus" in here.

> Also, what will be the process for further code development?

Yep, we're probably one step away from needing a process.  I have a
proposal for something that works pretty well internally (without going
the whole UML route).

Here are some needs, as I see it:

1) Different people are working on both different code and the same
code.  They need to stay in sync.  Also, people need to get proper
attribution for their work.

2) A "to do" list is being communicated by email.  Email is an awful to
do manager.

3) Design artifacts are being communicated by email.  This makes the
email archives the only place to find the design goals.

4) Other various artifacts (e.g. glossary) are needed.

I propose the following:

1) We'll create a CVS module that can be opened externally.  We've done
this for a couple of projects.

2) Obviously everyone will be able to checkout things from the Zope
Studio module.  But we'll also let a few people do checkins as well.  I
think, uh, that Shalabh is a good candidate. :^)

3) We put artifacts in CVS such as:

a. The code.  This is pretty obvious.

b. A CHANGES.txt.  This document can do two things: report changes and
collect things to be changed.  Just have a notation (such as a "+" or a
"-" for things to be done).  Later we'll use the Collector or Tracker
(its replacement) for this.

c. Most importantly, documentation that collects design goals, glossary,
etc.  This can be done in DocBkXML.  I'm doing a project with it right
now and it is pretty amazing.  You can communicate _structured_
information, such as what iteration a use case is supposed to land in!

d.  A CREDITS.txt, where the module owners will make DAMN sure everybody
that did good work gets mentioned.  (Perhaps the CHANGES.txt should note
who did the changes...)

I imagine that 3(c) is the most difficult one to imagine, so I'll
volunteer to get it off the ground.  If anybody wants to see how it will
look, send me an email and I'll send you the current rev of the
ephemeral Portal Toolkit docs.

--Paul