Developer Relations Policy GuideWhile 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 devrel@gentoo.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 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 should be brought directly to Developer Relations via devrel@gentoo.org 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. 2. Disciplinary action and resolution 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?
Any conflicts that are purely technical should be addressed to either QA or Council. 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 applicable. 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 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 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 deciding vote. 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 whole. Complaints raised about any member of Developer Relations may be raised to the Developer Relations lead(s) or to Developer Relations via devrel@gentoo.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. 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 applicable. 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.
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. |
|
