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
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
Show quoted text
page is \
a mess. I hope someone will clean this garbage up.
----
-Ronabop