Thread: PHP style Annotated Manual

PHP style Annotated Manual

From
"Sam & Lisa Snow"
Date:
I did a small bit of research on the PHP style of annotated manual. From
their documentation mailing list archives I was able to find out where to
get the source and some other discussion about it.

As long as the comments were moderated and rolled into the main manual
periodically, I think the system is great.

More thoughts? Any takers? Their system is based on MySQL, so it would take
a small porting effort. ;-)

Sam



===================


Follow the instructions on http://cvs.php.net to check out "phpweb"
instead of "php3", and you'll have the source for the enire website.

 - Stig

======================

List:     phpdoc
Subject:  Re: [PHP-DOC] Dealing with the PHP manual annotations (was Re:
From:     Ron Chmara <ron@Opus1.COM>
Date:     2000-07-28 4:06:07
[Download message RAW]


A mini-summary of one exchange, first:

> > > The developers have expressed doubts about giving out CVS accounts.
> > I agree with them on this; handing them out left and right would make me
a
> > bit nervous, too.
> > > Alternately, the annotation system could be modified, but this would
take
> > > some time.
> > The annotations are stored a MySQL table. Perhaps the easiest approach
might
> > just be to add some sort of "editor reviewed" column to the database and
> > creating a separate page that would display unreviewed notes so that a
> > designated annotation editor (or group) could easily keep on top of new
> > notes.
> > > > I think a quick trip through the php-general archives
> > > > and the FAQ/KB listings would turn up some knowledgeable candidates
who
> > > > could be trusted for this sort of thing.
> > > I would guess that making a letter that invites people to help out on
this
> > > project would be the best way to do this?
> > What do you think about working with the doc team to establish either an
> > editor or review group and then sending out a message encouraging people
to
> > submit dubious annotations for review? Kind of like what is currently
being
> > done with the bugs database where the QA team is helping filter out easy
> > reports to save developer time.

A few thoughts....

Scaled annotation permissions, mailing requesting management, review group,
db column changes, a review page?

It's starting to sound a bit excessive for implementation of what is pretty
much a simple issue (cleaning up the annotations, which are db records).

How about:
1. Annotations themselves have feedback, at the bottom of the annotation
list.
This is either per section, per page, or even simpler, *an email addy
aliasing
to the annnotated manual doc folks*. This builds the communication channel,
simply an effciently, and increases user feedback. (Let the users of the
docs
handle the crawl as well)

First implementation is adding a single line to the annotation loop, of the
form:
<?php
echo "mailto:manualtenders@php.net";
?>

Or whomever that mail alias should point to.

(Someone might want to fix the "http://www.php.net/manual/about-notes.php"
URL
while they're at it, too...)

It can go into a group IMAP box, a mailing list for debate,
whatever,*later*.
It may be split into whatever groups commitees, scaled permissions,
hierarchial \
ownership trees, etc.  But email is simple enough to do _now_. If you want
to get \
fancy, you can put a mailto on each notation, so you can pick up the record
id in the \
loop in stick it in the subject.

The point of splitting the smaller tasks out is to get smaller, faster,
progress,
and a follow up review commitee is just asking for poilitical bureacracy to
get
in the way of, well, deleting messages, leaving others and deciding what to
send
upstream for actual manual edits.

2."We don't need no steenking CVS access". It's a web db. There's already an
interface for message building. Adding an update/delete page is equally
simple.

Worried about concurrency? Use the read or move of an IMAP box to indicate
that somebody has "checked out" the problem. The edits aren't 4 day debug
sessions,
they're add/delete/email-to-the-main-doc-team (if there is, indeed, a manual
error. Shouldn't take more than 3-5 minutes for each annotation.

The annotation folks don't have to be C coders, or navigate the perms or
manage
concurrency... they have to be able to handle:
a) email in from users, and out to main doc team
b) a web page or two.
c) Maybe a password (via htaccess) to get to the proper editing page.

The entire purpose of an annotated doc-tender would be to scrape off the
useless stuff, leave the good stuff, and pass requested manual edits
upstream
to the people who have CVS doc access, or into this list, or whatever (but
keep it simple)

Count me in, if'n ya'd like the help. First page I'd go after is the
less-than-helpful slow motion flamewar on:
http://www.php.net/manual/function.substr.php....

----Snippet:
> brian@vinylbaby.com
> 19-Dec-1999 07:55
> I am sorry I started this. I was trying to point out an error and now this
page is \
> a mess. I hope someone will clean this garbage up.
----

-Ronabop





Re: PHP style Annotated Manual

From
"Dave Cramer"
Date:
The wiki stuff has been ported to servlets, if that is of any interest.

--DC--
----- Original Message -----
From: "Sam & Lisa Snow" <2snows@mailandnews.com>
To: <pgsql-general@postgresql.org>
Cc: "'Richard'" <poboxcanada@yahoo.com>; "'Dave Cramer'"
<Dave@micro-automation.net>; "'Michael Ansley'"
<Michael.Ansley@intec-telecom-systems.com>
Sent: Saturday, February 17, 2001 5:34 PM
Subject: [GENERAL] PHP style Annotated Manual


> I did a small bit of research on the PHP style of annotated manual. From
> their documentation mailing list archives I was able to find out where to
> get the source and some other discussion about it.
>
> As long as the comments were moderated and rolled into the main manual
> periodically, I think the system is great.
>
> More thoughts? Any takers? Their system is based on MySQL, so it would
take
> a small porting effort. ;-)
>
> Sam
>
>
>
> ===================
>
>
> Follow the instructions on http://cvs.php.net to check out "phpweb"
> instead of "php3", and you'll have the source for the enire website.
>
>  - Stig
>
> ======================
>
> List:     phpdoc
> Subject:  Re: [PHP-DOC] Dealing with the PHP manual annotations (was Re:
> From:     Ron Chmara <ron@Opus1.COM>
> Date:     2000-07-28 4:06:07
> [Download message RAW]
>
>
> A mini-summary of one exchange, first:
>
> > > > The developers have expressed doubts about giving out CVS accounts.
> > > I agree with them on this; handing them out left and right would make
me
> a
> > > bit nervous, too.
> > > > Alternately, the annotation system could be modified, but this would
> take
> > > > some time.
> > > The annotations are stored a MySQL table. Perhaps the easiest approach
> might
> > > just be to add some sort of "editor reviewed" column to the database
and
> > > creating a separate page that would display unreviewed notes so that a
> > > designated annotation editor (or group) could easily keep on top of
new
> > > notes.
> > > > > I think a quick trip through the php-general archives
> > > > > and the FAQ/KB listings would turn up some knowledgeable
candidates
> who
> > > > > could be trusted for this sort of thing.
> > > > I would guess that making a letter that invites people to help out
on
> this
> > > > project would be the best way to do this?
> > > What do you think about working with the doc team to establish either
an
> > > editor or review group and then sending out a message encouraging
people
> to
> > > submit dubious annotations for review? Kind of like what is currently
> being
> > > done with the bugs database where the QA team is helping filter out
easy
> > > reports to save developer time.
>
> A few thoughts....
>
> Scaled annotation permissions, mailing requesting management, review
group,
> db column changes, a review page?
>
> It's starting to sound a bit excessive for implementation of what is
pretty
> much a simple issue (cleaning up the annotations, which are db records).
>
> How about:
> 1. Annotations themselves have feedback, at the bottom of the annotation
> list.
> This is either per section, per page, or even simpler, *an email addy
> aliasing
> to the annnotated manual doc folks*. This builds the communication
channel,
> simply an effciently, and increases user feedback. (Let the users of the
> docs
> handle the crawl as well)
>
> First implementation is adding a single line to the annotation loop, of
the
> form:
> <?php
> echo "mailto:manualtenders@php.net";
> ?>
>
> Or whomever that mail alias should point to.
>
> (Someone might want to fix the "http://www.php.net/manual/about-notes.php"
> URL
> while they're at it, too...)
>
> It can go into a group IMAP box, a mailing list for debate,
> whatever,*later*.
> It may be split into whatever groups commitees, scaled permissions,
> hierarchial \
> ownership trees, etc.  But email is simple enough to do _now_. If you want
> to get \
> fancy, you can put a mailto on each notation, so you can pick up the
record
> id in the \
> loop in stick it in the subject.
>
> The point of splitting the smaller tasks out is to get smaller, faster,
> progress,
> and a follow up review commitee is just asking for poilitical bureacracy
to
> get
> in the way of, well, deleting messages, leaving others and deciding what
to
> send
> upstream for actual manual edits.
>
> 2."We don't need no steenking CVS access". It's a web db. There's already
an
> interface for message building. Adding an update/delete page is equally
> simple.
>
> Worried about concurrency? Use the read or move of an IMAP box to indicate
> that somebody has "checked out" the problem. The edits aren't 4 day debug
> sessions,
> they're add/delete/email-to-the-main-doc-team (if there is, indeed, a
manual
> error. Shouldn't take more than 3-5 minutes for each annotation.
>
> The annotation folks don't have to be C coders, or navigate the perms or
> manage
> concurrency... they have to be able to handle:
> a) email in from users, and out to main doc team
> b) a web page or two.
> c) Maybe a password (via htaccess) to get to the proper editing page.
>
> The entire purpose of an annotated doc-tender would be to scrape off the
> useless stuff, leave the good stuff, and pass requested manual edits
> upstream
> to the people who have CVS doc access, or into this list, or whatever (but
> keep it simple)
>
> Count me in, if'n ya'd like the help. First page I'd go after is the
> less-than-helpful slow motion flamewar on:
> http://www.php.net/manual/function.substr.php....
>
> ----Snippet:
> > brian@vinylbaby.com
> > 19-Dec-1999 07:55
> > I am sorry I started this. I was trying to point out an error and now
this
> page is \
> > a mess. I hope someone will clean this garbage up.
> ----
>
> -Ronabop
>
>
>
>
>