List Archive: gentoo-devrel
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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 email@example.com
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
* make sure conflict resolution is done in a distinctively above-board
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
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.
firstname.lastname@example.org mailing list