Requests for Comments (RFCs) are a well known concept in the Open Source world. At my company similar concepts start to evolve that go by different slightly different names, but at the end of the day they are RFCs that are only meant for company-internal communication.

I did some googling and found that others are describing similar things. The best article I found so far is Scaling Engineering Teams via Writing Things Down and Sharing - aka RFCs.

In the article the author, Gergely Orosz from Uber, explains their internal RFC process, and ends with:

So is this process unique to Uber? Far from it. Larger tech companies, like Google, Facebook, Microsoft or Amazon all came up with something that resembles some level of RFC process.

This makes me hopeful that we could find enough Known Instances of this approach at other companies, to turn this into a proven pattern.

"How those this relate to InnerSource" you may ask:

My claim is that a process like this helps you to involve the internal Engineering community within your growing organization at an early phase of major projects or architecture decisions.

This will eventually lead to a higher degree of interaction between teams, and with that also to more InnerSource contributions of any sort. At the most basic level, any RFC/Architecture discussion that is happening between teams is already an InnerSource contribution, isn't it?

So what do you say? Is this worth turning into a pattern?

I looked through the existing patterns and did not find one like this.

Appendix

Other names for the same thing:

• Architecture Decision Records
• Architecture Design Records
• Design Decision Records
• Internal RFCs