[Foundation-l] Pending Changes development update: September 27

Risker risker.wp at gmail.com
Thu Sep 30 02:00:26 UTC 2010


On 29 September 2010 21:07, Jimmy Wales <jwales at wikia-inc.com> wrote:

>  On 9/28/10 7:41 PM, Risker wrote:
> > 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.
>
> I respect what you are saying here, very much.  But I think the right
> approach is always "release early, release often".  There is no need to
> rush, but there is also no reason not to release fixes as they are
> available, because there is no particular "ship date" with marketing, etc.
>

Jimmy, here's where you're wrong.  The first version was marketed as the
solution that would allow the [[George W. Bush]] article to be publicly
edited - it was marketed that way on and off wiki - and instead we had 40
hours of non-stop IP vandalism and browser crashes for almost every
reviewer. (The first problem was easily anticipated by just about every
administrator on the site, and the second one by anyone who'd already seen
what had happened with other very large articles.)

This "product" has to be sold to admins to get them to use it; they saw the
first version and all of its significant problems and aren't very
interested.  And until there is a product that passes their smell test, they
still won't be interested. So installing an "upgrade" that hasn't resolved
ALL of the significant issues is not going to interest the "consumers".

The advantage of a coordinated effort of a new trial with an upgraded
release that has addressed all of the significant issues *and* has been
well-tested on the test wiki is that it can be used to market the tool.  It
doesn't matter whether or not it works well if the people in the position to
use the tool cannot be persuaded it is worthy of their attention. Take a
look at the stats, Jimmy: Six administrators were responsible for entering
80% of the articles into the first trial, and another 12 responsible for the
next 17%.  Most administrators were not interested the first time around.



> > It's pretty hard to maintain motivation, though, when it's clear that the
> > software's going to be a permanent feature regardless of what the project
> > does or thinks, and that any further "trial" is not going to change that
> > fact.
> I think that's very very far from true.  I think that everything the
> Foundation has said, and everything that I have said, and everything
> that (nearly) everyone on all sides has said, indicates nearly 100%
> universal agreement that in order for the feature to be enabled
> permanently, it has to achieve consensus.
>

> Consensus is not a "hold one vote and give up if you don't make it"
> process, but rather an iterative give-and-take.
>
> If I believed that the current version was the best that the Foundation
> could deliver, I would be adamant about just shutting down PC as soon as
> is practical, and believe that the right way forward would be to push
> for major expansion of the use of semi-protection.   I would hate to do
> that, because I think that a well-implemented PC is a better solution
> than semi-protection, striking a better balance.
>
> My point is this: I think it very far from a foregone conclusion that we
> will have PC in use in the longterm.  It has to improve a lot before
> that can happen.  The early signs, though, are that it was popular.
>

I'm really curious to know what metric you're using to determine that it was
"popular".  The *idea* is popular with a significant segment of the
community, which is where much of the support in the two polls came from;
but the *tool* itself wasn't very popular with many editors. And the concept
of administrator-granted "reviewer" permissions went over like a lead
balloon with a pretty big segment of the community.

Put the upgrades on the test wiki. Recruit a pile of editors (not just
administrators) to really put it through its paces and drive it hard, both
those who are technically savvy and those whose strength is content.  These
editors are your potential change agents; if they're convinced it's working
satisfactorily and that major issues have been resolved, they will spread
the word on-wiki.  Sticking poorly tested software upgrades onto the #7
website, and expecting people to be enthusiastic, is remarkably optimistic.

Risker/Anne


More information about the foundation-l mailing list