#50218 [Opn]: flock() has numerous documentation errors

ID: 50218 Updated by: danbrown@php.net Reported By: shelby at coolpage dot com Status: Open Bug Type: Documentation problem Operating System: All PHP Version: 5.3.0 New Comment: That's a fair assessment, and one that should be addressed. We constantly update the site based on suggestions from users in situations that, in all honesty, we may not foresee as part of the big picture. This is an open source project that evolves minute-by- minute, most often with suggestions and submissions by folks such as yourself being implemented over time. Our documentation team is pretty snappy at getting things accomplished quickly, and we're lucky (at least so far) that we don't face bureaucratic roadblocks like a lot of other projects can't seem to overcome. It's by no means a guarantee that the bug will be fixed within 72 hours, but there's a better chance that it will than it won't. That aside, you seriously may want to consider joining the project. You're obviously passionate about it.... why not apply that directly without having to go through a middle-man to achieve results? With no word in jest or sarcasm, the PHP project could benefit from your help. Previous Comments: ------------------------------------------------------------------------ [2009-11-18 17:00:26] shelby at coolpage dot com If it is true that documentation errors are resolved within 72 hours, then I eat my words and humbly apologize to you. If you simply added that statement-of-fact to the policy page and to the rejection email, then I wouldn't have even bothered adding the note to the manual page. I do not understand why you wouldn't make that clear on the policy, so that people will not feel like they have fallen in a blackhole, as can be the case in other social politics. Again if that is the case, my apologies. I was offended, because I have had my effort wasted too many times in past and it is unusual to see bug reports resolved all the way to release within 72 hours. I think it wasn't abnormal for me to assume otherwise. Please consider clarifying your policy page, so that bad feelings can not forment from misunderstandings. I can not read your mind. You have to state it. ------------------------------------------------------------------------ [2009-11-18 16:49:00] danbrown@php.net == KEY: > Your Comments My Responses == > In the meantime, you have many errors in > those user comments which did get approved > on that page. Talk about future housekeeping! Tell me about it! It's an ongoing effort, and one in which we'd certainly welcome the assistance of someone with as much time available as you're demonstrating in noticing the errors. We're all volunteers who donate our time to the community on a daily basis, and if you'd like to join the ranks to offer your assistance in making things better for your fellow PHP developers, it would be greatly appreciated! > Dan you have no point and no logic. But you > are good at destroying effort and chasing > away the people who do apply inspired effort. Aww, when you say it, it hurts. ------------------------------------------------------------------------ [2009-11-18 16:45:35] danbrown@php.net == KEY: > Your Comments My Responses == > Dan Brown I had already read the submission > guidelines for manual annotations, and in > fact my notation repeats some of the other > notations already on the manual page (e.g. > that LOCK_NB is a binary flag option that > can be combined with options). > > Removing my note from the manual page, > means that others will spend a whole > day of frustration trying to figure > out what I figured out, for as long as > the manual is not fixed, which who > knows might be months or even years. Not true. When a documentation bug is submitted, it is usually resolved within 72 hours. So until you know for a fact how the timing and patterns work, either join the project or don't make assumptions in how we operate, or question why we do things the way we do, thanks. > So you preference is to deny the users > the information, because they surely > won't find this bug report in meantime? My preference is to maintain a good, solid reliable presentation, and not to confuse others with conflicting or redundant information. When a documentation bug is fixed, it's not normal procedure to then sift through every annotation on the corresponding manual entry to ensure that we've updated it. One could only imagine the effort that would take. However, your estimation as to the intelligence of your peers and their ineptitude at tracking down relevant information is interesting to me. Have you frequently found yourself in situations where you are the only one with enough sense to help yourself? If you pass judgment as to the ability of those around you, my guess is that you'd find yourself quite lonely in many circles. > I put a link here in the bug report, so > who ever fixes the bug, can send an email > to the note editor to remove my note later. Links don't work that way, Shelby. They direct you TO a page, they do not report back FROM the target. So this is baseless. > Your premature deletion of my note did not > save any housekeeping effort on your part, > it merely destroys my work and hides the > information from the millions of PHP users. It was not premature, and in fact did serve its purpose in housekeeping. Further, please check your metrics, as "millions of PHP users" would be fantastic, but I think may be a bit exaggerated in this case. > Shame on you Dan Brown. At least you > had the dignity to post here what you > had done, so I can reply to you. Dignity is the one thing I didn't have to sacrifice on my wedding day. Now, if we were to discuss other things like personal space or sanity.... > Waste my time once, but never again. I > will withhold my contributions from PHP > from here out. It's worth noting that, within a few moments, you posted a follow-up on this report. Perhaps you meant this promise to be appended to the end of that message. > Congratulations. Thank you. It's been a long, difficult journey, but we appreciate your support. We'd like to thank the Academy.... ------------------------------------------------------------------------ [2009-11-18 16:32:22] shelby at coolpage dot com In the meantime, you have many errors in those user comments which did get approved on that page. Talk about future housekeeping! Dan you have no point and no logic. But you are good at destroying effort and chasing away the people who do apply inspired effort. ------------------------------------------------------------------------ [2009-11-18 16:25:49] shelby at coolpage dot com Dan Brown I had already read the submission guidelines for manual annotations, and in fact my notation repeats some of the other notations already on the manual page (e.g. that LOCK_NB is a binary flag option that can be combined with options). Removing my note from the manual page, means that others will spend a whole day of frustration trying to figure out what I figured out, for as long as the manual is not fixed, which who knows might be months or even years. So you preference is to deny the users the information, because they surely won't find this bug report in meantime? I put a link here in the bug report, so who ever fixes the bug, can send an email to the note editor to remove my note later. Your premature deletion of my note did not save any housekeeping effort on your part, it merely destroys my work and hides the information from the millions of PHP users. Shame on you Dan Brown. At least you had the dignity to post here what you had done, so I can reply to you. Waste my time once, but never again. I will withhold my contributions from PHP from here out. Congratulations. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50218 -- Edit this bug report at http://bugs.php.net/?id=50218&edit=1