|
| 1 | +## Title |
| 2 | + |
| 3 | +Transparent Cross-Team Decision Making using RFCs |
| 4 | + |
| 5 | +## Patlet |
| 6 | + |
| 7 | +InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties. |
| 8 | + |
| 9 | +## Problem |
| 10 | + |
| 11 | +For an InnerSource project to be healthy, it needs a substantial amount of contributors. These contributors (or teams) maybe have different requirements for the given project. e.g. they may want to add features to the project that are not compatible with one another or lead to an unhealthy bloat in the architecture. |
| 12 | + |
| 13 | +Discovering such disagreements or misunderstanding late in the process, e.g. once the software has already been built, is very costly. These disagreements may lead to frustrations by all parties involved, and can even be disruptive to the health of the collaboration culture in the project. A common situation where such a disagreement surfaces is a change request (pull request) which is open for a very long time because the author of the change request and the maintainers of the project essentially don’t agree that the proposed change should be made at all. |
| 14 | + |
| 15 | +For an InnerSource project this situation happens more frequently when the project is maintained by multiple teams in the company i.e. shared ownership. |
| 16 | + |
| 17 | +## Story (optional) |
| 18 | + |
| 19 | +**TBD** |
| 20 | + |
| 21 | +## Context |
| 22 | + |
| 23 | +- shared ownership by many teams of an InnerSource project |
| 24 | +- overarching design decisions cannot be made from a central body all the time (e.g. a group of architects) as they have neither enough time, nor sufficient domain-specific knowledge to make good decisions in all the cases |
| 25 | +- various types of users have input on the direction that a certain project is taking. Such user may be: Developers, Product Owners, Product Managers, etc |
| 26 | +- decisions need to be made in a asynchronous fashion, at least partly, as it isn’t feasible to call frequent synchronous meetings with all participants |
| 27 | +- there is a desire to document the decisions made, i.e. making sure that they are made in writing, rather than just verbally |
| 28 | + |
| 29 | +## Forces |
| 30 | + |
| 31 | +- most of the times, the involved parties want to make a decision fairly quickly (e.g. the up-front design time is fairly limited) |
| 32 | +- writing things down (without already implementing things) is often a new skill for many of the people involved |
| 33 | + |
| 34 | +## Sketch |
| 35 | + |
| 36 | +**TBD** |
| 37 | + |
| 38 | +## Solutions |
| 39 | + |
| 40 | +We chose an RFC-like process for increasing the transparency of our cross-team decision making process (also see [Requests for Comments][requests-for-comments]). |
| 41 | + |
| 42 | +Important elements of the solution are: |
| 43 | + |
| 44 | +- a description of when to publish an RFC (and when not to) |
| 45 | +- a template for RFC documents |
| 46 | +- a well known process surrounding RFCs e.g. |
| 47 | + - how to publish RFC and share it with all stakeholders |
| 48 | + - how to collect feedback for the RFC |
| 49 | + - how to work in the feedback |
| 50 | + - how to move the RFC towards a conclusion or decision |
| 51 | + |
| 52 | +## Resulting Context |
| 53 | + |
| 54 | +Implementing an RFC-like process has proven to be valuable, as it makes the cross-team decision making process more transparent for everybody, allowing for all voices to be heard. |
| 55 | + |
| 56 | +Observable positive effects: |
| 57 | + |
| 58 | +- **democratization of the decision making process** for decisions that impact many teams (also offloading team leads from that burden) |
| 59 | +- **a open asynchronous communication method** that works well across multiple teams and geos |
| 60 | +- **terminology alignmen**t e.g. by spelling out our testing terminology such as “what is a system test?” |
| 61 | +- **process alignment** e.g. by spelling out the out-of-hours support process |
| 62 | +- **greater clarity of thought**, as writing an RFC makes the author challenge herself more than they would normally |
| 63 | + |
| 64 | +The RFC approach also has risk that we want to call out: |
| 65 | + |
| 66 | +- It doesn’t always work! e.g. some people might still argue against a decision that was already made via an RFC. However having the decision making process in writing is still beneficial in these scenarios, as you can point people to when and why a certain decision was made. |
| 67 | +- Writing up design proposals (architecture, protocols, etc) upfront has an element of upfront waterfall-like design to it that does not fit the iterative development approach that man development teams favor. |
| 68 | +- An RFC may become big and too unwieldy. This often shows in long comment threads and discussions surrounding it. In those situations we may decide to complement the RFC with synchronous communication such as a working group and in-person meetings. But time is still saved, as people can read the RFC before the meeting rather than having all the information shared during the meeting. |
| 69 | + |
| 70 | +## Rationale |
| 71 | + |
| 72 | +RFCs haven proven themselves in the Open Source world for many years. This is true both for the Internet as a whole where RFCs have been instrumental in developing standards (e.g. see [30 Years of RFCs][30-years-of-rfcs]), as well for other Open Source projects that have adapted this method to promote transparent decision making in their community (e.g. [RUST][rust], [ZeroMQ][zeromq]). |
| 73 | + |
| 74 | +In the context of InnerSource, other companies have shared their experiences with RFC-like approaches too, such as [Uber][uber] and [Europace][europace]. |
| 75 | + |
| 76 | +Also for decision making outside of pure software design decisions, transparent decision making models can be effective e.g. when working towards an Open Organization. For an example see Red Hat’s [Open Decision Framework][open-decision-framework] (released publicly on June 7, 2016). |
| 77 | + |
| 78 | +## Known Instances |
| 79 | + |
| 80 | +- **Uber** - According to this blog post by Gergely Orosz: [Scaling Engineering Teams via Writing Things Down and Sharing - aka RFCs][uber]. |
| 81 | +- **Europace** - As described in Open Organization: [Setting cross-team standards and best practices in the open][europace]. |
| 82 | + |
| 83 | +## Status |
| 84 | + |
| 85 | +**Initial** - Created August/September 2020 in preparation for Tom Sadler’s talk “Using internal RFCs to enhance collaboration” at the [InnerSource Fall Summit 2020][innersource-fall-summit-2020]. This first version was written by Sebastian Spier, after an interview with Tom Sadler. |
| 86 | + |
| 87 | +**(future) Structured** - After the InnerSource Fall Summit 2020 we plan to extend this pattern with additional info based on Tom Sadler’s talk at the summit. With that we want to bring the pattern to maturity “Structured”. |
| 88 | + |
| 89 | +## Author(s) |
| 90 | + |
| 91 | +- Tom Sadler |
| 92 | +- Sebastian Spier |
| 93 | + |
| 94 | +[requests-for-comments]: https://en.wikipedia.org/wiki/Request_for_Comments |
| 95 | +[30-years-of-rfcs]: https://www.rfc-editor.org/rfc/rfc2555.txt |
| 96 | +[rust]: https://github.com/rust-lang/rfcs |
| 97 | +[zeromq]: https://rfc.zeromq.org |
| 98 | +[uber]: https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/ |
| 99 | +[europace]: https://github.com/open-organization/open-org-distributed-work-guide/blob/master/drostfromm_remote-first-through-openess.md#setting-cross-team-standards-and-best-practices-in-the-open |
| 100 | +[open-decision-framework]: https://www.redhat.com/en/about/press-releases/red-hat-releases-open-decision-framework-spur-transparent-and-inclusive-leadership |
| 101 | +[innersource-fall-summit-2020]: http://innersourcecommons.org/events/isc-fall-2020/ |
0 commit comments