[ZDP] ZDP-Tools Plans
Rik Hoekstra
rik.hoekstra@inghist.nl
Sun, 9 Apr 2000 21:55:14 +0200
The following is a list of my plans for the ZDP-Tools.
Please tell me what you think about them, and if you want
to take over some of the tasks, just let me know.
[rh] See comments in the text. I don't mind taking over some tasks (though
my time is limited). Any preferences.
One additional point: a better login mechanism would be nice. Now, a
specific role is only effective from one level below the one you logged in
(by calling <url>/manage) WHile this works more or less, it is a bit clumsy.
Rik
--------
* Topics and Subjects in Meta-Tags
Add the topics in the HTML Meta-Tags
[rh] Good idea.
* Notification
Notification per meta_type, for example you get an Email everytime a comment
is added. Maybe Notification folder in MemberFolder ?
Notification per path prefix. Everytime something is added to an object with
the path prefix "/projects/zdptools/", and Email is sent.
Combined Notification
For example I would like to be notified when a comment is added to
"/projects/zdptools/".
Notification to Maintainer
Notification to Writers
Summary Notification after a period of time
Notification on demand
[rh] Sounds nice. i take it this is configurable as to who what and if?
* Mailbag
It would be nice to have a Mailing list tracker on the ZDP site, where all
messages, which are sent to all of the Zope mailing lists are kept. The
messages could then be used for searching on specific topics, and could also
be directly reused when new pieces of documentation are written.
Reusing pieces of documentation right now means to track the mailing lists,
using your own mail reader, or going to one of the online Mailing list
trackers like egroups, and then cutting and pasting the message into your
documentation.
Just taking over content is not nice without giving credit to the original
author. It is also not very user-friendly because much of the discussion,
which has been surrounding the posting in the original discussion thread is
simply lost. The original thread can be very useful for ZDP visitors, who
may want to have a look at it when they see it quoted.
Right now, giving a pointer to the original post is hard, because you can
not be sure whether the site you are pointing to always keeps the URL, or
for what is worse, even disappears. We need to be sure that a quoted message
along with it's thread still exists in the future.
We don't have enough space on the ZDP site to keep the whole Zope mailing
lists, and so we are planning to digest the incoming mails only for a
certain period of time. Afterwards, the mails will be deleted if they
haven't appeared in a thread that has been quoted.
We don't have the ressources to update the Mailing List Tracker everytime a
mail is sent to a mailing list. So, to quote a mail, we need to manually
upload all mails which have been written to that list since the last update.
We also need to update threads to which new mails have been posted in the
meantime.
We also lack a tool for uploading messages to the Zope site. We could extend
the Mailbag product by Tres Seaver which uses the Python 'rfc822' and
'mailbox' modules to parse messages and mailboxes.
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
To get the mail into Zope, a program needs to be written that calls Mailbag
via ZClient when a mail arrives. Another type of program could be useful for
importing existing Mailboxes into Zope.
For delivery, an MDA like procmail could spawn a program out of a .forward
file and ask it to upload the mail to a Zope folder according to a
predefined set of recipies.
There exists a Python program called getmail which takes mail from a POP3
server and delivers it into a mailbox. The delivery part of this program
uses a getmailrc which could be used instead of the procmail recipies.
Once the mail is in a local installation on a ZDP members own Zope server,
it is easy to export the email and upload it to the ZDP site. From there,
the ZDP members can quote the message easily by directly pointing to the
URL.
This way, we may not get a complete mail archive, but at least we can always
be sure that the quoted mails and their surrounding thread exist.
[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). 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. The only
way to get this going if we had 'topic watchers'. In that way it wouldn't be
_too_ much of an effort.
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.
* 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
* 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)?
* Information Architecture
For Members and Visitors, there should be a different view in the content.
Members should see the projects they are involved in and their own
documents. Reviewer should see what documents need a Reviewer. Generally the
information architecture shpuld match the users view of the information
space.
[rh] Right. At the moment, I think Visitors (=people looking for
information) are presented too much ZDP and too little documentation. While
the zdp is building up, this is no problem, but when it stabilizes,
documentation should be the primary focus of the site. That means: hide all
the zdp-centric stuff (except for an advertisement calling for participation
and a separate area where everyone can see what is going on)
* Contributor History
There should be Contributor Folders, in which all Contributors should be
stored that have ever changed or worked on the document. Possibly the
Changes history could be stored there as well ?
[rh] yes
* Role Grant
There should be a mechanism by which Roles can be granted to members. The
Roles would also change the view on the information space for the member.
[rh]yes, this seems no problem
* Review Process
Writers who need a Reviewer can send a mail to a Reviewer to ask for
reviewing. This is more personal than just setting the NeedsReviewer
property. Reviewers can select in what Subjects/Topics they are axpert and
Writers select among Reviewers when they ask a Reviewer.
[rh] ok
* ZDP-Tools RoadMap
Publish this Plan. Define Tasks.
[rh]ok
* List of Zope Products
List of all Zope Products, perhaps also with Source code. Categorize the
products.
[rh] very important. One addition: keep list up to date. Perhaps we could
cooperate with the zope site in this respect (for example: when a new
product is cataloged there, the zdp site automatically gets updated)
* Zope Source Code on ZDP
Regularly upload the Zope Code to the ZDP site to have it searchable in the
ZCatalog.
Use py2html to create the HTML files.
PyFontify colorizes the Python Scripts
load_site for uploading the Code via ZClient
[rh] OK, a Mozilla like cross-linked code reference would be an even better
idea (but hard to accomplish)
Mirror Howtos and Tips of the ZDP site
This could be done by adding WebSiteLink instances for every Howto on
Zope.org to the Howto Project folder. In the WebsiteLink the abstract and
the author information could be added. The original content of the Howtos
can be stored in the Link but will only be displayed on demand. People
should look at the Zope.org site first. This way the reader is sure to
always have a recent version of the howto, but also can find it on the ZDP
site in the Catalog.
[rh]. Howto's should also get keywords/topics/subjects
* Threaded Discussions
Comments in Comments -> Thread
[ok]
* Use form_ everywhere
In the constructors of some ZClasses the form_ templates are still not used
(e.g. Member ZClass).
[rh]ok
* List members with their Roles
[rh] ok, but not for public view
* Add more Roles
[rh]ok
* Search by meta_type
[rh]yes, well...
* Let Anonymous see ZDP-Tools Implementation
[rh]hm, don't know. Make zdp-tools available for download seems enough to
me.
* Take over Zope.org look
[rh]Why so, I vote for keeping own look. In that way people confuse the
sites less easily.
* Aging of Documents
Get an Awareness about the age of a document. Define colors or numbers for
the age.
[rh]?. More important to indicate the synchronization of documents and Zope:
document such and so, updated for zope version 7.3.19
* Transformation of Documents
Cut and Paste. Delete and Shredd. Transform Meta_types.
[rh]ok
* Different supported views in a Drop Down list
Show_Flat, Show_Flat_short, ...
[rh] good
* Announce as News Item
In the constructor give a field where you can directly add a news item for
what you are adding.
[rh]yes
* Personal bookmarks
A link can be added to a personal links section, which can be seen on your
management Interface for quick reference.
[rh] mwah
* Other meta_types by this author
Links to other stuff a member has written
[rh] yes
* Complete ZDP-Tools Documentation
The ZDP-Tools Documentation should be completed before adding new features
:-)
[rh] good.