- 1 Goals
- 2 Policy
- 2.1 When should Community Relations be involved in conflict resolution?
- 2.2 Disciplinary action and resolution
- 2.3 The Policy for Resolution of Conflicts
- 2.4 Ethical Considerations
- 2.5 Miscellany
The stated goal for Community Relations is to act as a meeting point for Gentoo developers and users both. Community Relations is concerned with both intra-developer relations as well as forming relations with advanced users and prospective developers.
Community Relations is responsible to assist in inter-developer and developer-user conflicts. While conflicts serious enough to require Community Relations involvement are rare, it's inevitable that developers and users will clash to varying degrees. It's essential that the Community Relations team find fair and impartial resolutions to inter-developer and developer-user problems. Although all situations differ and exercising good judgment is necessary, these guidelines are intended to define the most acceptable course of action.
In addition, while Gentoo has an established CoC for years, it occasionally tends to be ignored. Via its Proctors subproject, one of the goals of Community Relations is to ensure that everyone involved sticks to it.
When should Community Relations be involved in conflict resolution?
Developers are encouraged to try to solve the issue among themselves in a civil manner before they reach out to Community Relations. 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 Community Relations involvement.
Community Relations becomes involved after all other attempts to solve the issue have failed. To involve Community Relations in your issue please send an email to comrel_at_gentoo_dot_org or open a bug and assign it to Community 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. A Community Relations member acting as mediator should make clear that he or she is taking control of the conflict in order to prevent miscommunication. This does not mean that the Community Relations mediator in control may not ask others for assistance, nor that they should make a decision for the involved parties. The purpose of a 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 Community Relations members; this process is detailed in the Policy and Process sections below.
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 are as CoC violations primarily scope of the Proctors subproject, and involve Community Relations only in case of repeat offenses or appeals against disciplinary action.
Disciplinary action and resolution
For escalated conflicts, disciplinary action must be decided on a case-by-case basis by Community 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 Community Relations project.
If an issue is deemed critical, the developer in question may have his or her access suspended while a vote takes place. In such situations, the Community Relations lead may act without a vote of the remaining Community Relations team; this power is granted by the Council. The critical issue action of the team lead must be confirmed (or annulled) by a subsequent Community Relations team vote.
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 Community Relations Lead or by Infrastructure, for security-related issues, issues which would endanger Gentoo, or which would endanger 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 shall be notified. Additionally, the entire Community 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 Community Relations lead(s).
The Policy for Resolution of Conflicts
What kind of disputes should be escalated?
A developer whose behavior is believed to be a negative influence for the Gentoo community. This includes any inappropriate action conducted by a developer. Any other conflicts of a non technical nature involving two or more developers. 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.
Once a complaint is sent to Community 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. Community 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 Community Relations for a vote.
Disputes between developers are first assigned to a member of the Community 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 applicable.
Complaints that do not require mediation per se are dealt with exclusively by a vote of the Community Relations team. Problems for which mediation has been unsuccessful are also escalated to a vote of the Community 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 Community 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 Community Relations team is given two weeks to vote on the matter. The two week period allows members of Community Relations to ask questions to either party as applicable. The Mediator to the issue is not excluded from voting. The Community Relations Lead may only cast a vote if a tie-break is needed.
The Process for the Resolution Conflicts
A member of Community Relations will be tasked to try and resolve disputes covered by this policy. Should such mediation fail, Community 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 applicable.
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 Community 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 Community Relations members to vote in a particular direction.
To illustrate this, if there are currently 12 members in the Community 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 Community Relations Lead will cast the deciding vote.
Resolution and Appeal
Any party to a dispute resolved by Community Relations may appeal the resolution to Council. No other developer may appeal.
Council may decide to override the Community 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 Community Relations with the appeal process being the same.
If a party to a dispute is also a member of Community Relations, that person may have no role in the dispute resolution process except as a party; forfeiting their vote if a Community Relations vote is held. It is the responsibility of that person to immediately inform Community 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 whole.
Complaints raised about any member of Community Relations may be raised to the Community Relations lead(s) or to Community 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 members.
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 directory (/home/username). This file will contain the details of your absence, your expected ETA to return... 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. After 60 days the developer will be considered as a candidate for being retired following policies stated by Project:Undertakers.
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 up. 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.