[Zope3-dev] Development methodology (Re: [Zope-CMF] Future CMF) (rant)

[Jeffrey P Shell]

On Friday, October 11, 2002, at 08:37  AM, Tom Deprez wrote:

> <snip>
>
>> What now?  It seems to me that *someone* (or a very small task group)
>> has to put a concentrated effort in this.  Perhaps a Wiki sprint would
>> be helpful?  I'd suggest to just start over, by creating a new Zope3
>> Wiki.  But since I'm not volunteering (unless Jim assigns me to this
>> task) that's just a suggestion.  And once the Wiki is reorganized,
>> someone needs to stay on top of it: update status regularly, remove
>> abandoned proposals, and generally make the Wiki easy to navigate for
>> visitors old and new.
>
> Mmm, how could we start on this? I'm not sure, but I think there is no
> 'rule' or 'style guide' on how to maintain project management in a 
> Wiki.
> Perhaps time to start one?

Such documents exist - I dare you to find them!

> And then, how will one person or a group of people be able to maintain 
> it?
> Should people contact the maintainers?
>
> Let's see if we can make it clearer.
> Just brainstorming here and not just general skeleton:
>
> Zope3
>    VisionStatement
>
>    The Project
>       AreWorkInProgress
>          (contains links to all subprojects with this status,
>            maintained by the wiki maintainers, according to 
> information from
> subproject)
>       AreProposals
>          (contains links to all subprojects with this status,
>            maintained by the wiki maintainers, according to 
> information from
> subproject)
>       ArePlanned
>          (contains links to all subprojects with this status,
>            maintained by the wiki maintainers, according to 
> information from
> subproject)
>       AreImpelemented
>          (contains links to all subprojects with this status,
>            maintained by the wiki maintainers, according to 
> information from
> subproject)
>       AreRejected
>          (contains links to all subprojects with this status,
>            maintained by the wiki maintainers, according to 
> information from
> subproject)

This is link after link after link.  Compare this to 
<http://www.python.org/peps/> - the PEP index is a very simple clean 
structure, one line per PEP, that can be easily scanned.  The very 
important informational 'Meta-PEPs' are at the top, the fairly 
important information PEPs are right underneath them, and then it 
progresses down with a structure like outlined above - followed by a 
straight numerical listing.  Such listings can be less pretty, but at 
least they're all there, like <http://dev.perl.org/rfc/>

Regarding Jim's statement regarding WikiNames - I'd rather keep track 
of PEP 218 then AddingABuiltInSetObjectType.  But that's just my 
preference - I'd rather have a good clear title and simple identifier 
than a funky identifier built out of a title.

Now - all of these organizational views you're talking about are good 
and valid, but Wiki organization techniques tend to make maintenance 
tricky.  You have to remember a funky WikiName in order to be 
categorized properly.

>       subprojects
>         subproject1
>             Managers
>             General idea (gives a quick view for what this project is
> intended and how it fits in the global project)
>             Case Studies
>             Status
>
>         subproject2
>
>         subprojectn
>
>    [The subproject pages should be maintained by the project managers]
>
>    CurrentStatus
>        shows an overview of all the subprojects:
>            something like a table:
>                  * with the name of the subproject (link to the actual
> subproject)
>                  * project managers
>                  * the date it started
>                  * date latest change
>                  * the phase it is in
>     [ CurrentStatus is something the maintainers of the Wiki should 
> regulary
> update, by looking at the subprojects]

This is something that should be done, but never is.  When I did the 
initial WebDAV WriteLocking project, I decided that I would be a 
shining example of a Wiki maintainer because I HATED every Wiki I came 
across - there were too many links to click on, and most of them were 
dead ends.  But, as the project went along, the Wiki and the actual 
project got further and further apart and I eventually fell prey to 
everything I hated.  Having all of that stuff on a web page that you 
have to click, click, click, click, edit to get to, and then do the 
same thing again to update another small page, and another, and 
another, in a browser TEXTAREA, all takes time.  Nobody has time.  It's 
easy to write into a Wiki, they're hard to structure.  The more 
structure that is placed in them, the harder they are to both navigate 
and maintain.  If these things were easy, I doubt we would be having 
this discussion.

With all Wikis, I hear "well, it just needs a good Wiki gardener/editor 
to keep it in check", yet very few people ever step up to that job.  
It's not exactly easy to do (even with all of the organizational effort 
Ken Manheimer has contributed), and feels like a small responsibility 
in contrast with everything else that one has to do in day.