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@g.o
 
-- 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@g.o mailing list