reST, mechamisms? (was Re: [Zope3-dev] Z3 documentation)
Jeffrey P Shell
jeffrey@cuemedia.com
Wed, 2 Apr 2003 11:20:19 -0700
On Wednesday, April 2, 2003, at 09:50 AM, Stephan Richter wrote:
> On Wednesday 02 April 2003 10:41, Jeffrey P Shell wrote:
>> What would I / we need to do to start moving forward?
>
> Please, please implement/integrate reST in Zope 3. I just talked to
> Jim, and
> he said he would love someone to do this!
What needs to be done to start off? A proposal? A branch? Is there
anything existing I could/should look at before starting?
> BTW, I will make sure you are bale to use reST from the Online Help
> then!
>
>> And while narrative documentation is being developed in the Wiki right
>> now, there are plans to move it to files/CVS at some point before
>> final
>> release, right? I think it's important to tag and release
>> documentation in near-sync with shipping code. I think it's great
>> that
>> I can travel back in time to Python 1.6 documentation on the rare
>> cases
>> I still need to.
>
> Well, I would prefer the documentation to live in the Wikis, for all
> of the
> reasons I posted before. Wikis have versions too. And notice that most
> of the
> Wiki based documentation would not be as suitable for files anyhow,
> e.g. I
> would never want to write a Cookbook in CVS files.
I've never had a good experience with documentation kept in Wikis. I
find them to be a good supplement, but after a few years of use, the
information is so mixed between relevant and irrelevant that I often
end up leaving in frustration. They become unbelievably hard to
navigate and are full of broken promises - links to barely filled out
or useless pages. I've always wanted to learn Squeak, but get so lost
in its Wiki that I can never stick with it. ZPatterns was the same way
- there was very useful information in the Wiki, but it got so tangled
up that narrative was lost - in many cases it felt like there were more
links than words. requiring a lot of clicking and backtracking in
order to understand a simple concept.
If we can keep that from happening, then I don't mind. People say a
Wiki is as good as its gardeners, but I somehow keep coming across all
the weeds. :\
So, I think its a good supplement, but I feel that it's no replacement
for real managed documentation. I don't want my feelings of
frustration with other documentation wikis to be felt by others.
Those are just my concerns. There's a lot of good things that a Wiki
gives, I'll grant that. But so much care has to be taken to ensure
that:
- Documentation is always current, but doesn't go
beyond shipping versions of the code. If we're
six months away from Zope 3.1, but documentation
already reflects Zope 3.1 changes and its
causing breakage or yielding unexpected results,
people will get frustrated and leave. Yet we
do need to be able to update docs while new
versions of the software are in development
so that there's no big flurry of activity at
release time to try to update.
- If the current version is Zope 3.3, for example,
but someone is still running Zope 3.0 and can't
move beyond it for various reasons and needs
to do maintenance, they should be able to easily
find the Zope 3.0 documentation and stay within
that range. Versions on single documents won't
help here.
Good local online help and API documentation
might be a way to mitigate this risk.
- Links in documentation don't take people to
antiquated design documents and proposals that
don't reflect current code without EXPLICIT
warning. It's very frustrating thinking you'll
find documentation about how the event system
works and instead find a two year old document
discussing how one MIGHT work. This is my
biggest concern if the documentation is mixed
in with the rest of the code, as it was a
frustration I felt early on.
- No pages titled "ObjectHub" whose only content
is "An object hub is a hub with links to objects".
I see pages like this (and have authored them
myself) where the author might think they'll
come back later and fill things in, or hope
someone else will, and many months later it's
still an empty page.
- Pages are narratives, and not just a couple of
paragraphs full of links to more pages with just
a couple paragraphs full of links. It's too much
clicking, backtracking, and clicking again, just
to grasp a basic concept.
I think most of these are pretty common sense things [1], but they
still seem to get forgotten. :\. I just wanted to raise these issues
now so that we're mindful of them.
[1] http://zwiki.org/ExcessiveLinkingConsideredHarmful
> However, I really want the OnlineHelp to live in reST space. In fact,
> the
> reason I have not written any more OnlineHelp screens is because of
> the lack
> of reST.