2010/9/28 Risker risker.wp@gmail.com:
Yes it is, and it's an important one. Several of us had already been working on a plan for the second trial, and those of us discussing had widely agreed that it would be much more likely to be successful if more of the recommendations on improving the software were incorporated, thus our recommendation that it not proceed so rapidly.
Social software like Pending Changes is inherently more complex than individual use applications. (And people tend to notoriously underestimate this complexity, and overestimate their own ability to anticipate practical adoption of a social technology.) Even beyond social software, "release early, release often" ( http://en.wikipedia.org/wiki/Release_early,_release_often ) is a well understood and accepted mantra of open source development. Fast release/feedback cycles in a production environment of real users are the method most likely to achieve a consensus one way or another without the project becoming an eternal resource waterfall of doom. Indeed, the main concern with development of Pending Changes in the past has been the lack of fast feedback cycles.
I understand and hear your frustration about the process (and I understand that this is in part concern about the health of the community, and about the success of this very trial). But I think the picture you're painting is gloomier than reality. There are cases (such as the Vector deployment) where WMF has made deployment decisions that exceed the governance of any individual project community: we took a clear stance, and defended it. In this case, it's entirely up to the enwiki community to use or not use this feature. The only thing we've let the majority vote and Jimmy's intepretation thereof guide us on is whether we'll immediately rip out the code or not.
Really, the fact that it shows up in the protection UI is irrelevant to the question of governing policy, which is up to the enwiki community to develop in its normal process. So, for example, if there was consensus right now to remove it from all pages it's currently used on, WMF would absolutely have nothing to say about that. The only thing we care about is providing Pending Changes the support it needs to succeed, or to fail well. We do have a bias in favor of continued iterative testing towards achievement of a clear outcome, but we don't have a bias in favor of the feature being used -- only in favor of learning quickly, so we can discontinue resource allocation if it's a dead end development path.