The attached is a draft proposed "Documentation issue reports" to provide guidelines and information to those new to issue reports. Feedback sought. The following deserve particular attention since they're my best guess:
* The use of "duplicate" status, whether it then goes to "fixed," and by whom.
* When to use attachments.
* The use of "+1/-1" and "@username" in comments are my best guess.
* Discussion of using issue reports in most cases rather than the e-mail list.
One of my perceptions is that topics sent only to the e-mail list slip through the cracks too easily. Consequently this draft proposes that people submit an issue to request to join the doc team, which I also put in "Joining the doc team" last week.
-karldied
| Comment | File | Size | Author |
|---|---|---|---|
| 999-doc issue reports.html | 4.69 KB | karldied |
Comments
Comment #1
karldied commentedNew page at http://drupal.org/node/24565, available for inspection, review, and feedback. webchick's comments elsewhere and more research solved most of the questions. Page updated from earlier draft. The idea is to describe the process so it functions efficiently and smoothly for all of us on the doc team. If there are better "best practices," I have no problem with changing or updating the guidelines.
Comment #2
karldied commentedGuidance to use status "active - needs more info" was problematic! (No wonder people like me need this page :-) ) Issues updated to "active - needs more info" don't show up in issue list with the default filter or get sent out to the e-mail list, just like issues updated to: duplicate, won't fix, by design, and closed. Fixed both this page and "Joining the doc team" /node/23367.
Comment #3
karldied commentedI propose adding guidance to use the "Category" field "support requests" option for those issues calling for documentation team "site administrator role" action:
Issue report category:
* Use "bug report" for errors.
* Use "feature request" for documentation requests, including new material and policy changes.
* Use "tasks" when an update is in development.
* Use "support requests" for requests that require site administrator role, including joining the documentation team, deleting handbook page comments that have been incorporated, and adjusting page weight for proper page ordering.
Comment #4
karldied commentedUpdated page to use "support requests" as described.
Next Q: which project drop-down choice under "Drupal project" would you prefer that spam and test handbook pages be reported against: "Documentation" or "Drupal.org webmasters"? (As a handbook maintainer, I don't normally peruse the latter, but can certainly learn to look prior to submitting an issue.)
How about removing incorporated comments, and re-weighting pages?
Comment #5
karldied commentedAnswer: Use "Drupal.org webmasters" to delete spam and test handbook pages. Reasoning: Keep all spam, test, and flame delete requests together rather than having forum moderation requests in one place on handbook requests in a different place. Someone who is not a Documentation maintainer role is likely to put the issue on Drupal.org webmasters. They are better all together so that it is easier to search and determine if the request is already submitted.
Keep removal of incorporated comments and re-weighting pages in "Documentation" project.
http://drupal.org/node/24565 udpated.
I'm ready to mark this issue as fixed. There might be some details for submitting issues against embedded doc that would be good to add, but I'm not familiar enough with the topic yet.
Comment #6
karldied commentedDone. Thanks for all the good input and feedback.
Comment #7
(not verified) commented