Subject: Conflict resolution policy RFC
Newsgroups: gmane.linux.gentoo.devrel
Date: 2006-04-24 18:23:25 GMT (3 years, 10 weeks, 2 days, 9 hours and 11 minutes ago)
This is not a formalized policy doc but rather a proposal for such. All input is welcome, please try to keep it mellow :) (yes, I realize this doesn't specify how these folks are to be chosen; the consensus in devrel at this point is a devrel vote for each person & working out conflict of interest problems on a case-by-case basis but this is also a matter for discussion) Conflict resolution policy RFC 15 Apr 05 avenj@... -- Introduction The current devrel policy has many commonly accepted flaws, not the least of which is the unnecessary complexity and overly long time needed to resolve complaints. Devrel's resolution policy does not need to be complex to serve our needs; it needs to be transparent, flexible, and nimble. It needs to be able to quickly address small problems before they become big problems. It needs to be able to recognize and address poor patterns of behavior within Gentoo. It needs to be able to pursue these goals while also addressing the concerns of developers who believe devrel may act unfairly, thus openness & options for appeal are essential. It must additionally meet these goals within a reasonable timeframe, else problems escalate and produce a negative effect on morale. In short, this proposal seeks to accomplish a few specific things: * separate conflict resolution into a clear subproject to help refine the devrel structure & clarify devrel's structure & goals * define a simple and effective conflict resolution body that can address problems in a timely manner while still producing useful results * make sure conflict resolution is done in a distinctively above-board manner I will keep this as straightforward as possible. Note that when I say 'conflict resolution' I am including things that are not strictly speaking "conflicts" -- constant QA violations come immediately to mind. This is intentionally very loose. All issues are different and the matter should be handled as appropriate to the particulars of the situation; this proposed policy reflects that. I also have not specified particulars as to how complaints are filed, etc: I have tried to keep this down to the bare basics of resolving the complaint. Particular methods may vary and can be detailed elsewhere (such as a 'Filing a complaint' doc). I feel this should be strictly policy-specific and expect that under this proposal the newly created conflict resolution subproject should begin writing guideline docs to help clarify specifics and implementation details. Additionally, this team should refine this proposal into a policy document. ----- Conflict resolution should become its own devrel subproject. The subproject should include one lead. The lead should primarily act in a strategic role and serve as the primary point of contact between devrel leads and the conflict resolution board. The conflict resolution lead is expected to stay involved in specific incidents but to have no voting role in the outcome except as a tiebreaker. They do, however, have influence over process and may put forth issues & proposals to the board. The board itself should be composed of four individuals. The board is responsible for coordinating all aspects of the complaint. Dev vs. dev disputes should be sent to ombudsman for mediation; overriding the ombudsman step should be only by unanimous decision by the board. Complaints that do not require mediation per se (such as repeat QA problems) can be dealt with exclusively by the board. Problems ombudsman cannot resolve will be returned to the board. If an issue is returned to the board, it is up to the board to determine a method for resolution. Meetings will be arranged at the lead's discretion or by majority vote of the board. The board should be expected to act in a timely manner; time limits are impossible to define with any sort of accuracy, but unnecessary delays are unacceptable. As such, if the board is unable to arrange IRC meetings at a convienent time for all involved without undue delays, e-mail is considered an acceptable method of working through complaints. In either case any official proceeding including board meetings and voting sessions must be made public. Discussions with involved parties with the intent of mediation can be considered private at the request of either involved parties or members meeting with said parties; conflict resolution leads are expected to handle the release of logs or emails to the gentoo-devrel mailing list and maintain an archive of these documents. In the case of private discussions, a summary of the non-sensitive aspects of the discussion should be provided. Once a final determination is produced by the board, any appeal to their decision may be made to devrel leads. An appeal made to devrel leads may be immediately vetoed to the council or put to the devrel mailing list for a vote within three days. Any appeal rejected by devrel may be made to the council to be voted on by elected representatives. Only the developer acted upon by devrel may appeal. -- Jon Portnoy avenj/irc.freenode.net -- gentoo-devrel@... mailing list