| 1 |
This is not a formalized policy doc but rather a proposal for such. All |
| 2 |
input is welcome, please try to keep it mellow :) |
| 3 |
|
| 4 |
(yes, I realize this doesn't specify how these folks are to be chosen; |
| 5 |
the consensus in devrel at this point is a devrel vote for each person |
| 6 |
& working out conflict of interest problems on a case-by-case basis but |
| 7 |
this is also a matter for discussion) |
| 8 |
|
| 9 |
|
| 10 |
Conflict resolution policy RFC |
| 11 |
15 Apr 05 avenj@g.o |
| 12 |
|
| 13 |
-- Introduction |
| 14 |
|
| 15 |
The current devrel policy has many commonly accepted flaws, not the |
| 16 |
least of which is the unnecessary complexity and overly long time needed |
| 17 |
to resolve complaints. |
| 18 |
|
| 19 |
Devrel's resolution policy does not need to be complex to serve our needs; it |
| 20 |
needs to be transparent, flexible, and nimble. It needs to be able to quickly |
| 21 |
address small problems before they become big problems. It needs to be |
| 22 |
able to recognize and address poor patterns of behavior within Gentoo. |
| 23 |
It needs to be able to pursue these goals while also addressing the |
| 24 |
concerns of developers who believe devrel may act unfairly, thus |
| 25 |
openness & options for appeal are essential. It must additionally |
| 26 |
meet these goals within a reasonable timeframe, else problems escalate |
| 27 |
and produce a negative effect on morale. |
| 28 |
|
| 29 |
In short, this proposal seeks to accomplish a few specific things: |
| 30 |
* separate conflict resolution into a clear subproject to help |
| 31 |
refine the devrel structure & clarify devrel's structure & goals |
| 32 |
* define a simple and effective conflict resolution body that can |
| 33 |
address problems in a timely manner while still producing useful |
| 34 |
results |
| 35 |
* make sure conflict resolution is done in a distinctively above-board |
| 36 |
manner |
| 37 |
|
| 38 |
I will keep this as straightforward as possible. Note that when I say |
| 39 |
'conflict resolution' I am including things that are not strictly |
| 40 |
speaking "conflicts" -- constant QA violations come immediately to mind. |
| 41 |
|
| 42 |
This is intentionally very loose. All issues are different and the |
| 43 |
matter should be handled as appropriate to the particulars of the |
| 44 |
situation; this proposed policy reflects that. |
| 45 |
|
| 46 |
I also have not specified particulars as to how complaints are filed, |
| 47 |
etc: I have tried to keep this down to the bare basics of resolving the |
| 48 |
complaint. Particular methods may vary and can be detailed elsewhere |
| 49 |
(such as a 'Filing a complaint' doc). I feel this should be strictly |
| 50 |
policy-specific and expect that under this proposal the newly |
| 51 |
created conflict resolution subproject should begin writing guideline |
| 52 |
docs to help clarify specifics and implementation details. Additionally, |
| 53 |
this team should refine this proposal into a policy document. |
| 54 |
|
| 55 |
----- |
| 56 |
|
| 57 |
Conflict resolution should become its own devrel subproject. The |
| 58 |
subproject should include one lead. The lead should |
| 59 |
primarily act in a strategic role and serve as the primary point of |
| 60 |
contact between devrel leads and the conflict resolution board. |
| 61 |
|
| 62 |
The conflict resolution lead is expected to stay involved in specific |
| 63 |
incidents but to have no voting role in the outcome except as a |
| 64 |
tiebreaker. They do, however, have influence over process and may put |
| 65 |
forth issues & proposals to the board. |
| 66 |
|
| 67 |
The board itself should be composed of four individuals. The board is |
| 68 |
responsible for coordinating all aspects of the complaint. Dev vs. dev |
| 69 |
disputes should be sent to ombudsman for mediation; overriding the |
| 70 |
ombudsman step should be only by unanimous decision by the board. |
| 71 |
Complaints that do not require mediation per se (such as repeat QA |
| 72 |
problems) can be dealt with exclusively by the board. Problems ombudsman cannot |
| 73 |
resolve will be returned to the board. |
| 74 |
|
| 75 |
If an issue is returned to the board, it is up to the board to determine |
| 76 |
a method for resolution. Meetings will be arranged at the lead's |
| 77 |
discretion or by majority vote of the board. |
| 78 |
|
| 79 |
The board should be expected to act in a timely manner; time limits are |
| 80 |
impossible to define with any sort of accuracy, but unnecessary delays |
| 81 |
are unacceptable. As such, if the board is unable to arrange IRC |
| 82 |
meetings at a convienent time for all involved without undue delays, |
| 83 |
e-mail is considered an acceptable method of working through complaints. |
| 84 |
In either case any official proceeding including board meetings and |
| 85 |
voting sessions must be made public. Discussions with involved parties |
| 86 |
with the intent of mediation can be considered private at the request of |
| 87 |
either involved parties or members meeting with said parties; |
| 88 |
conflict resolution leads are expected to handle the release of logs |
| 89 |
or emails to the gentoo-devrel mailing list and maintain an |
| 90 |
archive of these documents. In the case of private discussions, a |
| 91 |
summary of the non-sensitive aspects of the discussion should be |
| 92 |
provided. |
| 93 |
|
| 94 |
Once a final determination is produced by the board, any appeal to their |
| 95 |
decision may be made to devrel leads. An appeal made to devrel leads may |
| 96 |
be immediately vetoed to the council or put to the devrel mailing list |
| 97 |
for a vote within three days. Any appeal rejected by devrel may be made |
| 98 |
to the council to be voted on by elected representatives. Only the |
| 99 |
developer acted upon by devrel may appeal. |
| 100 |
|
| 101 |
-- |
| 102 |
Jon Portnoy |
| 103 |
avenj/irc.freenode.net |
| 104 |
-- |
| 105 |
gentoo-devrel@g.o mailing list |
Archives