Sometimes, a well meaning, but ultimately unfruitful, comment can derail an issue's purposes and have a snowball effect for hurting people's feelings.
Project Issue could help with comment validation and workflows, but the underlying factor of etiquette is a matter of interpersonal relations and personal skills of maintaining appropriate level of dialogue and quelling discontent when things take a turn for the worse.
The DCOC provides a foundation of good standards and is a valuable tool for defining the nature of the community, however it seems that a it doesn't provide enough concrete recommendations for maintaining useful discussion. So adding further documentation with recommendations that target all issue may provide tools that will help all users help each other more effectively.
When these problems arise, one person simply pointing another person to the DCOC may not give a clear enough picture of how they can turn things around, and canned responses can be mildly offensive especially when used improperly. Therefore, identifying situations and behaviors from groups of users and including this documentation with issue queue guides may help build a foundation for a set of recommendations to those users.
Identified situations:
* Over-zealousness on the part of contributors to battle back and forth over metadata
* Quickness from pull-requesters to "take my ball and run", fork, etc when met with resistance on the part of the maintainers
* Inflexibility on the part of maintainers, ie to "won't fix" issues instead of exploring the intents of the submitter and trying to find a satisfactory middle ground or an alternative approach
* Quickness to redefine issues without being respectful or seeking clarification from the submitter
This is an example directed at maintainers:
* If you maintain a project...
- expect to be surprised from your users, both pleasantly and unpleasantly. Your early adopters are very special. They will become the heart of your project if you embrace them. Some users will wish to extend your project and even if the change doesn't strike you as an improvement, it may be because you haven't reached far enough in your dialogue to find something that would be beneficial to you, your users, and a subset of users who ask for a change. The important characteristics of a good maintainer are flexibility, good leadership, and commitment to the cause.
--- Original summary:
Is there an "official" policy or guideline for changing the details of an issue? The topic starter of #966530: Securing the default login in Drupal is (IMHO) disrespectful to the opinion of the majority there. I'm not sure if anyone should take action here, I'm just curious if there is any kind of guideline somewhere.
Comments
Comment #1
silverwing commentedThere's a section in the handbook about issues http://drupal.org/node/317 (I was suprised, too!) but nothing on etiquette that I can see.)
Actually that section, like http://drupal.org/node/383956, needs a bit of cleaning since the Status' were changed (still refers to Active (needs more info)
Comment #2
heine commentedOne problem I see on a particular issue is that people use the retest feature of the testbot to 'subscribe' to issues. Unfortunately, when this is done with needs work issues, the status is changed to needs review and the issue drops out of the queue.
Comment #3
arianek commented@marcvangend nothing documented that i know of on etiquette - if you (or anyone else) want to draft something to add into that section, then we can get some reviews here and add it. we'll need to build some consensus about any guidelines that we put there, so will need to post on irc/twitter/g.d.o as appropriate.
i'm assuming it was the constant priority changing and active/closed back and forth that you were referring to as being disrespectful?
Comment #4
marcvangendExactly, a number of people had explained why the problem raised was not considered critical en why it would not be fixed in D7. The topic starter is entitled to his own opinion and as far as I'm concerned, he is very welcome to disagree and ask for clarification. Still I think that the issue status should always reflect the opinion of the majority, and not be (ab)used to emphasize the opinion expressed in a comment.
Comment #5
arianek commentedgotcha. so yes, if someone wants to write up a proposed guideline and get some consensus on it, we can definitely add that to the docs.
Comment #6
Matto commentedI think an issue queue etiquette section would be very valuable.
marcvangend wrote: "the issue status should always reflect the opinion of the majority, and not be (ab)used to emphasize the opinion expressed in a comment." That sounds like some pretty good guideline text right there (to address that particular issue).
Some things to consider covering in terms of etiquette:
* Creating an issue (the originating post)
* Responding to the originating post
* Replying to responses
* Guidelines for all the actions above for: the issue originator; "ordinary" respondents; respondents with special status, such as maintainers of the project being "issued" and drupal.org webmasters.
* Length and number of comments you post in an issue thread (is it better to post "fewer, more comprehensive" or "more, shorter"?)
* Generic forum posting stuff like profanity, shouting, etc.
* The guidelines should be informed by the strategic objectives of the Drupal community (I don't know what they are, exactly, but I imagine they include the goal of not scaring away potential new contributors, for example.)
Just some quick thoughts there. I'd be happy to help with this, but I don't have much experience using the issue queues here or anywhere else.
Comment #7
arianek commentedmatto - as far as etiquette goes, i think you're on the right track with that list!
as for where to put this, we can put it with the issue queue guidelines, but maybe should also link to it from the code of conduct? http://drupal.org/dcoc
Comment #8
DrewMathers commentedI would like to refocus this issue on the matter of updating existing issues. For creating new issues, How to make an issue report describes this effectively. Rather than laying out guidelines, that page discusses etiquette in terms of how it will get your issue answered (or not).
Wikipedia has an interesting technical solution to users petulantly reverting one another's changes. It's called the three-revert rule. Wikipedia suspends the offender's access, but Drupal.org could lock comments or restrict settings changes to project maintainers. Taking this further would require opening an issue in the Project Issue Tracking module queue.
For explicit guidelines for updating issues, one that comes to mind immediately is "Don't hijack existing issues with a new question". I use some standard text for this. After answering the user's question:
Comment #10
mitchell commented#8: There are a couple of issues in Project Issue related 'Guidelines for updating issues,' however they are more targeted at structural changes (technical solutions) to Project Issue, like #66806: Don't let regular users re-open closed issues & #441004: Finite state machine (FSM) for issue status. I'm not sure of an issue for updating docs pages that define expected workflows, but there are a number of guides on how to use the issue queue that could be recompiled and improved for this. I'll see what I can do for that in another issue.
Edit: #1308176: [meta] Battle plan for stopping spam/"subscribe"/"+1"/"thank you" comments (and cleaning up old ones from the db too). is another technical solution for comments that don't advance the purpose of an issue.
---
This issue seems more appropriate for improving the level of conversation in the issue queue, so I updated the issue summary to focus on etiquette.
I read over the originally linked issue and included 'a situation' in the edited summary. In general, I think think linking to issues here wouldn't be as good as dissecting them in the abstract. To link to them might just reinvigorate old arguments.
Comment #11
mitchell commentedNew home.
Comment #12
webchickMoving to the new Drupal Community Working Group issue queue.
Comment #13
drumm#2011334: Adding report spam link to comments in forums is an example of a derailed issue. We could do better by
Comment #13.0
mitchell commentedRe-centering discussion on etiquette
Comment #13.1
mitchell commenteda
Comment #14
rachel_norfolkHi,
As we are looking to place more issues describing the governance of the CWG here (as opposed to the actual activity of the CWG), I’d like to do some “tidying up”.
Can you please describe what actions are needed to close this issue for you? Would you be happy for me to mark as “Closed (fixed)”?
Thanks
Rachel, CWG
Comment #15
gisleIn comment #1, silverwing wrote:
If you now look in the right margin of that page, you see a link with the text "Issue Queue Etiquette". It was added in 2012, so it wasn't there when silverwing commented, tho'.
I am sure it can be improved (be bold!), but I think that the participants in this issue should know about its existence,
Comment #16
gdemetWe're working on creating a set of templates that has language that can be used to "nudge" people in the right direction in the issue queues and Slack. Adding that as a related issue.
Comment #17
mitchell commentedI re-realized after 7 years that it's important to give entire fields of study and practice thorough analysis, working with good models. Sometimes interesting times/things get in the way.
Please check out my latest work on issue queue workflows and other flows in the Speakeasy Solution Stack Issue Queue, with its fields and labels that matching well with our needs through Speakeasy Issues App using Rolling Projects' Issue Queue Labels.
Comment #18
gdemetClosing out this very old and long-ago fixed issue. The issue queue etiquette page at https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... addresses the concerns that prompted this issue.