Modules / Issues
D.O processes
e.g. : Module Review Queue for people that do not understand why it takes so long
e.g.: Answers from people that are not well received or lack respect
Reputation
e.g.: Some tasks are quickly resolved if you know a person that knows a person.
Business Competition / Eco System
e.g.: People that move to other Drupal Companies but keep encountering their previous employers in the community.
e.g.: Working together in the community but hard competition in the work environment if the companies are from the same local community.
Contribution
knowledge stream : How to contribute and how to spread this skill
e.g. : There is a lot of process but which one should one use and why does one need to read so much.
e.g.: Lack of information can be frustrating, such as unwritten rules.
Forking
e.g.: Forking a module because there is someone that is not happy how process works and finds it easier to fork the module. There could be different reasons why.
Systemic Issues
e.g.: The U.S. Government has a law that they have to archive everything that happens in the name of the U.S. Government.
For this reason they have a user on Drupal.org that is named after the organisation.
Now, the policy forbids organisation user names and enforces every account to be a person. This is a deadlock as law and policy are collisioning.
Not acknowledging or Valuing all contribs equally
e.g.: Documentation edits are not always commits
e.g.: Translation edits that happen outside of drupal.org
e.g. Drupalcamp talks, etc…
|
“I know best”
Issue queues
IRC
e.g.: Comments and/or replies that assume the other side knows about his or her ability to not explaining him or herself anymore.
Language and culture
Due to the barriers of the language it could be that certain bits are misunderstood and were taken as offensive. Written words do not come with additional hand-gestures so it could be meant in a very different way.
Assumptions
Assuming that some people have the knowledge while they have not and depicting them on that.
e.g.: Commenting heavily on certain contribution while it was intended as a help to improve solving a certain use-case. This is demotivational and could cause conflict and build up frustration.
General Agendas (Interest, political, business wise, focus, ...)
Companies have agendas depending on the direction certain companies head to.
e.g.: A company focussed on migration will have more interest in migration modules and to fix them. They will probably have a direction they want to take that might not map with the author of a certain migration module. Person vs Company is a source of possible conflicts.
False sense of hierarchy.
e.g.: Not daring to contact “higher-up” people due to the fear that they are “too busy” or would not respond anyway.
Harassment and Bullying
Sexual comments, balance, people that feel threatened. Severe problems in such a diverse community.
e.g.: A twitter rant or a personal attack due to natures one can not do anything about.
Territorial issues
Geography & authorship
Drupal groups in the same area but they are competing. Group names that were pre-occupied by people that have nothing to do with that area and convince them to “hand-it over”
Whining in general
Commenting without constructive wording is useless
“Bad Day” factor
Sometimes someone just has a bad day and due to the digital nature it is not always clear.
Empathy and/or interpersonal skills
Not everyone is equally skilled to word their feelings into English text or are able to feel empathic and or related to one another. This should be noted and taken into account. Conflict could be avoided if this is recognized.
|
Comments
Comment #1
kattekrab commentedAdding a comment... just because we have a shiny new Drupal7 way of doing issue queues and I want to see how it works ;-)
Also - I would love some comments from other people.... so ... what do you think of this issue? How can we build all these different aspect of conflict into our processes?
Comment #2
mgiffordMy experience of conflict resolution is over 20 years old at this point.
I would think though that there would be other examples we could draw on from other communities.
Would be nice to have others for comparison.
Comment #3
myles green commentedOh how did I manage to miss this!
I think some of the 'easier' issues like Modules / Issues & Reputation could become more transparent by using a better ticketing system, like Zen Desk or Sirportly (I'm sure there are lots of other options). I just think they're more transparent, even if takes time for a module to be approved (Module Review Queue) the support aspect of it doesn't need to be managed by the developer(s) who are are dealing with the approval.
Clearly it would need a customer support team to manage this but due to the size of Drupal it makes sense to me. Just a thought.
Thanks,
Darren
Comment #4
kattekrab commentedHrmm - this might be a good one for the software working group to think about.
At the moment we are very proud of our dogfood, and we eat it often, and we love it! Suggestions for using non-Drupal tools are often met with suspicion, or criticism or worse! But we do use zendesk for conference related customer service around DrupalCon...
The Software Working Group has just put together teams to look at developer tools and community tools - I'll see if I can get Angie who sits on both the community and software working groups to make sure this idea goes to the right group of people!
Thanks for chiming in @hydrantdarren - interesting suggestion. And you're right - sometimes it is our tools we should be blaming! ;)
Comment #5
webchickIn order for me to take something to the DSWG, there'd have to be a concrete proposal here, not just an idea. :) See the top of https://groups.drupal.org/drupal-org-2014-roadmap-brainstorming for a template. Specifically, we'd want to know what the benefits and risks were, what metrics we could put in place to determine if the change is having its intended effect, etc.
If you're serious about the proposal, feel free to put it together and propose it. IMO though it'd be a tough sell to the wider community. I also don't think changing the software out is going to change the fundamental issue that it's really tough to find volunteers willing to work on this stuff, no matter how awesome the interface looks.
Comment #6
myles green commentedHey, no problem. I know what you mean but then there are lots of modules for integrating with 3rd party tools which is what Drupal does really well. So making the most of what Drupal does well seems like a sensible idea.
Happy to help with a proposal @kattekrab.
Comment #7
webchickI think for the most part this issue (in terms of defining types of conflict in our community) looks pretty done. The table looks great, thanks to all who've worked on it. I've now moved this to a documentation page at https://drupal.org/node/2227709 so it can stand as a reference.
If you have additional suggestions for the page, please file follow-up issues. Thanks!
Comment #8
kattekrab commented@hydrantdarren - I reckon it might be worth following up with a proposal to the swg as webchick suggests - probably should go to the swg queue as a general discussion, or feature request? https://drupal.org/project/software
@webchick - thanks for posting this up as a handbook.
Comment #9
myles green commentedYep its a good idea @kattekrab. I'll put some time a side to make a start.
Comment #10
kattekrab commentedThanks @hydrantdarren - ping me once you've had a chance to post something.