Re: PHP style Annotated Manual
От | Dave Cramer |
---|---|
Тема | Re: PHP style Annotated Manual |
Дата | |
Msg-id | 001f01c09949$09138370$c201a8c0@orgl1.on.wave.home.com обсуждение исходный текст |
Ответ на | PHP style Annotated Manual ("Sam & Lisa Snow" <2snows@mailandnews.com>) |
Список | pgsql-general |
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 > > > > >
В списке pgsql-general по дате отправления:
Предыдущее
От: "Dan Wilson"Дата:
Сообщение: Re: Re: SELECT (sometimes) returning Zero Rows? Fixed, sort of...