[ZDP] ZDP-Tools Plans and ZDP guidelines

[Maik Roeder]

Hi Kamon !

kamon ayeva wrote:
> About the plans I think we need to divide and set different priorities
> because there are too much to do, and we all have limited time.

Right, I am currently working on making just this supported
by the ZDP-Tools:

1. I have cleared up the constructor code, and tested it heavily,
   so it is certainly in a very good shape. With this as a basis,
   I can go on adding new ZClasses.
2. The next thing will be creating all the Tasks that I have 
   proposed. This will make it possible to sort them according
   to a (to be created) priority property.
3. Finally add a Changes History so the developers can really
   capture everything that has been programmed. The Changes 
   History can be used for much more, but this is the most
   important application from my point of view as a ZDP-Tools
   contributor.
4. Along with the Changes History goes the Contributor History,
   but as all changes will have the Contributors name on them,
   maybe the contributor history is just a byproduct ?

> I globally agree with Rik's answers, but I can comment further on some
> things important according to me:

I'll go back here to Rik's mail, to which I have not yet answered:

> Notification on demand
> 
> [rh] Sounds nice. i take it this is configurable as to who what and if?

I don't want to put too much magic into this, and I hope it will just 
evolve.
 
> Lately, Tres Seaver has rewritten Mailbag, refactoring the logic into Python
> classes. The corresponding ZClasses for the presentation layer still have to
> be rewritten, but can possibly be taken over from the previous Mailbag
> version.
> 
> [rh] hm, is this available somewhere

It is available from Tres Seavers homepage on Zope.org.
http://www.zope.org/Members/tseaver/MailBag
 
> [rh] the point to throw in here is whether a whole zope archive would be the
> best idea. It is the simplest to maintain (if it's technically working), of
> course, but a mail digest would be an even better idea. This is technically
> simpler , but requires more human resources (read volunteers).

I don't want to create just another mail archive. There are other people
who have the ressources do do so, but indeed what I want to do is actually
a mail digest. Mails will only remain stored if they are being referenced !
I just figure that this makes it work like the Python garbage collector :-)

> Right now, I  have started some watching of the mail lists (zope, zope-dev) 
> and I add snippets whenever anything I think is useful comes out of the list.

I think it is a valiant effort to extract the information from the mailing
list, but my reason for creating a MailStorage would be to give credit
to the original author of the content. The extractors work really shows
up even more this way if he can bring the mail from the original posts
into a good shape.

> The only way to get this going if we had 'topic watchers'. In that way it
> wouldn't be _too_ much of an effort.

For me it is important to have support for automated quoting of mails from
the mailing list. If the quoting is not used, then the information is not
worth to be quoted.

> While the mailing list is a great resource, there is much junk on it (from a
> documentation point of view) at some 75 messages a day this would mean more
> than 27000 (excluding zope-dev) messages per year, with a deminishing rate
> of usefulness as Zope and its documentation stabilizes. Intuitively, I'd say
> that keeping a complete archive is the responsibility of someone else (DC I
> presume?), not the ZDP.

Right.
 
> * Changes History
> 
> Changes could be gathered for ZDP-Tools and bundled with a new release to a
> Changes.txt.
> 
> Generally we need to capture changes to all that is added or changed. At the
> bottom of every form there should be a field where you can take a not on
> what you changed or added. This information would be gathered in a Changes
> Folder.
> 
> [rh] I'm not sure I know what you mean

When I change a piece of documentation or add a new DTML method to a ZClass,
then it should be supported by the ZDP-Tools to also create a Changes
note on the fly.
 
> * Style Guide Tips and Zope Tips
> 
> On a login Screen or in the Management interface there could be a place
> where Tips can be displayed at random.
> 
> [rh]mwah, the tips is the thing I always switch off immediately when I
> install a new program. Tips look fancy, but I think they're useless (did you
> even get a tip when you needed it)?

OK, then we can put the tips into a repository and handle them like FAQs
and Snippets.
 
> * List members with their Roles
> 
> [rh] ok, but not for public view

What do the others think ? I would not have a problem with showing
my role in the project.
 
> [kamon]
> * Synchronization of content with Zope.org (how-tos):
> I imagine this can be done with XML-RPC syndication, but why not simply
> propose to DC and the community that the how-tos area be switched to ZDP
> site. The reason is that people will need a single point to access
> documentation and also have the feature of downloading the how-tos.

I want to add Links in which the content of the Howtos are hidden.
The content will be found by the Catalog, but the people should
first look at the source on Zope.org before looking into the copy
on ZDP.

What do you think ?

Maik