How new features end up on the site

From the CouchSurfing Wiki, an informal workspace which anyone can edit.

Chris Burley:
> 2. Are we now able to make changes of this nature without community
> opinion or global decision making? I just remember the loads of work it
> took(not my preference) in order to change the way friend references
> were left when I was working at MTL collective.

Joe:

Yes. We are now operating under a very different development model than what you experienced in Montreal. The old approach was "get all sorts of approval and input and make proposals and stuff before you do anything." The new approach is "use your judgement about whether a change is likely to be disruptive or controversial; if it's not, go ahead, but be prepared to roll-back rapidly if, post-deployment, there are any significant problems or disagreements."

A "non-disruptive" change is defined as one that (a) does not significantly confuse or disorient our users, either new users or old users, and (b) is conservative with regard to the purpose and use of the site--i.e., well within the bounds of what people think couchsurfing is all about and what the site currently does.

Of course, even non-disruptive changes may prove controversial, and because of good version control and deployment strategies, we are prepared to roll back our changes within minutes or hours should they prove controversial. Anyone can roll back anyone else's changes, and Kasper is in his position because he could be trusted to roll back is own changes should they prove controversial.

Some kind of group process is still necessary for disruptive or controversial changes. What exactly that process is, is unclear right now. It's not a pressing issue because there are so many non-disruptive, non-controversial changes to be made. But there appears to be a kind of a spectrum of processes emerging:

(1) the one above, for non-disruptive, noncontroversial changes. This leaves developers free to make 40 bugfixes and cosmetic improvements a day, as well as larger changes like Kasper's that are non-disruptive.

(2) for slightly more disruptive/controversial changes, one or two of the admins/founders/people with a lot of historical perspective are consulted, some informal user studies are done with nearby new users and existing users, and roll-out is especially tentative and possibly beta-tested. this is still way more light-weight that the MTL process: admins, for instance, have to trust each other to give good advice individually, as only one or two of them may be consulted.

(3) for obviously and extremely disruptive/controversial changes, a proposal is written and floated for a long time, shopped around to all concerned parties, and nothing is really done about it ever.

It is up to the developers and core developers to use their judgement about how to proceed with each change, just as it was up to Casey's judgement before the crash whether to just make a change directly or to ask many people's opinions about it. Core developers are picked because of their respect for the site and the user experience, and their ability to make good decisions and think clearly about what needs to be shopped around. Their positions are predicated on being able to make good decisions in this regard, and if a core developer starts committing changes that really should have been shopped around (because they are disruptive or controversial), their privileges will be revoked.

In all cases, we are prepared to roll back (or iterate forward) as soon as controversy arises or better ideas come in. And that is what makes this a viable way of doing things, with little risk that we will disorient and lose our user base, confuse our mission, etc.

In the end, we support an iterative and tentative development model. Instead of trying to collect everyone's ideas up front, somehow consolidate them, and then make a permanent change, we make smaller, tentative changes and listen to the users, expecting that some things won't fly, and others will need to be swiftly updated based on real-world experience.