Developer Relations Policy Guide
Conflict resolution policy
While conflicts serious enough to require Developer Relations involvement are
rare, it's inevitable that developers will clash to varying degrees. It's
essential that the Developer Relations team find fair and impartial resolutions
to inter-developer problems. Although all situations differ and exercising
good judgment is necessary, these guidelines are intended to define the most
acceptable course of action.
When should developer relations be involved?
Developer Relations should only be involved in a conflict when other attempts
to solve the issue have failed. Developers are encouraged to try to resolve the
issue amongst themselves in a civil manner. Developers within a project
engaged in a personal conflict may wish to consult with the project lead.
Although leads are not necessarily qualified to resolve personal disputes,
technical issues resulting in conflict can often be resolved within the project
without Developer Relations involvement.
Developer Relations becomes involved when the above two methods have failed. To
involve Developer Relations in your issue please send an email to
firstname.lastname@example.org or open a Bug and assign it to Developer
Relations; either is acceptable. Please note that opening a bug is not
necessary for mediation, however the developer may open a bug if he/she wishes
to do so; opening a bug is mandatory if mediation efforts fail. Developer
Relations includes a team of developers who work with the conflicting parties
to resolve the conflict, these members are deemed mediators; the Developer
Relations Mediator who takes this role should make clear that he or she is
taking control of the conflict in order to prevent miscommunication. This does
not mean that the Developer Relations Mediator in control may not ask others
for assistance, nor that they should make a decision for the involved parties.
The purpose of the Mediator is to assist in mediating discussion to aid in a
mutually agreed upon resolution. If all attempts at mediation fail, the issue
is escalated and a decision will be made by majority vote of Developer
Relations members; this process is detailed in the Policy and Process sections
Issues not necessarily related to personal conflict, such as intentional or
repeated policy breaches, malicious or abrasive behavior to users or
developers, or similar developer-specific behavioral problems should be brought
directly to Developer Relations via email@example.com or via a
Bug. These issues may bypass mediation and immediately be escalated to a vote
by Developer Relations for the appropriate course of disciplinary action.
Disciplinary action and resolution
What Action May be Taken
Disciplinary action must be decided on a case-by-case basis by Developer
Relations. For the majority of situations requiring disciplinary action, a
warning is enough to correct future behavior. If behavior does not improve, a
probationary period with revoked access to Gentoo infrastructure of two weeks
to one month is appropriate. If upon restoration of access negative behavior
re-occurs, removal from the project will be necessary. In extreme cases,
suspension or removal may be necessary upon a single offense. Except in
critical situations where immediate action is required, such disciplinary
action is determined by members of the Developer Relations project. If the
issue is deemed critical, the developer in question may have his or her access
suspended while a vote takes place. In such situations, the Developer Relations
lead may act without a vote of the remaining Developer Relations team; this
power is granted by Council. In the event of such a case, process for
the resolution of the conflict may be bypassed altogether, a decision may be
made, and any disputes would then be raised to Council per the below appeal
process. The critical nature of an escalation may be determined by the
Developer Relations Lead or Infrastructure, for security-related issues, that
which would endanger Gentoo, or our reputation. An issue that is deemed
critical does not need further justification in addition to stating which of
the above situations it falls under.
Upon removing a developer, the gentoo-core mailing list should be notified.
Additionally, the entire Developer Relations team is informed via email of the
issues that led to removing or suspending a developer, and this information is
stored on the bug. Developers who are removed from the project may not reapply
for developer status without the approval of the Developer Relations lead(s).
The Policy for Resolution of Conflicts
What kind of disputes should be escalated?
- A dispute involving Code of Conduct, or similarly themed violations,
involving two or more developers.
- A developer whose behavior is believed to be a negative influence for the
Gentoo community. This includes any inappropriate action conducted by a
- Any other conflicts of a non technical nature involving two or more
Any conflicts that are purely technical should be addressed to QA and they will
be handled according to GLEP 48. If a technical issue is turned into a personal
issue, it would then be applicable. Please note, any conflict where a
developer wishes to report a user should be escalated to User Relations.
Once a complaint is sent to Developer Relations, the team assumes
responsibility for coordinating all aspects of the complaint. The team must act
in accordance with the following guidelines:
Mediation efforts are not intended to be transparent to the developer
community. Developer Relations respects the privacy of the developers whom we
work with; accordingly there can and will be mediation efforts made without
being made public knowledge to the rest of the developer community. Regardless
of private or public knowledge mediation, all mediation efforts will be
confined to a window of 4 weeks. If mediation has not proven successful by this
time, regardless of reason, the issue will be escalated to Developer Relations
for a vote.
Disputes between developers are first assigned to a member of the Developer
Relations team for mediation. This step may be omitted only upon unanimous
agreement among the mediation members, and only if no such member has already
attempted mediation as described above. A bug is not required for mediation;
however a bug is required if mediation efforts have failed or are not
Complaints that do not require mediation per se are dealt with exclusively by a
vote of the Developer Relations team. Problems for which mediation has been
unsuccessful are also escalated to a vote of the Developer Relations team.
In either case, once a complaint reaches the need for a vote the parties
involved in the escalation and the mediator are given three days to supply
Developer Relations with information on the matter. While information exchange
cannot be forced, it does not indicate the matter is dropped, nor the vote
cancelled, if any party does not provide information within three days. After
the third day, the Developer Relations team is given two weeks to vote on the
matter. The two week period allows members of Developer Relations to ask
questions to either party as applicable. The Mediator to the issue is not
excluded from voting. The Developer Relations Lead may only cast a vote if a
tie-break is needed.
The Process for the Resolution Conflicts
Developer Relations includes a team of Mediators dedicated to resolving
disputes covered by this policy. Should such mediation fail, Developer
Relations will vote to resolve the issue. The information regarding the issue
will be presented by each involved party as well as the Mediator involved, if
Each party is given three days to present information on the issue, at the end
of the third day the team will review the information regarding the issue and
vote on a resolution. The team will decide which information presented is valid
for the current case and disregard information which is deemed invalid or not
applicable to the current case.
All members of Developer Relations have one vote to determine the appropriate
disciplinary action; all votes must be received within 14 days. For the voting
to be valid it requires a simple majority of all Developer Relations members to
vote in a particular direction.
To illustrate this, if there are currently 12 members in the Developer
Relations project then at least 7 members must vote in a particular direction.
This does not mean that all 12 members must vote, just that the majority of the
team must vote in a one direction, making it unnecessary for the remaining 5
members to vote as they would have already been over ruled by the majority
vote. If the vote is split 50/50, the Developer Relations Lead will cast the
Resolution and Appeal
Any party to a dispute resolved by Developer Relations may appeal the
resolution to Council. No other developer may appeal.
Council may decide to override the Developer Relations decision, this decision
would be reached by majority vote within Council, in which case the Council
decision would be respected and adhered. Repeat offenses for the same action
would be treated as such, resulting in review of possible disciplinary actions
at the discretion of Developer Relations with the appeal process being the same.
If a party to a dispute is also a member of Developer Relations, that person
may have no role in the dispute resolution process except as a party;
forfeiting their vote if a Developer Relations vote is held. It is the
responsibility of that person to immediately inform Developer Relations of the
conflict. The only way a conflict of interest is applicable is when a person
involved in the mediation/resolution process is also involved in the conflict.
As developers, we are entrusted to make decisions in the best interest of
Gentoo and set aside personal interest for the best interest of Gentoo as a
Complaints raised about any member of Developer Relations may be raised to the
Developer Relations lead(s) or to Developer Relations via
firstname.lastname@example.org for discussion at any time; a meeting may be
called to discuss the matter further, up to and including to vote to remove
Leaves of Absence
Often Gentoo developers go away on vacation, have to take a
short leave for University exams, or even go on a honeymoon. While
we applaud you for having a life outside Gentoo, we would like to
know when you leave and when you are expected to return. When
you leave, alert your immediate development group as well as
making a devaway entry.
You need to create a file called .away in
your /home/you directory. This file will contain the
details of your absence and will be reflected
at the devaway site.
That page is updated once every hour. Upon your return, simply delete
the .away file from your home directory.
An extended leave of absence is defined as inactivity for any period
of time longer than 60 days. Access to Gentoo infrastructure will very
likely be disabled during this time for security reasons. This means
that access to CVS and shell access to dev will be affected -- email
will likely not. If developer relations is not made aware prior to an
extended period of inactivity, after 60 days the developer will be
considered retired and any return will be at the discretion of the
developer relations lead(s) and the relevant project manager, if
Retired developers will have their gentoo.org email address removed from Gentoo
mailing lists to prevent mail bounces. Retired developers are responsible for
resubscribing to public lists with a non-Gentoo email address.
- Retired developers get their @gentoo.org mail forwarded for a number of
months equal to the number of years they've been an official developer rounded
- Mail will be forwarded for a maximum of 6 months.
This policy makes sure all devs will have a minimum of 1 months forwarding
matching existing policy. And a dev that's been around for ~3 years will have
3-4 months to get personal mail moved to a non gentoo.org account.