PEAR support etiquette

Hi, I wonder if we could talk a bit about how support is rendered in PEAR on the bug tracker and on the mailing lists. In general, I think we're doing a good job. Let's get that out there right now. The most important act we can do in PEAR is to fix problems, write code, and get on with our lives. Recently, I have heard rumblings about the way bugs and support issues are handled through php.net, and to a certain extent, through pear.php.net, although not at the same level of discontent. I would like to actively counteract that problem, if possible If it becomes necessary to mark a bug "bogus," I'd like to suggest a few guidelines: 1) always explain why you're bogusing it in calm, friendly terms. "I'm marking this bug bogus because I can't reproduce it, and suspect there may be a problem in your local configuration. Please mark the bug as "Open" if you manage to find more information that I can use to reproduce the bug" 2) always refer users to the pear-general mailing list for bugs that are really support queries, and try to answer their question if you can. "I'm marking this bug bogus because the problem appears to be a misunderstanding of how include_path works. In your case, you need to locate php.ini (either run phpinfo(); in a web-based script, or "php -i |grep php.ini") and add this line: include_path=/path/to/pear In the future, I think you will find pear-general@lists.php.net to be a wonderful support resource. Ask questions there, and PEAR developers and users can help figure out the problem" 3) if you think the problem is caused by a new bug in PHP itself, please post a message to internals@lists.php.net in this format: "Hi, A user recently reported a bug for PEAR package <Packagename> that looks to me like it is actually a bug in PHP version X.X.X. Could someone take a look at the bug report: http://pear.php.net/bugs/XXXX and let me know if this is indeed a bug in PHP? Thanks, YYYY" Then, and only after you have confirmation, should you mark it bogus. PHP and PEAR as a whole was recently attacked rather unfairly in a hasty user's blog post because I marked a bug as bogus that looked to be a weird PHP bug, when I should have asked first on internals. Oh well, live and learn. If you know a user's problem is caused by an existing bug, link to the bugs.php.net bug report in your bogus message. In general, I think this rule should work: proofread your support responses, whether they are a bug or an email. Proofread for tone as well as for content. It's far more annoying to get into a 20-message flamewar than it is to proofread once. I'm not trying to point fingers here (well, except for my own mistakes, I guess), my main goal is to find subtle ways of improving PEAR that do not get in the way of the most important thing: development. Thanks, Greg