[WikiEN-l] Community ready for Pending Changes (nee Flagged Protection)?

Tue Jun 15 17:15:09 UTC 2010

> Can you please identify methods in which we can measure the improvement
> here?  Are you proposing, even before the trial starts, to start including
> articles that do not meet the criteria for page protection?  Let's be
> clear,
> Cenarium; the trial is very specifically only to be used on pages that meet
> the *current* criteria for page protection; what you're suggesting here is
> something completely unrelated to the trial of pending changes in and of
> itself.
>

You know well that there are no objective way to say if an article meets the
'criteria' or not. If you ask different admins about a particular situation,
some will say no protection is warranted, some will say temporary
semi-protection is, of variable length, and some say that indefinite
semi-protection is. The protection policy says 'heavy and persistent
vandalism or violations of content policy' for indefinite, and 'Subject to
significant but temporary vandalism or disruption' for temporary, this
allows for considerable discretion. And since pending changes protection is
much less restrictive than semi-protection, admins will naturally lower
their personal threshold for applying it. There are several admins who apply
a threshold considerably lower than average, their semi-protections are
often contested but almost always uphold, or with no admin going ahead to
remove them. When several admins started to make use of ' liberal semi' for
BLPs, there has been considerable objection (by me among others) but almost
all protections stayed.

There we see the two contradictory needs, to better protect articles, BLPs
in particular, versus to keep articles editable. Excessive protection (of
any kind) is bad; but BLPs subject to vandalism or BLP violations to a level
where semi-protection would be within discretion, but just below the
threshold where most admins would protect, is not satisfactory.

By its flexibility, pending changes allows to better balance those two
contradictory needs.

A great advantage of pending changes protection is that we can see edits, so
determine to a certain extent if protection is still warranted. With
semi-protection we can only guess. So we'll be in better measure to remove
pending changes protection were no longer needed.

This means we'll simultaneously be able to handle more cases for protection,
and remove protection where no longer needed. The total of protection may
not even grow sensibly at all, but protection would be better distributed.
We just need to keep an eye on the backlog and adjust if necessary. In the
trial we may not readily see this happening, because it would be more
limited and controlled, but I'm sure it will occur to a certain extent.

This won't handle all issues, especially isolated vandalism and BLP
violations, where protection cannot be used per policy, which is why we
vitally need better monitoring tools, like patrolled revisions. I would
strongly oppose any attempt to no longer regard the protection policy for
using pending changes, or alter the protection policy to extend its scope.

For discussion of methods, see Wikipedia talk:Pending changes/Trial.

This is a very dangerous view on the issue. This is what people
> who strenously opposed the new mechanism were most afraid
> of, and the supporters originally said would not be a danger.
> If this really happened, I could easily see many of the people
> originally in support of the new mechanism, could do a full
> volte-face and come strongly in opposition of the mechanism.
>
> Supporters of the original agreement often voiced the proviso
> that using the mechanism for semied/BLP's or whatever their
> personal threshold was, would never ever be a thin end of the
> wedge to spread things out to things we wouldn't semi currently.
> That is the *old* *agreement* on this issue. A huge drive by any
> tiny group of blow-hard editors to expand use of the mechanism
> beyond what we currently semi, could back-fire spectacularly.
>
> I don't dispute that in the fullness of time; years or decades
> from now, it might eventually go that route, but that is a
> completely different issue, and I suspect there would be
> many more important community supported initiatives that
> would have to be accepted in the interim, before that could
> remotely be acceptable.

People were mostly afraid to see this becoming a FlaggedRevs implementation
similar or close to that on de.wikipedia, which is very different from what
I imagine.

The idea of Yamamoto
Ichiro<http://en.wikipedia.org/wiki/User:Yamamoto_Ichiro>to use
flaggedrevs as an alternative to protection was a breakthrough
because it allows not only more editability than classic protection but also
to better control uses of protection, as I explain above, this allows a much
finer distribution, to apply it where it is needed, and only where it is
needed, more than classic protection would ever allow.

Pending changes is now heavily associated with protection, even on the
technical side. The protection policy acts as a safeguard against attempts
to use it on pages where protection is unjustified, though we can't say what
will happen in the future. But the protection policy does allow discretion,
and with the flexibility of pending changes protection, I think this will
naturally result in a better distribution of protection. Any protection can
be reviewed by the community, and there's going to be much attention given
to the backlog.

The majority of the community wouldn't accept to use flaggedrevs on pages
outside the scope of the protection policy, and I don't see this changing
anytime soon. And this is imo for the best.

On Tue, Jun 15, 2010 at 2:20 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Sun, Jun 13, 2010 at 6:59 PM, David Goodman <dgoodmanny at gmail.com>
> wrote:
> > There has never been agreement for more than the 2,000. It will be
>
> Wha?
>
> The 2000 limit was a technical thing which came later, and not from
> the community.
>
> I don't think it's a bad thing, even outside of the simple performance
> concerns that inspired it — otherwise we probably could expect some
> trigger happy person to mass convert all (semi-)protected pages before
> we've had a chance to work the kinks out of the software...
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>