Wikipedia talk:Pending changes/Closure

Way forward

I think we should add a section called “Way forward” immediately after “Working summary”. It should say something like:

• Use PC only on low-edit-frequency pages until we decide what we are doing.
• Have a widely advertised poll for two weeks from August the 31st. The following options will be given. Poll-responders can also suggest alternatives.

1. Remove the pending changes feature.
2. Keep pending changes, exactly as it has been run in the trial – limited to 2000 pages and any changes to the policy for applying the feature needs consensus.
3. Keep pending changes as it has been run in the trial but have a policy that it is only used on pages that have a low edit frequency or are on few watchlists.
4. Wikipedia:Targeted flagging - Expand the number of pages that pending changes can be applied to, but limit it to BLPs on a small number of watch lists.
5. Some variation of Wikipedia:Targeted flagging – e.g. base targeting criterion on average number of edits per week or allow on little-watched-non-BLP articles.
6. Expand the number of pages that pending changes can be applied to and use a similar concept to what we have now for deciding whether a page can be PC protected.
7. As 6 but also use on all BLPs
8. Expand the number of pages that pending changes can be applied to. Use on all BLPs and only a very limited number of other articles.

A. One of the above, but consider expanding the application of PC if some of the issues can be addressed.

e.g. If I thought the pending changes option should continue as it is but could be expanded if some of the issues Identified were addressed I would say 2A.

Any thoughts. Is this a good idea? Improvements to the options?

Yaris678 (talk) 19:41, 20 August 2010 (UTC)

So this would list divergent paths of action separately, as opposed to feature requests which identifies things which could generally all be done at the same time? I think we should hold off on this for just a day or two more, since its presence will significantly change the focus of the discussion towards, as you probably foresaw and intended, what to do now. I'm also not sure the discussion-starters wanted this to be more complicated than a simple close/continue vote. I think we should have that discussion, but before we jump into a very substantial debate, we should probably check to see that it's within the scope of the developer's capabilities and the general plan for this trial.

I think the list of options is really helpful, we just need to nail down how to make them all obvious and distinct. I also think it is really useful to distinguish what people would accept now, with PC as is and what people would accept conditional on certain changes. Should we try and identify a common list of changes, or should we let the discuss range towards people's individual preferences and peeves. Last, assuming we put this list up, would we start a new discussion section, with a new heading (and what would you want to call it?). One final question, would we put the summary options list up before starting that discussion section, or after? In other words, would we prepopulate the list of options, or wait for discussion to bubble them up? Ocaasi (talk) 23:41, 20 August 2010 (UTC)

Proposed Summary/Discussion about PC options

this is not the discussion, just a draft

A widely advertised poll lasting for two weeks from August the 31st will determine the future of pending changes. This discussion is designed to identify how much support there is for different scopes/variations of the feature. Please select the one option you prefer. This is still just a discussion, not a vote:

1. Remove the pending changes feature entirely
2. Keep pending changes as is but use it only on low traffic/low watchlisted pages
3. Keep pending changes as is but use it only on low traffic/low watchlisted BLPs
4. Keep pending changes as is, no changes
5. Keep pending changes as is but expand on low traffic/low watchlisted pages
6. Keep pending changes as is but expand on low traffic/low watchlisted BLPs
7. Keep pending changes but expand on all BLPs
8. Expand pending changes as is, just on more pages
9. Expand pending changes as is and add to low traffic/low watchlisted pages
10. Expand pending changes as is and add to low traffic/low watchlisted BLPs
11. Expand pending changes as is and add to all BLPs

note: As is indicates the current number of articles, interface, and policy guidelines. Any choice still permits improvements to the pending change user-interface. Any future expansions would still require consensus. Distinguish between the choice you prefer today, and the choice you would prefer if certain improvements were made to PC. Identify which improvements would have to happen in order to support your choice.

Ocaasi (talk) 12:40, 21 August 2010 (UTC)

If you are wanting to spark a wider discussion about the list of options that is separate from the other discussion then perhaps it should happen on another page. Wikipedia:Pending changes/Poll preparation?

Your list is probably an improvement on mine but it makes me think we could break it down into two poll. I think:

1. Dealing with the issues brought up at the closure discussion will mostly take weeks and months if not longer. The obvious exception is whether to target the feature at specific types of page, which can be put to a poll now.
2. The number of pages that people are happy for the PC feature can be applied to will be dependent on what the feature is targeted at. For a start, 10,000 high-traffic pages will create a lot more work than 10,000 low-traffic pages.

Therefore there should be two polls.

Poll 1 - Targeting the PC protection

N.B. This will be implemented in policy not code. Until pending changes can be improved significantly, its protection should only be applied to:

• Nothing - remove the feature
• Any page that could otherwise be semi-protected - as per current guideline
• Any low-traffic/low-watchlist page that could otherwise be semi-protected
• Low-traffic/low-watchlist pages with a less strict criterion than qualifying for semi-protection
• Low-traffic/low-watchlist pages with a less strict criterion than qualifying for semi-protection with a preference for pending change protecting BLPs.
• Any low-traffic/low-watchlist BLP page
• All BLP pages except those with the highest traffic / highest number of watchlists
• All BLP pages.

Poll 2 - Number of pages - to be held after the result of poll 1 is declared

N.B. This will be implemented in the software. Given that pending changes will be targetted at XXX, and until it can be improved significantly, its protection should be limited to this many pages.

• 0 - Effectively remove the feature
• 2,000 - As many pages as during the trial
• 10,000 - Moderate expansion
• 70,000 - Slightly bigger expansion
• 500,000 - Enough to cover all BLPs or a similar number of other articles
• Infinity - No limit on the number of pages that it can be applied to.

After that we could possibly have a poll three about which issues raised require the most attention, although I expect they will have been discussed further by then.

Yaris678 (talk) 15:23, 21 August 2010 (UTC)

In talking with Rob, I was somewhat persuaded that we won't be able to have a complex a poll as I (or you) would like. We probably only get one poll, because we can't expect people to keep coming back, so we might have to try and narrow down the options to the most likely packages based on people's comments. Rob has also mentioned that there are technical limitations which would prevent anything in excess of (50,000?), so I think that would be a hard upper bound, even without considering likely opposition to that as being too large too soon. We might be able to incorporate some preliminary policy consensus, for example:

...A review of the discussion revealed fairly consistent support for making pending changes faster, fixing the accept/unaccept interface, clarifying policy regarding when to accept edits, and emphasizing use on lower-traffic pages and BLPs rather than as a pure substitute for semi-protection, especially on high-traffic pages, pages which are highly vandalized, and pages protected due to sock-puppetry or content disputes. Ocaasi (talk) 15:48, 21 August 2010 (UTC)

Vote comment questions and format (possible)

As the trial of Pending protection is over, community consensus is required for its continued use. The community should now decide if the implementation should be continued or not:

Please respond to the questions below with a single number. In deciding consensus all the keep vote comments for option 2 and 3 will be first counted together to establish a keep or oppose consensus and if the result is keep then the consensus support between option 2 and 3 will be assessed (as a keep consensus will have already been asserted to have got to this point then this consensus with be just whichever has the most supports). Consensus will be judged by an Administrator on the basis of a simple head count (as there are no policy decisions to be considered) on the basis that 6 - 4 is a minimum consensus agreement. A no consensus outcome will default to close.

• 1 - Close.

• 2 - Keep as is, work on improvements. (this option still allows for adding and removing of articles to PP but with no major expansion)

• 3 - Keep as is, work on improvements with steady expansion ( from the present 1.4k to something between 5k and 10k ) low traffic/BLPs and any articles as requested.

• support (?) - Off2riorob (talk) 15:17, 21 August 2010 (UTC)

• - format and questions arrived at through discussion between User_Talk:Ocaasi and User:Off2riorob

Comments on the above proposal

Please comment on any objections or alterations to the above proposal, thanks. Off2riorob (talk) 18:52, 21 August 2010 (UTC)

A (more-or-less) straight up-or-down vote won't help unless we're allowed to give our reasoning for our vote. —Jeremy ^{(v^_^v Carl Johnson)} 19:55, 21 August 2010 (UTC)

The discussion page is for that. Off2riorob (talk) 20:21, 21 August 2010 (UTC)

That's the thing; who reads the discussion page? —Jeremy ^{(v^_^v Carl Johnson)} 20:29, 21 August 2010 (UTC)

Well, we have had quite a few comments there already, about fifty different users. Off2riorob (talk) 20:35, 21 August 2010 (UTC)

Oho, I see what you mean. —Jeremy ^{(v^_^v Carl Johnson)} 20:42, 21 August 2010 (UTC)

The simpler poll makes sense. Question: In option 3, is the intention that the number of pages be expanded as improvements are made or that it be expanded anyway, with the protections that (1) we are concentrating on low-traffic pages and (2) we will expand slowly and so we can stop the expansion if things start to go wrong? Yaris678 (talk) 23:14, 21 August 2010 (UTC)

Closure of discussion

moved from main page

As I can see discussion is petering out and I don't see much benefit arising from an extended period, I suggest implementing the consensus vote comment as per the talkpage at an early convenience. Off2riorob (talk) 20:16, 21 August 2010 (UTC)

Way too soon. Risker (talk) 04:52, 23 August 2010 (UTC)

New section

I'd like to create a new section for discussing specific issues of implementation going forward. If continuing the trial in some form is approved (which appears likely), there are still all of the issues with the user interface, reviewing guidelines, page application decisions, conflict resolution, etc. I'd like the discussion to shift focus towards those issues. Thoughts? Ocaasi (talk) 12:09, 23 August 2010 (UTC)

This seems like a good idea, but I would do it as a series of sub-pages rather than one section of the closure page. That way we can try to keep things together. I agree with the topics you suggest. I think it might also be worth having a page on "Pending changes iconography". This could deal with things like:

• the logo (which a lot of people don't like)
• The concern that the word "Approved" looks too much like it is definitely true.
• The possiblity that sneeky vandals might be motivated by getting their edits approved.

We could address all this by thinking about how we represent things.

Yaris678 (talk) 12:47, 23 August 2010 (UTC)

I'm not sure I see subpages as more together than separate sections. If we title them well, logo/reviewer guideline/which pages/statistics/etc. Then editors can go to the section they are interested in and keep it all on one page. Unless it gets too long, I think it would work. Ocaasi (talk) 13:10, 23 August 2010 (UTC)

I think having multiple pages will help people to focus and allow people to track changes to the bit they are interested in. A navbox could be used to allow easy navigation between the different areas. Yaris678 (talk) 17:01, 23 August 2010 (UTC)

I think it depends. If this is for the purpose of the closure discussion, I'd prefer sections on one page to keep critical mass of discussion (at least at first). If we're setting up long term areas for discussing the development of pending changes, which will be used after the vote, then sub-pages would eventually be useful. Ocaasi (talk) 05:35, 24 August 2010 (UTC)

Yes. I am thinking more in terms of longer term areas for discussing the development of pending changes. In terms of the closure debate, maybe we should just add a section for discussion what those areas should be. We have obviously suggested some, but we can open it to the floor. Yaris678 (talk) 09:52, 24 August 2010 (UTC)

What would you think about: user interface, reviewer guidelines, pageuse guidelines, vandalism... Ocaasi (talk) 10:04, 24 August 2010 (UTC)

My list would be:

• User interface and usability
• Guidelines on reviewing (re: Wikipedia:Reviewing)
• Reviewer behaviour (how we see what other reviewers are doing, how to avoid conflicts about reviewing decisions, what to do if some one is using their reviewer powers for the wrong purpose).
• When to apply pending changes protection (re: Wikipedia:Protection policy)
• Terminology and iconography

I assume that “when to apply pending changes protection” is what you meant by “pageuse guidelines”. I am not sure what would go in a section on vandalism, that wouldn’t be better targeted somewhere else.

Yaris678 (talk) 17:00, 24 August 2010 (UTC)

Additional thoughts:

• "Reviewer behaviour" could possibly include what is required of new people who want to be a reviewer.
• Possibly include a "Miscellaneous" section for discussing anything that doesn't fit neatly into the other bits. Same concept as Wikipedia:Reference desk/Miscellaneous.

Yaris678 (talk) 12:21, 25 August 2010 (UTC)

Disrupts effectiveness of watchlists

I saw the "clarify me" next to "Disrupts effectiveness of watchlists" in the work summary and decided to investigate. It looks like the complaints come down to "my watchlist has gone bananas with all this vandalism that has been going on". Therefore, the point is essentially the same as the more succinct "Some pages continue to suffer large amounts of IP/unconfirmed-user vandalism and so might be better to have semi-protection". Therefore, I have removed the point about watchlists.

I think that's part of it, partly linked to the way PC shows up on watchlists, and partly about how more vandalism "clutters" edit histories. Ocaasi (talk) 05:32, 24 August 2010 (UTC)

OK. The vandalism point is covered by the "should've been semi protected" point. I have changed the watchlist comment to highlight the way that pending changes are highlighted. Yaris678 (talk) 10:07, 24 August 2010 (UTC)

Trial complete?

If the trial period is over, why are pages still showing up here as needing review? --Auntof6 (talk) 22:55, 24 August 2010 (UTC)

I agree. Even if it is a big hassle to disable the feature entirely, we can get the admins to switch everything to either semi-protected or not protected.

I think the fact that the software is still being used, despite the end of the trial, is one reason why this whole post-trial phase is being rushed. We need time to look at the stats but people feel they need to justify the continuation of the trial NOW. Yaris678 (talk) 08:40, 25 August 2010 (UTC)

"Developers have indicated it would be too complex to turn off the feature then back on in case of decision in favor to continue the implementation, so they'll wait for the community decision, unless it takes more than a month in which case they would turn off the feature." -Wikipedia:Pending_changes/Closure Ocaasi (talk) 13:14, 25 August 2010 (UTC)

I don't think they will turn off the feature after a month if the community is working towards a decision and the wheels are not dropping of which they are not. Off2riorob (talk) 15:26, 25 August 2010 (UTC)

Ah... I had forgotten about the month thing. That just adds even more pressure to come to a quick decision. It would have been much better to take our time, analyse the stats, think things through. Yaris678 (talk) 12:25, 26 August 2010 (UTC)

Personally the way they've done it is the most sensible. A decision can be made, and once that is done pending changes can stop or continue. -- Eraserhead1 <talk> 18:20, 26 August 2010 (UTC)

Feature requests

Hi everyone, I thought I'd make a quick assessment of the feature bullet items. As with anything, the devil is in the details, but it's probably helpful to have at least a first pass at this:

• Ideas that are new to us, but worth considering and don't seem on the surface to be too tough (please file in Bugzilla):
  • - A "stop reviewing" button that marks the pending change as no longer "under review". Alternatively this button could be called "put back in queue" or "defer"
  • - A shorter timeout on the "under review", and/or use of Javascript to determine automatically when the review is no longer actively examining the article
• Ideas that are already in the queue
  • - Unapprove button should be hidden when innactive, not greyed out.
  • - Clearly labeled "Reject" button tied to the rollback or undo action on the review form using the reason entered as the summary
• Ideas that have been discussed, but need to be filed in Bugzilla
  • - More common names for PC specialpages, and a quick link to PC specialpages, in addition to notification of PCs on your watchlist
• Ideas that need further discussion and/or clarification:
  • Different logo for PC/Reviewers
  • Better links to documentation on PC related specialpages
    • Generally a good idea, but specific suggestions would be useful. Also, patches welcome.
  • Incorporate the PC protection rationale (protection log message) into the review screen as instruction to the reviewer.
  • Make it faster
    • There's some performance work that has been done, and more that we know we need to do.
  • - An "accept" button/link on the watchlist or page history without loading the full diffs - using popups for example
    • Some of the early feedback on the feature suggested the exact opposite
  • - Make page protection log more visible (reviewing depends on protection reason, but it's hidden by default)
  • - Add short reviewer instructions to the review page
    • Possibly a good idea, but a mockup of the proposed UI would be extremely helpful here to make sure we're not cluttering things up too badly.
  • - Easier access to preview/edit from the review page, for on-the-fly edits to pending changes
  • - Don't make reviewers who try to directly edit an article they're reviewing have to accept their own edits
    • This only should occur when a reviewer is editing an unreviewed article, which forces the reviewer to acknowledge "yes, I'm accepting the sum of my edits and the person(s) before me"
  • - Ability to leave short notes/questions for other reviewers on the review page itself
    • Seems like a generally good idea, but is more than a minor tweak and could use a good specification. This may not come above the cut line for features we could get to soon.
  • If another user preempts a page under review, make notification to the reviewer more obvious
  • An assisted tool for handling large pending changes queues (something along the lines of Huggle or Igloo)—before we have a large pending changes queue—to prevent a self-defeating backlog
  • Special:OldReviewedPages should separate out those pages that are on a lot of watchlists. It may be better for reviewers to concentrate on pages that they know about and pages on few watchlists.

I put a lot of these in the last category because, as I stated before, the devil is in the details. There are a large number of usability improvements and polish that this feature would benefit from. Furthermore, there are many improvements that can be made to the editing experience on MediaWiki that would benefit both Pending Changes-protected as well as other pages (e.g. diff and history improvements), so I imagine that Pending Changes improvements might be best handled as part of a more holistic look at the editing experience. -- RobLa-WMF (talk) 21:39, 26 August 2010 (UTC)

Thanks Rob for looking through the list and the very useful feedback. We could also use a very loose timeline for the changes, not as promises of course, but as a guide for voters on continuation of the feature. Given the straw poll's lack of any particular dates, changes which are not just easy or desired but that could be implemented quickly might influence opinions.

As far as bugzilla goes, who will put them in to make sure all are filed. Any takers?

Re: the broader features of MediaWiki, are there particular UI prototypes which include the features you're thinking of, for which we could get some sense of features and timeline? Thanks again, Ocaasi (talk) 15:00, 27 August 2010 (UTC)

Rob, in terms of 'A shorter timeout on the "under review", and/or use of Javascript to determine automatically when the review is no longer actively examining the article', which option are you thinking of using? I don't think there would be a need for a shorter timeout if the "stop reviewing" button could be implemented. Javascript sounds like a good idea though.

Also, did you notice that there is a further item on the feature request list?

Yaris678 (talk) 15:52, 27 August 2010 (UTC)

Which one? Ocaasi (talk) 16:25, 27 August 2010 (UTC)

The last one before the policy section "Changes of terminology could make this feature much more understandable and usable." I imagine that is will be on the "Ideas that need further discussion and/or clarification" list since we need to have the discussion about what we are going to call things. Yaris678 (talk) 17:34, 27 August 2010 (UTC)

I think he covered that through "More common names for PC specialpages", plus the various defer/revert/accept issues. What other terminology? Ocaasi (talk) 18:15, 27 August 2010 (UTC)

This new post on the feedback page has an interesting suggestion. Relating to his second point, I have also seen people saying they have an issue with "accepting" something that might not be true.

Has anything more been registered in Bugzilla then? I for one don't know how to... but I might do it if someone shows me where to start. Yaris678 (talk) 18:06, 5 September 2010 (UTC)

PC Terminology

Yeah, the "accepted" issue is part of the hang-up. That post you linked to is a bit confusing for the first part, and I can't say I agree with it. If you can put it into a constructive recommendation, go ahead. I do like his alternative for "visible", or something like it. I think "sighted" or "current" is about as far as we should go, even though accepted is technically accurate. Ocaasi (talk) 18:52, 27 August 2010 (UTC)

I think the first positive suggestion is that we should have a discussion. Who knows what wonderful ideas Wikipedians will come up with? I think "sighted" is what it was going to be called at one time. On the German Wikipedia it is called gesichtete, which Google informs me means visible. Of course, the rules on the German wikipedia are different. Really we need a word that means visible to all, to be contrasted to the pending version which is visible to some. How about manifest and concealed? Uncovered and covered? Uncloaked and cloaked? Obscured and apparent? The English language has a lot of words to choose from. Yaris678 (talk) 19:23, 27 August 2010 (UTC)

Maybe public. I don't like the opposite connotation (private), but it's basically Public and Pending versions. Ocaasi (talk) 19:37, 27 August 2010 (UTC)

Public could work, although the public does have access to the non-public versions... as I said, I think a wider discussion is the best idea.

<Geek mode>Perhaps the pending changes protection could be called Klingon protection to go along with the cloaked/uncloaked idea.</Geek mode>  :-)

Yaris678 (talk) 20:06, 27 August 2010 (UTC)

You'll have to take my word for it that I've never watched an episode of ST straight through. Nonetheless, that Captain Kirk fellow would know what to call it. Ocaasi (talk) 20:57, 27 August 2010 (UTC)

(indent) I see that Special:ValidationStatistics uses syncronized and outdated.

“ The average lag for pages with unreviewed edits pending is 28m57s. These pages are considered outdated. Likewise, pages are considered synchronized if there are no edits pending review. ”

Elsewhere on the same page, the pairing is fully reviewed and outdated.

Yaris678 (talk) 06:46, 28 August 2010 (UTC)

Outdated is interesting, although probably more negative than desired. Synchronized seems a bit too musical for my taste. Maybe other options like "Live", or "Active" get at the difference, although they can be a little ambiguous since again the 'public' version is kind of the inactive one, since it's not always current. I think discussion is going to settle on the more exact words, like "Reviewed", since that's all we can say it was. 10:20, 28 August 2010 (UTC)

I notice that Draft document mentions exposure draft and discussion draft, which sounds like what we are talking about... but the article doesn't elaborate on what these terms mean. Yaris678 (talk) 11:59, 29 August 2010 (UTC)

Were more readers familiar with the Pythagorean Mysteries we could use Esoteric and Exoteric. If more were espionage fans, then Overt and Covert. How about "Veiled" and "Unveiled"? Jim.henderson (talk) 13:47, 7 September 2010 (UTC)

wikt:esoteric:“belonging to an inner circle” and wikt:exoteric:“external”. I like those. It is a tradition that has been going on centuries - if you can't think of a decent English word, take one from the Greek. The others all have merit too. I think the most rigorous approach would be to compile a glossary of current terms and then come up with a rational system that replaces the whole lot. Yaris678 (talk) 19:12, 13 September 2010 (UTC)

I have just come across the page Wikipedia:Pending changes/Terminology. If people had been made aware of the page earlier on (like when they are made a reviewer) I think a lot of the confusion could have been avoided. However, the page doesn't cover all the terminology and that which it does use seems to be different from that which was implemented! e.g. no mention of outdated or synchronized, no mention of automatically accepted, the page mentions pending revision whereas the article history says pending review. Add to that the fact that there are better words out there, which make it clearer what is going on and offer less comfort to vandals and we can see there is still plenty of scope for improvement. Yaris678 (talk) 12:29, 14 September 2010 (UTC)

The style guide came late in the development, and thus, there are corners of the interface where "outdated" and "synchronized" still come up (see the comment I just made on MediaWiki talk:Validationstatistics-time). As for whether there are better words out there, perhaps there are, but it is an issue we spent a considerable amount of time on already. Further tweaking of the wording is just going to introduce confusion as old documentation clashes with new documentation, so I hope we'll try to make the existing wording work better rather that scrapping it and starting over. -- RobLa-WMF (talk) 16:44, 14 September 2010 (UTC)

I don’t know who you are referring to that has spent a lot of time and energy, but my guess is that it was a very small group of people who were more interested in how the software works. Now that a much larger group of people have been exposed to the software and have actually had to use the software, we are in a much better position to come up with some decent terminology. I don’t mind putting in a lot of the effort myself to come up with a new glossary and/or style guide, but I do think that we should widen participation to see what ideas other people come up with. A number of people have raised concerns about the terminology, including:

• It is confusing. I think this fact is confirmed by how hard it has been for a lot of people to get there head around how pending changes works.
• It gives sneaky vandals a buzz when they get their sneaky vandalism “accepted” by a reviewer.
• The word “accepted” in the corner of a version of an article could give the false impression of an assurance of quality and hence bring Wikipedia into disrepute when people find errors in the article.

Your point about the potential for a change to cause confusion is valid, but that is why it is important to sort this issue now, before pending changes is rolled out any further. The longer we wait the more difficult it will be to change; but it will still be confusing to new users and enticing to sneaky vandals.

Yaris678 (talk) 12:41, 15 September 2010 (UTC)

Yep. It's more important that we have good consensus driven terminology than using same terms as old documentation.Gerardw (talk) 23:03, 15 September 2010 (UTC)

I am not sure how effective a poll would be here...I would still like to express my vote in favour of "Live". Jimmy Wales was using this word in an interview last year (http://www.theworld.org/tag/wikipedia/ at -7:50) originally talking about other levels of protection. It sounded just right: "Live to the public", rather than somehow "pending". And best of all this doesn't seem to suggest any stamp of quality or even recency has been given (or at least minimizes those connotations) -Tesseract2 (talk) 17:05, 24 September 2010 (UTC)

I'm not arguing for a poll. Just a wider discussion, with more people, rather than this little discussion on an obscure talk page.

Live could work... although you do have the problem that the version that people see (which I assume you would call live) is not the version that is changing and growing (which could be someone else's idea of the word live). I like the performance metaphor though. Perhaps we could have something like "on stage" and "back stage".

Yaris678 (talk) 07:44, 16 October 2010 (UTC)

Is there any consensus for this change, and if so where is it?

(cross posted from WT:Protection policy-Beeblebrox (talk) 20:59, 7 September 2010 (UTC))

Talking about this edit [1]. Are we really at this point or is this user being overzealous? Beeblebrox (talk) 20:13, 7 September 2010 (UTC)

There was consensus for a two-month trial, which is now unquestionably over. The recent straw poll to start a further trial led to a clear no consensus. What's the issue? --Yair rand (talk) 21:27, 7 September 2010 (UTC)

Certainly no more articles should be placed on pending changes until consensus to do so is reached.—Kww(talk) 21:41, 7 September 2010 (UTC)

The thing here is that the protection policy has been edited to indicate that pending changes is over, as in over, and that all articles that had pending changes need to either be changed to semi protection or unprotected entirely. I haven't been following this all that closely, but at a glance I don't see a consensus that supports that. Beeblebrox (talk) 22:06, 8 September 2010 (UTC)

The original trial statement supports that: what's a "two month trial" if, well after two months later, the trial has never stopped? People are free to gain consensus for a new trial under whatever terms they think are reasonable, but it's not reasonable to allow the earlier trial to linger on indefinitely.—Kww(talk) 22:12, 8 September 2010 (UTC)

I agree with that, but unless we have decided to get rid of it it doesn't strike me as a particularly productive idea to go removing it from every article that had it applied when the function is in fact still completely active and there are still hundreds, if not thousands, of users still holding the "reviewer" user right. For the moment I have altered the wording [2] to more accurately reflect the current state of affairs. Beeblebrox (talk) 22:25, 8 September 2010 (UTC)

While I tend to agree with the above sentiments, I think if the agreement was for a 2 month trial and that period of time is already over, it's counter productive to consensus building on how to proceed not to honor the last consensus that was reached, no? ialsoagree (talk) 01:28, 9 September 2010 (UTC)

I'd split the difference. Until consensus is reached about what to do with the trial, I think it makes sense not to add PC to any new articles. I'd wait until a decision / compromise is reached for turning off the rest. Ocaaasi 03:40, 9 September 2010 (UTC)

That's an indefinite continuation of the trial, for which there is no consensus. "End" means "end", not "slow down". The trial has ended. The mistake was in the interface permitting the PC to last past the end of the trial. People ask what needs to be put into the next trial, and that's a must: if an article is put on pending changes, "indefinite" has to be overriden automatically to expire at the end of the trial. That way we won't get this happening again.—Kww(talk) 04:24, 9 September 2010 (UTC)

Another trial? How long are we going to discuss this? How long have we already been discussing it? Two years at least. Another trial can't be the right answer. We need to leave this thing on or turn it off for good. At this point I really don't care which, but it is way past time for an up or down decision on the matter. Beeblebrox (talk) 20:25, 9 September 2010 (UTC)

I've gone ahead and changed the warning box text on MediaWiki:Protect-text. It's my understanding that since the trial closed, the protection should not be added to any additional articles. Nakon 04:35, 13 September 2010 (UTC)

Well that is one idea but there is support for the continued usage and it allegedly can be added to articles if it is the best method of protection in the situation. Off2riorob (talk) 05:57, 13 September 2010 (UTC)

discussion box

Restored the discussion box. New comments can go below, or, if the community wishes to continue the discussion here, update the status text in the beginning and remove the box. Gerardw (talk) 04:36, 12 September 2010 (UTC)