The charter as currently written seems very reactive: people who have a plan on how to evolve the technology landscape write an RfC, and TechCom approves/rejects/amends, but has no role of initiating and driving changes on its own. While the lack of resourcing power understandably limits options in this regard, and a more limited role might result in healthier power dynamics as well, it still seems like a missed opportunity to put the ten most adept and respected members of the technical community in the same room, and then not use them for anything other than reviewing submissions. Wouldn't it be a natural role for ArchCom to (in cooperation with those who would provide the resources) manage some kind of roadmap/technical strategy? We have recently recognized the problems that stem from MediaWiki not having a roadmap, but that's very much true for the wider technology stack as well.
Topic on Talk:Wikimedia Technical Committee/Charter
The charter allows RFCs to be initiated by committee members, so it doesn't rule out being proactive. Various members have expressed a desire to be more proactive, and to work more closely with WMF managers who own the budgets. I guess the question is whether being proactive should be described more specifically in this document.
I'll raise this with the committee, along with other new topics on this page. Thanks!
This is one of the issues that trouble me the most as well. I've often raised that, including at the ArchComm meeting I joined back in December. RFCs initiated by commitee members don't really count IMHO, as anyone can initiate RFCs, so presumably this wouldn't be done with a T-Comm hat.
I'll echo @Tgr (WMF) in that we need for an architectural roadmap/technical strategy and that's something I would definitely expect the T-Comm to lead, as a group, not just opine on.
I think RFCs initiated by committee members do count, as anyone can submit roadmap/technical strategy RFCs, and the RFC process is suitable for policies and strategy discussions, I believe.
I think the important point is that T-Comm should see it is one of it's key tasks to set policy (backed by strategy). So committee members (or the committee as a whole) should be expected to propose such RFCs, or initiate other deliberation processes as appropriate for setting policy.
What kind of wording would be helpful to make this point more clear? At the moment, we have "...make decisions and set policies regarding high-level technical issues" and later "Anyone (including committee members) can propose a new policy or guideline through the RFC process". Perhaps that can be made stronger, e.g. "the committee will propose new policies or guidelines via the RFC process"?
I understand the difference between "reactive" and "proactive", however I also believe that one of the outcomes of this charter should be to eliminate this difference. Meaning, that there couldn't be either. I'll address them from different perspectives.
Problems
In the past, major changes, and changes that affect multiple products/features, could sometimes happen without an RFC. There was no CTO and no enforcement. At the same time, it feels wrong if ArchCom would (proactively?) interfere with internal team practices. E.g. Whether resolving tech debt in a product or feature is a priority shouldn't be our call. On the other hand, if it starts to affect the code's overall stability, security, performance, or causes problems with other areas (cross-cutting), it becomes our concern - in so far that the product would have essentially diverged from its previously reviewed architecture.
This has always felt like a paradox to me. I hope requiring ArchCom involvement going forward (as enforced by CTO) will prevent this.
Product backend
The feature roadmap of end-user products is not in our scope, however their technical requirements are. As such, I don't think there will be a strong need for us to proactively propose specific major changes to individual products. I do believe we should be proactive, but not by going into individual products - rather, by sharing and justifying our intentions through general guideline documents that set the overall direction.
On a small scale, this would be proactively adopted by developers (enforced by project maintainers through Code-Review, perhaps with ArchCom as last resort).
On a larger scale, requiring ArchCom involvement would naturally apply it for any new proposals. Even proposals that don't seem to immediately relate to overall direction (e.g. new feature) may still require changes in order for the end-result to still be a stable, consistent, and performant production environment.
By applying the direction only through proposals, we keep ourselves on-track to serving the needs of Product, and naturally avoid scope overlap with product management by only proposing major changes when there is a specific need. For example, if RESTBase hadn't existed yet, perhaps ArchCom would've blocked Page Previews (Popups) as it didn't perform to acceptable standards without it. How it goes from there depends on available resourcing, product prioritisation, and coordination between the various Product (Audiences) and Technology teams.
Infrastructure
Long-term planning that doesn't directly impact or enable something tangible. While possible, it's unlikely an existing RFC would exist where it'd be appropiate to block on such change. For example: Kubernetes for scaling of production apps, Using Thumbor for image thumbnails, etc.
Are these in ArchCom scope? Undoubtedly, Yes. And when such change comes up, it should use the RFC process.
But could ArchCom members (proactively) create an RFC for such things? How does that deal with the resourcing problem?
Usually with RFCs, the resourcing is on the author. If it doesn't happen in the end, no harm is done. The notable exception is RFCs for establishing guidelines and overall direction. Often, such RFCs apply retroactively and require involvement from many teams to go through existing code over time. I suppose the same could be done for infrastructure direction. I think it would be natural for such infrastructure direction RFCs to not be too specific, but overall I think it makes sense for ArchCom to be involved in this area, even proactively. (More about this point at Topic: System vs. software architecture.)
The committee added a sentence to the purpose saying that they also work at the level of vision or high-level direction. That opens the doors for working more proactively.
The committee also felt that a "roadmap" would be the domain of a product manager.