> 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 <gmaxw...@gmail.com> wrote: > On Sun, Jun 13, 2010 at 6:59 PM, David Goodman <dgoodma...@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@lists.wikimedia.org > To unsubscribe from this mailing list, visit: > https://lists.wikimedia.org/mailman/listinfo/wikien-l > _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
