We adopted PHP's RFC 'model' for our Architecture team
Marcos Marcolin • December 7, 2022 • 4 min read
php arquitetura rfcIn early 2021, a longer-tenured developer, one of the senior ones at my employer, had the idea to start an internal team within the development department. The goal was to study Software Architecture and apply it to our projects, as well as discuss new solutions.
The Architecture Team
A few people were invited to join this team, with the goal of discussing architecture problems, studying design patterns, proposing solutions, among other things. This team usually meets every 7 to 10 days to discuss new demands and review ones already in progress.
At first, practically every topic involved fixing and improving PHP code, and the team had around 8 professionals. Today, the team is already in the dozens in terms of participants and includes professionals from various specialties. Topics discussed include project standardization, use of design patterns, refactorings, tests, code and query optimizations, JavaScript, Node.js, and a whole lot more.
I won't dwell on this team here, maybe I'll cover it in more detail in another article.
RFC (Request for Comments)
If you don't know what an RFC is, I'll leave a link with more details at the end of this article.
In short, it's a model adopted by some technologies to accept/receive suggestions for changes. In a language like PHP, that can mean deprecating or removing a feature, a small tweak, or a new feature, for example. And all of that is resolved democratically, through people who have voting rights.
Since I've known PHP (around mid-2010), the RFC process has been used to decide on changes, and anyone interested can open one. Read here how to start one.
Back to the main topic: as our team grew, so did the demand, and that became the starting point for better organizing what we were already discussing. And since we should respect democracy, why not use it in our own team?
Over time, more topics came up for debate, and along with that came differences of opinion. Facing that dilemma, I suggested we adopt the RFC model used in PHP's core development for our team, which made it possible to propose solutions with more detail, along with a fair vote.
Of course, we didn't build a voting system identical to the one the language uses, with permissions, vote control, and so on. We simplified it and built it into our Notion board. Marcelo, our tool maestro, helped us with this task.
Today we have the following structure:

This way, we can organize RFCs in a simple, democratic way. When a topic sparks a discussion with differing opinions, we suggest the author write an RFC with more detail and open it up for a vote. Below you can see a few topics discussed recently.

On the RFC item in Notion, you can see who approved or rejected it, as well as the number of votes for and against. If someone has a question or another point to raise, they can comment on the item and start a discussion.

To start an RFC, you need to fill in some information, including:
- Introduction to the topic
- Proposal
- Backwards-incompatible changes (possible deprecations)
- Impact
- Open tasks related to the topic
- Patches and tests
To make writing easier, Marcelo already put together a template with the information above.
Conclusion
So far the process has been running smoothly, even though the operations are manual, since there's no automation to close an RFC after it's been open for a certain time or has reached a minimum number of votes, for example.
So, the author and that month's group chair are responsible for "nudging" members to vote or discuss. There's no set maximum deadline for discussion, but we're currently working on that.
I should note that not everything discussed turns into an RFC. Most topics are resolved in small cards on the Notion board and reviewed weekly.
Today, we have around 60 developers on the development team, and this model is fitting well with our process, and we intend to keep evolving it. Our goal isn't to add bureaucracy, but to make decisions based on the benefits we can get from RFCs, and to do so fairly, without concentrating power in just a few people.
So, how do you all organize these Architecture demands? Tell us about it!
Thanks for your attention, and see you in the next article!
Special thanks to Jean Detoni for starting the Architecture team, and to Marcelo for structuring our entire organization in Notion.
Useful links
- https://wiki.php.net/rfc
- https://en.wikipedia.org/wiki/Request_for_Comments