--- Mehdi Achour <[EMAIL PROTECTED]> wrote:
> Hi !
> 
> It's been a while since the thread [1] wasn't
> discussed, so here we go 
> again.
> After 3 months, here's the situation reviewed :
> 
> 1) - Notes posted :
>   We receive about 30 notes a day, most of them are
> :
> 
>    I   - Asking for help
>    II  - Pointing to a bug in the documentation
> (typo, something 
> missing, etc..)
>    III - Noise
>    IV  - Scripts to help other users

Perhaps II could be handled if there were an option
for the notes editors to submit the user note bug, the
same way it is deleted/rejected/edited nowadays. I and
III should be removed, and IV should be dealt on a
case by case basis, some examples might be useful
enough to make it into the manual entry's body.

> 
> 2) - Problems with the actual system :
>    I - The rejection mail is too generic and deals
> with all the 
> situations that may have caused the rejection. If
> the poster didn't read 
> all the warnings while submitting the note (don't
> post support 
> questions, don't, don't), will he really read such a
> mail ?

Yep, it is a quick hack. The idea was that perhaps if
the person did not read the first 2 times the info was
shown, it might read the third time. It did decrease
the number of junk when we started using that system,
but I agree that maybe something more sophisticated is
needed.

>    II - We see some good notes deleted, and nothing
> done. We have lost 
> one more occasion to provide a better manual.

Agree. As you mentioned in IRC, I am all for having a
way of labelling those entries to be added to the
manual.

>    III - When a note is deleted, we doesn't know why
> it was (from time 
> to time I think that the one who deleted it don't
> know the reason..)

That is true. Back when I had more time to help w/ the
notes admin, there were cases were notes that were
important were removed by a novice editor.

>    IV - We sometime rejected notes with bad-formed
> emails, it only gives 
> the mail server more work (and we know how the mail
> server suffers from 
> time to time)

Along w/ the rejection code, I had put some code to
test the validity of the email, not just using regexes
but also talking to the MX server to check that there
was a real mailbox w/ that username, but that caused
performance degradation in some cases.

> 3) - Solutions :
> 
> First shot, solving I, II and III.
> 
>    Same as proposed in [1], but a little reviewed
> (three months has 
> passed by)
> 
>    Possible actions :
>      Rejected
>      Deleted
>      To be integrated
>      Integrated
>      No action (another maintainer will maybe take
> one of the four 
> actions mentioned before)

I would add: 
       Send bug report

>    Possible reasons :
>      * Rejected :
>        - bug : Didn't you read all the warnings
> before posting ? Please 
> fill in a bug report. we can also mention features
> request here.
>        - support : have a look at
> php.net/support.php
>        - not our thing : "Hey !! why is
> www.somesite.com pointing me 
> here ???". Answer "drop a mail to the webmaster of
> this site"
> 
>      * Deleted :
>        - trash : a note that doesn't belong in our
> manual at all (spam, 
> irrelevant, wrong note, bad coded script, submitted
> twice, etc..). 
> Everything that is not part of the other reasons for
> deleting a note.
>        - integrated : the note is now in the
> official manual. We can 
> also make the script send an automatic mail to the
> submitter (he will 
> certainly be pleased)
> 
>      * to be integrated :
>        - this note is really relevant and should be
> in our manual ? mark 
> it as integrated.
>           If you have enough time/karma, add it to
> CVS, then delete the 
> note with "integrated" as reason
>           If you don't have enough karma, but still
> want to help, write 
> something and send it to phpdoc, someone will
> validate  and integrate it.
>           If you don't wanna do something more, stop
> here. A web 
> interface will allow phpdoc'ers to see the notes
> flagged this way and 
> they'll act for you.

The "integration" bit could be done as a documentation
bug report, with the advantage that there will be a
track record of the action/contents.

> Second shot, solving IV :
>    The actual system doesn't test the emails before
> sending a rejection 
> mail. We can make it do so, with a regexp and
> testing if "spam" or 
> "remove" is part of the email. This way, even if we
> make a mistake and 
> click the bad link, the mail server won't be working
> in vain.

Did someone modify the way the email is validated.
Last time I saw it, it was using a regex. Might want
to check if the regex has been changed or the
validation omited altogether in the source code.

> 4) - Discussions :
>    When I proposed [1] I recieved a lot of feedbacks
> saying : "wow, too 
> many reasons, it's gonna be horrible." This is how
> the alert sent to the 
> notes mailing list will look like
> 
> "
>    Submitter email
> 
>    The note
> 
>    ------------
>    Manual page
> 
>    Delete :
>      trash
>      Integrated
>    Reject :
>      bug
>      support
>      not our thing
>    To be integrated
> 
>    Search the note database
> "
> 
> 6 possibilities. IMHO, if someone found this to be
> too many, he doesn't 
> belong on the notes maintainers staff as he don't
> want to put forth any 
> effort. A note maintainers task is to take care of
> the manual and 
> improve it. It requires effort (private joke :
> rioter... I'm sorry =D)

I don't think it is a problem (I am even suggesting
more options ;-)

> 5) - Active maintainers :
>    Here are the list of the active maintainers for
> last months :
> 
>     - Vincent Gevers (vincent)
>     - Sebastian-H. Picklum (sp)
>     - Mehdi Achour (me, didou)
>     - Sara Golemon (pollita)
>       Managing the notes every day, integrating
> notes in the manual, 
> fixing the bugs reported there.
> 
>     - Jani Taskinen (sniper) : As he's in the front
> line in the bugs 
> reports, he sometimes walks through a manual page
> after closing a 
> related bug and hunts down most of the notes there.
> 
>     There's some people who help from time to time
> and people who have 
> helped a lot in the past. We can mention jimw,
> ronabop, zak, alindeman, 
> jmc, betz, phillip.. (sorry for whoever I'm
> forgetting)
> 
>     I would really like to hear feedback from all of
> you. Sure, everyone 
> else is welcome, especially phpdoc'ers for the "to
> be integrated" 
> proposition.

+1 on the ideas in your proposal. Look also at the
suggestions above and the ones given by Goba.
 
> 6) - Conclusions :
> 
>    I hope this time the thread won't die. I'm ready
> to developp the new 
> interface and the help of everyone is again
> welcomed.
>    The ball is in your camp, shoot it back !

I would say, go ahead and look at the existing code
and start planning for modifications. Back when I
added the kludgy 'reject' (later improved by several
others), I showed a crude working code and that helped
focus the discussion.

One thing I always wanted (and wrote code that was
never integrated for some reason), was to let notes
editors register which manual sections/pages they
would be interested in editing, that way he/she would
only recieve the emails related to those sections (of
course all the other notes will still go to the Notes
mailing list).

> Best regards,
> 
> Mehdi Achour
> 
> ---
> 
> [1] :: 
>
http://news.php.net/article.php?group=php.doc&article=%3C3F35958D.4030008%40keliglia.com%3E
> 
> PS : Thank you for the review Lateralus ;)

=====
--- Jesus M. Castagnetto <[EMAIL PROTECTED]>

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Reply via email to