Browse files

Add docs/parrot-relationship.txt, which codifies the relationship man…

…ager roles between the Rakudo and Parrot projects.

This was adopted in June 2011, but apparently never made it into
either of the repositories.  So I'm adding it to the Rakudo
repository now.
  • Loading branch information...
pmichaud committed Dec 11, 2012
1 parent a308f34 commit 77970398271c28feee61ff519022b8c1adaa9893
Showing with 109 additions and 0 deletions.
  1. +109 −0 docs/parrot-relationship.txt
@@ -0,0 +1,109 @@
+Background: For a variety of reasons, Rakudo continues to target Parrot
+monthly releases. This implies that Rakudo developers must periodically
+test and develop against the HEAD of Parrot's master branch, to detect
+potential breakages before they make it into a monthly Parrot release
+that Rakudo expects to build against shortly thereafter. Early
+reporting of potential issues, breakages, and performance degradatation
+of Parrot HEAD prior to any release is also very beneficial to
+Parrot development.
+During the May 2011 Parrot Developers Summit the participants agreed
+that Parrot will continue to support Rakudo's efforts to target Parrot
+monthly releases and be regularly synchronized with Parrot's master branch.
+Note that the above agreement does _not_ go so far as to state that
+commits to Parrot master can never cause a Rakudo failure. We
+recognize that breakages will occasionally occur between Rakudo and
+Parrot's HEAD, both within and outside of the scope of Parrot's
+deprecation and support policies. Such interim breakages are
+completely acceptable as long as there is some confidence by both
+development teams that whatever issue is causing the breakage is
+likely to be resolved satisfactorily prior to the next Parrot
+monthly release.
+It is when such resolution seems unlikely that there has been sharp
+and contentious debate over the "how, where, who, and when" details of
+solving whatever issue may be at hand. This is what the new policy
+aims to address.
+The policy: Starting May 2011, Parrot and Rakudo will
+designate two persons from each team to serve as "relationship
+managers" to resolve any issues that arise between the two projects.
+These managers are expected to carry sufficient clout or authority
+to effect potentially unpopular decisions within their respective
+projects (e.g., reverting commits, delaying feature availability,
+adjusting development schedules, etc.).
+Christoph Otto and Andrew Whitworth have been selected as Parrot's
+relationship managers for Rakudo; Rakudo managers for Parrot will
+be represented by Moritz Lenz and Patrick Michaud.
+In the future, when Rakudo developers feel that discussions about
+Parrot on IRC, mailing list, or other channels are unlikely to
+resolve a critical breakage or performance issue they are
+encountering, the developers should bring the issue to the
+attention of one or both of Rakudo's representatives (<person1>
+or <person2>). The Rakudo developers involved should also seek
+to reduce any pressure they may be applying in the other forums.
+(Reducing pressure can be as simple as "I think we may be at an
+impasse that needs the guidance of the relationship managers,
+let's get them to work on it and we can go have a beer.")
+The Rakudo representatives will evaluate any issue brought to
+their attention, and they will then bring it to the attention of
+the Parrot representatives if they deem it appropriate. At this
+point, the representatives from both teams will collectively work
+to arrive at a consensus solution that will be acceptable to
+both projects (if not to all of the participants). The mechanisms
+by which the representatives choose to arrive at their decisions
+are entirely up to them.
+The above process also holds in reverse for Parrot developers
+that feel an issue has become unresolvable via direct discussions
+with Rakudo developers.
+Note that petitioning or pressuing another project's relationship
+managers directly (in their role as relationship manager) is highly
+discouraged. Once it's decided that relationship managers need
+to be involved, opinions and discussions between the managers will
+carry far more weight than those coming across project boundaries.
+A relationship manager is free to answer cross-project lobbying
+requests from non-managers with "Raise this issue with your
+project's relationship managers."
+There are two primary motivations for the establishment of
+project relationship managers. First, we want to provide a "safety
+valve" to relieve heat/pressure and provide a path forward whenever
+the normal discussion channels start to appear impossibly deadlocked.
+Second, we want a mechanism that ensures that critical decisions
+aren't appearing to be made (either explicitly or through inaction)
+solely because of the set of participants of any given IRC discussion
+or mailing list thread.
+Bringing an issue to the attention of a relationship manager does
+not mean that the issue will be immediately resolved, nor that
+that the issue will ultimately be resolved in exactly the manner
+desired by the requestor. What it does mean is that the relationship
+managers have committed (1) to thoughtfully investigate and respond
+to any issues raised by their counterparts, so that we can all have
+some confidence that the issues have been carefully considered from
+many sides by people empowered to make changes if needed, and
+(2) to work on such issues in a timely manner, so that the overall
+disruptions to Parrot's and Rakudo's development are minimized.
+We all know that Parrot developers want Rakudo to succeed, and
+vice-versa. Nobody is intentionally trying to make things
+difficult for others; the projects are just sufficiently complex
+that it's impractical for us to completely avoid any surprises
+(breakages) in either project. We know surprises will occur; this
+new policy will hopefully enable us to collectively handle the inevitable
+surprises more productively than we have in the past ("fail softly").
+We'll try it and see how it works out; if it doesn't work out,
+we'll come up with something else. (Or perhaps well all need to
+discuss it with our relationship managers. :-)
+Comments and feedback welcomed.

0 comments on commit 7797039

Please sign in to comment.