Re: PHP RFC # 0001 --- List Etiquette

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Nov 28, 2007 10:48 AM, Daniel Brown <parasane@xxxxxxxxx> wrote:

>    Good morning (/afternoon/evening) all;
>
>    This is more or less an RFC-type email, hence the subject line.  I
> would like to see your comments on this case, and maybe we can forge
> some sort of agreement or unofficial treaty or something.
>
>    Oftentimes we see a user post a question to the list, with ongoing
> discussion back-and-forth on a troublesome issue, and when a solution
> is found, the subject line has an added [SOLVED] tag on it.  While
> this makes sense in a forum style arena, where posts are binded
> statically in the same group, it defeats the purpose of mailing list
> archives such as Nabble and GMANE.  A recent email from this morning
> illustrates the problem, as displayed presently at this page:
>        http://www.nabble.com/PHP---General-f140.html
>
>    The email  with the subject "The PHP License" received commentary
> from both Jochem Maas and myself, and the OP (AmirBehzad Eslami)
> replied to the message, appending the [SOLVED] tag to the subject.
> This is not a serious issue in this particular matter, as it was a
> simple thank-you message out of politeness (which is greatly
> appreciated, Amir!).  However, using just a single example should help
> to emphasize my point exponentially when you consider the frequency of
> occurrences we see following the [SOLVED]-appended route.
>
>    On 12 September, 2007, Zbigniew Szalbot posted a message to the
> list about a segmentation fault in PHP 5.2.3.  Over the next 24
> hours-plus, exactly sixty comments passed back-and-forth on the
> thread.  When a solution was found, it was posted in a separate email
> with the [SOLVED] tag added to the subject line, and two additional
> comments added to that (entirely new) thread.
>
>    Why is this such a critical issue?  Because if we hope not to have
> to answer the same questions over and over again, instructing people
> to properly STFW, then we should at least be contributing to proper
> archival and documentation of problems we've successfully solved.
> Using the aforementioned example, we check Google for the same
> problem:
>
>
> http://www.google.com/search?q=php+5.2.3+segmentation+fault+core+dumped
>
>    Hooray!  Someone else has had the exact same list of problems, and
> now I can simply go through all of the responses and it should
> (fingers crossed!) correct my issues as well.
>
>    Message 58.... 59.... getting close!.... sixty-one.... WHAT?!?  No
> solution?  Back to Google.... only to find that each result is exactly
> the same discussion, never including the final three emails.
>
>    So the summary of my proposal is as follows:
>
>        1.) An issue has been identified with the list whereby
> improper archival will likely lead to repeat questions and unnecessary
> traffic to the list.
>        2.) I propose that we discontinue the act of subject
> modification to indicate a change in status of the issue (SOLVED,
> ALSO, ANOTHER PROBLEM, etc.) unless a completely different problem is
> reached or question is asked.  This will allow a step-by-step document
> (of sorts) to be created and made "searchable" on the web.


i agree; [SOLVED] on a  separate email is nonsense; it makes perfect sense
in the
context of a forum, but not on a mailing list.  this issue has been annoying
me for sometime.
however the only problem with your proposal is the following:
new users will enter the list sporadically as they already do.  anybody who
enters the list
after this agreement is made (assuming it is universally accepted) will not
be privy to the
agreement.  also, anybody who hasnt bothered to keep up with the list today
will probly
gloss over it and also ignore (inadvertently) the agreement.

its a good idea, but i doubt well ever see it come to fruition.

-nathan

[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux