This page is currently a draft.
More information and discussion about changes to this draft may be on the discussion page.
Some writing from a private discussion about ArchCom that I think I want to repurpose. There's a lot more work to do on this to repurpose it properly
Here's a couple of (unfair?) criticisms of ArchCom:
- It takes a long time for ArchCom to decide things
- ArchCom often suggests solutions that are more complicated than they need to be
The challenge we face is that developers frequently don't want to do the work to quickly build rough consensus for their project, where "rough consensus" means "tell the people affected; get their advice; address their concerns; and move forward" (not "make everyone happy"; that way lies madness)
Building rough consensus is reasonably straightforward (see Consensus). "Straightforward" doesn't mean "easy", but it can mean "fast" if you're willing to do the work. Sometime people blame ArchCom's process because they've expect the ArchCom team to do the work for them. ArchCom's role is in making sure that engineers making a substantive change to how things work actually attempted to seek the advice (not necessarily the permission) of everyone affected by the change.
Engineers often want autonomy and freedom to develop while at this same time making changes that (unintentionally) do things like:
- Trash performance of the site
- Open huge security vulnerabilities on our site
- Trash reliability
- Increase our system complexity and/or technical debt
Inexperienced engineers often treat dealing with some/all of these problems as someone else's job. Large, well-funded companies create safe environments for mediocre developers by forming well-resourced departments around each of the bullet points above.