User:RobLa-WMF/Consensus

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

Criticisms

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

Response

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.