* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/devrel: policy.xml
@ 2008-02-02 14:32 Christina Fullam (musikc)
0 siblings, 0 replies; 5+ messages in thread
From: Christina Fullam (musikc) @ 2008-02-02 14:32 UTC (permalink / raw
To: gentoo-commits
musikc 08/02/02 14:32:03
Modified: policy.xml
Log:
Update Developer Relations conflict resolution policy
Revision Changes Path
1.18 xml/htdocs/proj/en/devrel/policy.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.18&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.18&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?r1=1.17&r2=1.18
Index: policy.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/policy.xml,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- policy.xml 23 May 2007 16:23:46 -0000 1.17
+++ policy.xml 2 Feb 2008 14:32:02 -0000 1.18
@@ -7,8 +7,8 @@
<abstract>Developer Relations Policy Guide</abstract>
-<version>1.1.2</version>
-<date>2006-08-27</date>
+<version>1.1.3</version>
+<date>2008-02-02</date>
<chapter>
<title>Conflict resolution policy</title>
@@ -18,13 +18,12 @@
<body>
<p>
-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.
+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.
</p>
</body>
@@ -35,38 +34,42 @@
<body>
<p>
-Developer relations should only be involved in a conflict when other
-attempts to solve the issue have failed. Developers should attempt
-polite discussion relating to the matter at hand to resolve conflict
-between themselves. Developers within a single top level project
-(TLP) engaged in conflict may wish to consult with the TLP
-manager. Although TLP managers are not necessarily qualified to
-resolve personal disputes, technical issues resulting in conflict can
-often be resolved within the TLP without Developer Relations
-involvement. Developer relations becomes involved when the above methods
-have failed. Any member of the Developer Relations Conflicts Resolution
-Subproject may work with the conflicting parties to resolve the conflict;
-the Developer Relations member 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 member in control may not
-ask others for assistance.
+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.
</p>
<p>
-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 <mail link="devrel@gentoo.org">devrel@gentoo.org</mail>. These
-should be dealt with on a case-by-case basis by Developer Relations
-and may require disciplinary action.
-</p>
-
-<p>
-Any complaint which the parties are not able to resolve themselves
-using the resources described above is assigned to the Conflict
-Resolution subproject for resolution. This process is described in
-'Disciplinary Action and Resolution'.
+Developer Relations becomes involved when the above two methods have failed. To
+involve Developer Relations in your issue please send an email to
+<mail>devrel@gentoo.org</mail> 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.
+</p>
+
+<p>
+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 <mail>devrel@gentoo.org</mail> 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.
</p>
</body>
@@ -77,159 +80,167 @@
<title>Disciplinary action and resolution</title>
<section>
-<title>Introduction</title>
+<title>What Action May be Taken</title>
<body>
<p>
-Disciplinary action must be decided on a case-by-case basis by the
-Developer Relations lead(s). 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
-Conflict Resolution subproject.
-</p>
-
-<p>
-Upon removing a developer, the gentoo-core mailing list should be
-notified. Additionally, the Developer Relations team are informed
-of the issues that led to removing or suspending a developer, and
-this information is stored on a bug. Developers who are removed
-from the project may not reapply for developer status without the
-approval of the Developer Relations lead(s).
+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; 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.
+</p>
+
+<p>
+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).
</p>
</body>
</section>
<section>
-<title>Conflict Resolution Subproject</title>
+<title>The Policy for Resolution of Conflicts</title>
<body>
<p>
-Developer Relations has established a Conflict Resolution subproject
-for resolving disputes covered by this policy. This group consists of
-one Developer Relations member as a strategic lead, four active Gentoo
-developers who serve as a conflict resolution board, and alternates as
-determined by the lead. The lead is chosen by the active Developer
-Relations members, and the lead is responsible for selecting board
-members and any alternates. Developer Relations approves or rejects
-the lead's choices.
+What kind of disputes should be escalated?
</p>
+<ul>
+<li>A dispute involving Code of Conduct, or similarly themed violations,
+involving two or more developers.</li>
+<li>A developer whose behavior is believed to be a negative influence for the
+Gentoo community. This includes any inappropriate action conducted by a
+developer.</li>
+<li>Any other conflicts of a non technical nature involving two or more
+developers.</li>
+</ul>
+
<p>
-The lead of the Conflict Resolution subproject is primarily a
-strategic contact between the board and the Developer Relations lead(s),
-and as such, has no voting role in determining the resolution of any
-conflict unless needed to break a tie. However, the lead should be
-involved in any conflict referred to this subproject, and must be
-available to provide guidance, advice, or assistance if needed. The
-lead is also charged with the tasks of ensuring all subproject members
-are in fact active participants, that all members are eligible to
-serve, that the subproject works to establish any necessary internal
-procedures, and for similar administrative actions necessary for
-proper functioning of the board.
+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.
</p>
-</body>
-</section>
-
-<section>
-<title>Conflict Resolution Policy</title>
-<body>
-
<p>
-Once a complaint is sent to the Conflict Resolution subproject, the
-board assumes responsibility for coordinating all aspects of the
-complaint. The board must act in accordance with the following
-guidelines:
+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:
</p>
<p>
-Disputes between developers are first assigned to a member of the
-Developer Relations Conflict Resolutions Subproject for mediation.
-This step may be omitted only upon unanimous agreement among the
-the board members, and only if no such subproject member has already
-attempted mediation as described above.
+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.
</p>
<p>
-Complaints that do not require mediation per se (such as repeat QA
-problems) are dealt with exclusively by the board. Problems for
-which mediation has been unsuccessful are also returned to the board
-for resolution.
+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.
</p>
<p>
-In either case, once a complaint reaches the board for final
-resolution, the board should act upon the complaint in a timely
-manner. Although it is impossible to establish absolute time limits,
-unnecessary delays are not acceptable. It is up to the board members
-themselves to establish communications among themselves. IRC is the
-preferred communications medium, but e-mail is an acceptable
-alternative if IRC proves to be impossible.
+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.
</p>
<p>
-No matter how the board chooses to carry on its business, all official
-proceedings including board meetings and voting sessions must be made
-public. However, discussions with parties involved in a complaint held
-for the purpose of mediation may be kept private at the request either
-of the parties or of the board members meeting with the parties. The
-subproject lead is responsible for releasing (the public) logs or
-e-mails to the devrel mail alias and for maintaining an archive of all
-public documents. In the case of private discussions, a summary of the
-non-sensitive parts of the discussion should be provided.
+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.
</p>
</body>
</section>
<section>
-<title>Resolution and Appeal</title>
+<title>The Process for the Resolution Conflicts</title>
<body>
<p>
-Once the board members determine they have enough information to reach
-a conclusion, they meet to make a final determination of the
-appropriate resolution of the complaint. The subproject lead does not
-vote in determining this final resolution unless needed to break a
-tie.
+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.
</p>
<p>
-Any party to a dispute resolved by the board may appeal the resolution
-to the Developer Relations lead(s). No other developer may appeal.
+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.
</p>
<p>
-In case of an appeal, the Developer Relations lead(s) must take one of two
-actions. They may deny the appeal and refer it to the Council for final
-resolution.
+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.
</p>
<p>
-Or, they may accept the appeal. If they accept the appeal, the lead(s)
-must immediately post the appeal to the devrel mail alias for vote on
-the appeal by all of Developer Relations. Developer Relations members
-then have three days in which to vote to accept or deny the appeal.
+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.
</p>
+</body>
+</section>
+
+<section>
+<title>Resolution and Appeal</title>
+<body>
+
<p>
-If a majority of those who vote agree with the appeal, then the appeal
-is successful. In this case, the judgment of the board is modified as
-requested in the appeal.
+Any party to a dispute resolved by the Developer Relations team may appeal the
+resolution to Council. No other developer may appeal.
</p>
<p>
-If Developer Relations votes to deny the appeal, then the judgment of
-the board is accepted unmodified. The outcome of such a vote may be
-appealed to the Council for resolution, but again only parties affected
-by the resolution are allowed to 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.
</p>
</body>
@@ -240,43 +251,23 @@
<body>
<p>
-No member of Developer Relations may participate in more than one step
-in the attempt to resolve a conflict. Specifically, anyone who attempts
-to mediate or otherwise resolve a conflict early in the process is barred
-from taking part in later stages (such as serving on any required dispute
-resolution board).
-</p>
-
-<p>
-In particular, 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. If that Developer Relations member also has a specific
-role in the resolution process (such as Developer Relations lead or Conflict
-Resolutions sublead), then that person must immediately inform Developer
-Relations of the conflict and ask Developer Relations to select an alternate
-to act in his or her place for this dispute.
-</p>
-
-<p>
-For any complaint sent to the Conflict Resolution subproject, the
-Developer Relations lead(s) and the subproject lead should speak with
-each board member to determine any conflict of interest issues. Board
-members having a conflict of interest in any particular dispute may
-not participate in the resolution of that dispute. They should be
-replaced by an alternate chosen by the subproject lead. Whether the
-alternate becomes a permanent board member or whether the member
-rotated out is brought back at the end of the dispute is left to the
-discretion of the subproject lead.
+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.
</p>
<p>
-Complaints raised about any member of the Conflict Resolution
-subproject may be raised to the Developer Relations lead(s) or at
-Developer Relations meetings for discussion at any time. Under extreme
-circumstances, Developer Relations as a whole may vote to remove
-members from the conflict resolution subproject. Also, board members
-may be replaced at the subproject lead's discretion with an
-explanation to Developer Relations.
+Complaints raised about any member of Developer Relations may be raised to the
+Developer Relations lead(s) or to Developer Relations via
+<mail>devrel@gentoo.org</mail> for discussion at any time; a meeting may be
+called to discuss the matter further, up to and including to vote to remove
+members.
</p>
</body>
--
gentoo-commits@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/devrel: policy.xml
@ 2008-04-27 16:33 Christina Fullam (musikc)
0 siblings, 0 replies; 5+ messages in thread
From: Christina Fullam (musikc) @ 2008-04-27 16:33 UTC (permalink / raw
To: gentoo-commits
musikc 08/04/27 16:33:01
Modified: policy.xml
Log:
Revision
Revision Changes Path
1.19 xml/htdocs/proj/en/devrel/policy.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.19&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.19&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?r1=1.18&r2=1.19
Index: policy.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/policy.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- policy.xml 2 Feb 2008 14:32:02 -0000 1.18
+++ policy.xml 27 Apr 2008 16:33:01 -0000 1.19
@@ -7,8 +7,8 @@
<abstract>Developer Relations Policy Guide</abstract>
-<version>1.1.3</version>
-<date>2008-02-02</date>
+<version>1.1.4</version>
+<date>2008-04-26</date>
<chapter>
<title>Conflict resolution policy</title>
@@ -94,11 +94,16 @@
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; 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.
+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.
</p>
<p>
@@ -231,7 +236,7 @@
<body>
<p>
-Any party to a dispute resolved by the Developer Relations team may appeal the
+Any party to a dispute resolved by Developer Relations may appeal the
resolution to Council. No other developer may appeal.
</p>
--
gentoo-commits@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/devrel: policy.xml
@ 2010-04-03 16:36 Petteri Raty (betelgeuse)
0 siblings, 0 replies; 5+ messages in thread
From: Petteri Raty (betelgeuse) @ 2010-04-03 16:36 UTC (permalink / raw
To: gentoo-commits
betelgeuse 10/04/03 16:36:30
Modified: policy.xml
Log:
Change policy to not be in conflict with GLEP 48.
Revision Changes Path
1.20 xml/htdocs/proj/en/devrel/policy.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.20&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.20&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?r1=1.19&r2=1.20
Index: policy.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/policy.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- policy.xml 27 Apr 2008 16:33:01 -0000 1.19
+++ policy.xml 3 Apr 2010 16:36:30 -0000 1.20
@@ -7,8 +7,8 @@
<abstract>Developer Relations Policy Guide</abstract>
-<version>1.1.4</version>
-<date>2008-04-26</date>
+<version>1.1.5</version>
+<date>2010-04-03</date>
<chapter>
<title>Conflict resolution policy</title>
@@ -136,11 +136,10 @@
</ul>
<p>
-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.
+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.
</p>
<p>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/devrel: policy.xml
@ 2012-10-28 15:21 Sven Vermeulen (swift)
0 siblings, 0 replies; 5+ messages in thread
From: Sven Vermeulen (swift) @ 2012-10-28 15:21 UTC (permalink / raw
To: gentoo-commits
swift 12/10/28 15:21:02
Modified: policy.xml
Log:
Removing link attribute from guides
Revision Changes Path
1.21 xml/htdocs/proj/en/devrel/policy.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.21&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.21&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/policy.xml?r1=1.20&r2=1.21
Index: policy.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/policy.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- policy.xml 3 Apr 2010 16:36:30 -0000 1.20
+++ policy.xml 28 Oct 2012 15:21:02 -0000 1.21
@@ -1,7 +1,7 @@
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<guide link="/proj/en/devrel/policy.xml">
+<guide>
<title>Developer Relations Policy Guide</title>
<author title="Author"><mail link="devrel@gentoo.org">Developer Relations</mail></author>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/devrel: policy.xml
@ 2013-09-21 20:26 Markos Chandras (hwoarang)
0 siblings, 0 replies; 5+ messages in thread
From: Markos Chandras (hwoarang) @ 2013-09-21 20:26 UTC (permalink / raw
To: gentoo-commits
hwoarang 13/09/21 20:26:18
Modified: policy.xml
Log:
Updated policy moved to wiki
Revision Changes Path
1.22 xml/htdocs/proj/en/devrel/policy.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.22&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/policy.xml?rev=1.22&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/policy.xml?r1=1.21&r2=1.22
Index: policy.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/policy.xml,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- policy.xml 28 Oct 2012 15:21:02 -0000 1.21
+++ policy.xml 21 Sep 2013 20:26:18 -0000 1.22
@@ -1,7 +1,8 @@
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<guide>
+<guide disclaimer="obsolete"
+redirect="http://wiki.gentoo.org/wiki/Project:ComRel">
<title>Developer Relations Policy Guide</title>
<author title="Author"><mail link="devrel@gentoo.org">Developer Relations</mail></author>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-09-21 20:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-21 20:26 [gentoo-commits] gentoo commit in xml/htdocs/proj/en/devrel: policy.xml Markos Chandras (hwoarang)
-- strict thread matches above, loose matches on Subject: below --
2012-10-28 15:21 Sven Vermeulen (swift)
2010-04-03 16:36 Petteri Raty (betelgeuse)
2008-04-27 16:33 Christina Fullam (musikc)
2008-02-02 14:32 Christina Fullam (musikc)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox