Develop a conflict resolution process for technical issues

Part of the problem here isn’t just who it should be escalated to, but how to go about doing it. If you look at some of the issues and discussions that have deadlocked and aren't moving forward any more they are usually rather long and complicated. So before it can be passed along I think it is important that the next step is to restate the problem and solutions. In some cases this may be enough on its own to have all parties realize they are talking past each other and aren't really in conflict at all.

Only when there is a clear summary of the arguments for all points of view should it be assigned to a "conflict resolver". Quickly thinking about it I think I would make the chain start of being: Nearest module maintainer -> Nearest system maintainer -> Release Maintainer -> Dries. With the possible addition of a list of people who volunteer to help out with these kinds of issues who might have a better skill set to achieve the decision.

I think it is also important to have some guidelines on how to resolve conflicts. There is a lot of theory out there we can reference if we want to get technical. Shortly put I feel the first step should be to get the conflicting parties together with a third-party and reset the conversation and hopefully reach a solution everyone can get behind. If that fails it falls on the conflict resolver to pick a path setup the next action item to get things running again.

If you read my patch in #1493426: Create explicit version-controled governance documents, you'll see that I propose a rotating set of volunteers/appointees I (only-half-)jokingly call hook_leader()s. rfay_leader(), Mile23_leader()...

That is, the project maintainer creates a pool of people who will automatically, on some short schedule, be designated as mediators or somehow represent a neutral viewpoint. They only have symbolic power, but if they start showing their badge it's time for the tone to change.

Technically, this could be supported in d.o, in the badge system under discussion, or as a listed role like co-maintainer on the front page. Or it could be as simple as project managers listing the hook_leader()s in an issue. The schedule for the hook_leader()s could be automatic as a function of d.o, or it could just be that they tell the maintainer they need a break.

The point is to put another role in there with the authority to demand a tonal change but not the power to hammer anyone, and also structure it so that those people don't get burned out.

This would help on the front-end, steering people away from conflict, and back towards discussion and debate.

Coming up next.... hook_leader_alter(). :-)

This or #1493430: [meta] Develop a conflict resolution process for community issues should be closed as duplicate

@valthebald I disagree - Technical and Community conflicts are different. In the end, we may decide that the mechanism is the same to resolve these conflicts. In the mean time, both should stay open.

#5: Agree, let's keep both open

In the interests of gathering some "real world" use cases, here is an example of a technical conflict: #1552384-19: Move the Queue system to Dependency Injection (Though it's also subtly a community conflict rolled in, which makes me wonder if we can truly discuss these two issues as independently as they are now.)

Various previous technical decisions that have made include moving to PSR-0 autoloading for Drupal classes, the use of a Dependency Injection Container, etc. Chx is raising concerns about the DX of a proposed change to the Queue system, which he cares more about than the language system that we've already converted to this same syntax because he wrote the original. He then goes on to suggest that this is a "fork in the road" issue where we need to discuss which approach we're going to go for: leave legacy function wrappers in place, or drop hooks altogether. I don't quite understand that dichotomy, but....

Anyway. What's more relevant here is the way in which we attempt to resolve these issues when they come up, because a similar model could work for other places. chx (as one of the maintainers in MAINTAINERS.txt who is given access to do this) assigns the issue to the project's lead maintainer. That maintainer then gets that issue added to his "My issues" for better visibility. He can either make the decision himself, or delegate the decision to others. He can also choose to let the discussion continue, but specify a date as a means of timeboxing the discussion.

This approach is outlined at http://buytaert.net/streamlining-drupal-core-decision-making and thusfar (knock on wood) seems to be working pretty well. For technical conflicts. Community conflicts are another kettle of fish. ;)

So could we extrapolate this general approach for Drupal core to an approach that could work across all projects for all manner of technical conflicts? One tricky thing is access to the "Assigned to" field is limited to maintainers for a project, so "just anyone" cannot do what chx did here. So maybe the formal process could look something like this:

In the vast majority of cases, we prefer to reach technical decisions based on an objective assessment of pros and cons, and in a collaborative, consensus-driven manner. However, there are times at which there is no clear winner between varying approaches, and/or when smart, respected people in the community are directly at odds with each other on the preferred approach.

The following process explains how to resolve this case of technical conflict:

- First, update the issue summary with a clear, objective outline of where the technical conflict breakdown is. Make sure all parties agree that the summary is reflective of the issue at hand.
- Next, hold a "real time" discussion, via IRC, Skype, or some other medium, with the interested parties, including those in disagreement. This streamlines and often improves communication and a solution may naturally emerge more readily than from a non-asynchronous written discussion. Important: Make sure to document the result of this discussion in the relevant issue.
- If this fails to yield a solution, the issue should next be escalated to the project maintainer, by moving the "Assigned" field. If you do not have permissions to move the "Assigned" field, an e-mail via the maintainer's contact form will do. # Not sure about this. Sounds really annoying. :\ But not sure what else to do. An issue tag, people won't know to check, unless #1561772: Create a conflict resolution team takes care of it and does the outreach? Hmmm.
- The maintainer at that point may do one of a number of things: a) make a decision themselves, b) delegate the decision to another, and/or c) let the discussion continue until date X, if it feels like not enough feedback has been gathered.

Definitely not perfect, but maybe could act as a starting point?

And, I guess... :)

I'm not up for an in-depth comment tonight but +1 from me to #6. I've been saying for years that every process needs someone(s) able to make a final decision if clear consensus can't be reached or difficult issues end up going to the "do nothing" side by default because no one can break the stalemate.

So this is a great policy for issues inside one specific project. Does this apply for technical conflicts between multiple projects that have multiple maintainers? Do we escalate to a resolution team? Who makes final decisions in that case? Or if this is being discussed in a separate issue?

I saw this in the queue. I have read the IS and the comments. I agree with#6 and the summation in #9.

I am marking this Fixed.