[ZWeb] Some fishbowl work

[Ken Manheimer]

I've been trying to keep up on new zope.org effort - looks like great
stuff - but i've been only sporadic successful.  Nonetheless, i'd like to
dive in (and have been given some mandate - yay!), with some thoughts and
a proposal for a well-contained effort to address what i see as the most
pressing isue in the fishbowl.  Please let me know if i neglect some
relevant existing discussion - i don't mean to be disregarding anything...

First off, i think there's enourmous potential in the kind of
collaboration this group is attempting, and that we try to marshal in the
fishbowl, but there are some pitfalls and bumps in the road that can make
the rewards elusive.

I think the biggest difficulties are in adequately organizing
communication, and the "doomed to repeat history that you don't know"
effect.  The fishbowl process, python PEPs, and that kind of thing
concentrates on establishing clear statement of goals and approach as
prerequisites for substantial projects.  This enables many people to
contribute wisdom at the critical stage when formulation is happening,
and also leads to clear evidence of what went on; even failed proposals
offer valuable info about why they didn't fly.  The planning demanded by
this requirement also helps deter overambition - by forcing exposure of
specifics that turn out to be bigger than expected.  This is quite
valuable, especially so when it comes to group efforts.

All this documentation is useless, however, if it gets lost in the sauce,
and i think that's what's been happening in the fishbowl.  Scaling
overtook us (a good while back), so it's too hard for anyone to detect
and to track the items that concern them.

I posted a proposal to address this a while back - "FishbowlManageability",
http://dev.zope.org/Wikis/DevSite/Proposals/FishbowlManageability - but
haven't had time to work on it.  It looks like i may have a few days this
week, before a deluge of other commitments, and we (zope corp and i:-)
would like to try to get out of the hole *before* the opportunity disappears.

I would need to concentrate on a manageable chunk, because this week is
likely to be the lull before the storm, so i may not have a chunk of time
for a while afterwards, and i think that improvement in the change
monitoring stuff is crucial to everyone.  Here's what i'd like to do -
i'd be interested in feedback about the suitability and practicality.

I see two primary avenues to change monitoring at this point:

 1. A change monitoring product, along the lines i describe in my
    proposal.  (If we were in the CMF we could base something simple
    around CMF favorites, but we're not, sigh.)

    Advantages of this approach:

    - It would apply to all content, not just to wiki pages.

    - It provides a basis for harvesting meaningful attention statistics -
      how many people are tracking such-and-such item.

    Disadavantages:

    - It requires from-scratch implementation

 2. Adapt simon michael's ZWiki email notification mechanisms to zope.org
    WikiForNow wikis.

    Advantages:

    - It's already implemented, just means adapting code

    Disadvantages:

    - It applies only to wikis

    - It would not be appropriate for the CMF - tres is clear that
      content should not directly bring in dependency on incidental stuff
      (like email faculties).

Really, that brings me to the requirements for this little project - what
are the goals and specific features we have to have from change
monitoring?  I think i'll be working on sketching out my ideas on that
(including looking at my own, existing proposal!-), while people have
time to respond to this message...

Paul suggested another alternative - use the collector as central
repository for proposals and projects, with an issue for each, and then
let the issues refer to sites for the artifacts.

I'm not sure what i think of this - i don't think a single issue is good
for conducting the issue tracking in a project, but maybe it'd make sense
to use workflow for tracking the status of a proposal as it moves through
review and then project progress.  And the collector would provide for
notification about major state changes.  Maybe for update notices that
the poster wishes announced.

(Hmm, i realized the collector would have to be substantially changed to
enable anyone to receive notifications, and the collector doesn't yet
have the tracker's routing discrimination mechanism, for
metadata-sensitive dispatching.)

I guess this approach would entail:

 - Identifying how the collector would have to be changed to serve the
   purpose

 - Implementing the changes.

I'm not sure the collectors existing metadata and notification mechanisms
are close enough fit here to be compelling.  But i'm just thinking out
loud.

I'm interested in getting input and suggestions about all this.  To me,
the most important part is getting it started in the right direction -
maybe it's a project i could just get started, and have other people take
on.

--
Ken
klm@zope.com