Re: Re: note 87919 rejected and deleted from function.define by notes editor thiago

Martin, If you think you can do a better job in this hectic, all-volunteer group, I invite you to join the team and contribute. We would welcome the added talent and passion! This officially ends this discussion. On Tue, Dec 30, 2008 at 16:29, Martin N Brampton <counterpoint@aliro.org> wrote: > Hello > > I'm sorry, but this is plain silly. I have just reread the notes that > appear when you click on "add a note" in their entirety. > > Let me work through the prohibitions in reverse order: > > Questions: I did not ask any questions. Please note that every sentence > that I wrote is either an assertion or an imperative. Nor did I need > support of any kind, which is the only reason given for using a mailing > list. > > Comment on lack of documentation: Nothing I said related to the PHP > documentation in any way whatsoever. > > Report a bug, request a language change or feature: Nothing I said requested > anything at all. So I have to suppose that you want to claim that a > misleading note is a bug in PHP. This is so extraordinary an > interpretation, I cannot imagine anyone ever thinking of it. One thinks > primarily of bugs as existing in software, possibly by extension in the > official documentation. To regard a mistaken user contribution as a bug > seems to go way beyond any normal usage. > > - - - > > The note on which I commented is factually inaccurate, yet still present in > the documentation. If you are moderating user notes, I cannot understand > how such a blatantly mistaken note ever got published in the first place. > It's been there for more than 2 weeks without any action being taken. I > was shocked when I read it. Even if a moderator didn't understand the > precise issues, surely it is highly unlikely that such a substantial defect > as is alleged would actually exist? Would it not make sense to investigate > before allowing its publication? > > It is madness to allow one click addition of incorrect information, and then > require that its correction should go through an elaborate procedure, for > which no information or straightforward link is actually provided anywhere > near the original note. > > And there are most certainly published notes that correct errors in earlier > notes. > > If you want errors in notes to be dealt with in a different way, then the > obvious course of action is for you to provide a simple one-click option for > notifying defects, and to clearly document it early in the already > excessively long instruction page. > > - - - > > It is beside the point whether the rejection notice is intended to be > contemptuous. The fact is that on any normal reading (by a native English > speaker) it is simply irrelevant to my submission, and certainly comes over > to me as rude and highly discouraging of any participation in attempting to > improve the PHP documentation. > > And in the same vein, the remark discouraging submission of regular > expressions to validate email addresses is an appallingly smart alec > patronising comment that is inappropriate to any serious project. > > I won't want to make the mistake of trying to help another time. > > Regards, Martin Brampton > > > Daniel Brown wrote: >> >> On Tue, Dec 30, 2008 at 14:13, Thiago H. Pojda <thiago.pojda@gmail.com> >> wrote: >>> >>> Martin, >>> >>> IMO your note is good. >>> >>> Your note was rejected for a bigger reason than just removing it from >>> the notes section. >>> >>> I rejected it to make you bring this up on PHP mailing lists to >>> discuss it and then, if decided so, add a observation to that into the >>> real docs. I'll be deleting the others about this subject soon. >>> >>> You can report it as a bug, if you will. >> >> Thiago is correct, Martin. And while the canned email sent upon >> rejection seems a little harsh, it's meant to be direct, as a good >> portion of the user note submitters from the community are not >> native-English-speakers. It's certainly not meant to be read as >> contemptuous. >> >> Essentially, a rejection is a reminder that corrections - even to >> user notes - should be reported using means other than the notes >> submission form itself; in the future, if you submit this as a bug to >> http://bugs.php.net/ with either a link to the note or the >> note >> number, it will be handled as appropriate. The offending note will >> then be corrected (with credit to the user who supplied the correction >> noted therein) or removed from the manual entirely. >> >> In any case, thank you very much for your submission, and have a >> great new year! >> > > -- > PHP Notes Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- </Daniel P. Brown> daniel.brown@parasane.net || danbrown@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Unadvertised dedicated server deals, too low to print - email me to find out!