Difference between revisions of "Dispute resolution"

Latest revision as of 01:37, 21 November 2007

This page is a guideline for best practices in the MIT Kerberos development process. This is not a policy that must be followed. However the community has found that following the guidelines expressed here is desirable and leads to an improved chance of a good outcome.

It is strongly desirable that MIT Kerberos decisions can be made by general agreement or at least rough consensus of the community of people actively contributing to MIT Kerberos—general agreement of the Developers is desired. However such agreement is not always possible; this guideline discusses what to do when such agreement cannot be reached.

Avoiding urgency

Resolving a problem under time pressure is very difficult; the greatest past frustrations and longest-lasting ill feelings have resulted from situations where a decision needed to be made quickly. For this reason it is the responsibility of developers to do what they can to avoid putting us in a position where decisions need to be made under time pressure. Developers are expected to bring an issue forward to the community as soon as they are able to know about it. As the need for deadlines becomes apparent, those deadlines should be stated as soon as possible. When the community is put in a place requiring rapid decision that could have been avoided, it is appropriate to push back against this happening in the future. It may be appropriate to push back against forces requiring a rapid decision if those forces should have been in a position to notify the community sooner but failed to do so.

Even so, there are often cases where decisions need to be made under deadlines. Here are some strategies to keep in mind to avoid being forced to resolve a dispute too quickly:

1. Can the part of the decision that needs to be made now be separated from the part over which there is disagreement?
2. Can prioritizing the decision process, holding phone or face-to-face meetings, etc make the time available sufficient to reach agreement in the available time?
3. Can the decision be deferred somehow? For example can an API be introduced in a hidden or limited context to avoid having to make a rapid decision about a public API?
4. Can the deadline be moved or the project slipped from a release?

Seeking external input

One of the best ways to resolve a dispute is to get additional input. If there is a discussion about usability, consult others who have usability experience. If there is a discussion about performance of some API, discuss with people who have implemented and measured similar features.

Broadening the discussion

When some small part of the developer community cannot reach resolution it is often desirable to get the rest of the developer community involved. There have been multiple cases where a dispute between two people got to be problematic. When others were involved a clear resolution emerged.

Meet in real-time

People need to feel that they have been heard and that they are part of a team that values their input. Before overruling the objection of someone in Krbcore it is almost always necessary to offer to have a real-time meeting where they are listened to and where they are given an opportunity to interact with the rest of the team. At any such meeting the team should try to be present and those present should focus on understanding and considering the concerns.

If all else fails

1. If there is a consensus within Krbcore but not within the developer community as a whole, then the core team's consensus shall be the resolution.
2. If no other resolution is possible in the time allowed, then the Technical Director decides.