[WikiEN-l] Bug 31424 - Anecdotal evidence of IE 8 problems
Hi everyone, We need your help. We have a number of reports on the various village pumps, helpdesks, Twitter, and such that IE8 users are experiencing crashes merely by visiting our site. Here's the bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=31424 Given the frequency and diversity of reports, there is almost certainly something to this, even though we don't yet have a solid repro case that a developer can actually use to fix this. Here's what we need. If you are actually seeing crashes, we would love to know exact browser version (e.g. IE 8.0.7601.17514), exact operating system version, all plugins installed and their exact versions, and how much RAM your machine has. Please report your findings either in the bug report above, or if you're more comfortable on-wiki, then here: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#If_you_can_make_IE_crash_pretty_reliably_we_need_your_help. Thanks! Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] [Foundation-l] Old Wikipedia backups discovered
On Tue, Dec 14, 2010 at 7:54 AM, Tim Starling tstarl...@wikimedia.org wrote: I was looking through some old files in our SourceForge project. I opened a file called wiki.tar.gz, and inside were three complete backups of the text of Wikipedia, from February, March and August 2001! This is exciting, because there is lots of article history in here which was assumed to be lost forever. Wow, this is really, really amazing! I'm not sure just how you avoided having a heart attack after seeing this: -- HomePage|979586833 1c1 Describe the new page here. --- This is the new WikiPedia! Great work! Rob ___ 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] Pending Changes development update: October 25
Hi everyone, This is another update on Pending Changes work. Over the Hack-a-ton weekend, Chad Horohoe and Priyanka Dhanda worked on two of the bigger features for the November 16 Pending Changes update: Bug 25294 - Reject button confirmation screen in Pending Changes https://bugzilla.wikimedia.org/show_bug.cgi?id=25294 Bug 25289 - Make review load faster by speeding up display of old revisions https://bugzilla.wikimedia.org/show_bug.cgi?id=25289 As of today, both of these are now deployed to our test site: http://prototype.wikimedia.org/flaggedrevs Additionally, since the last update, Brandon Harris has made a mockup available of some additional UI changes: http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/NovemberReleaseDesignChanges The full list of issues for the November 16 release is listed here: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=25293 We're not sure at this point just how much of the list we're going to make it through, but we plan to do additional updates shortly after November 16 with things that we don't get to. Please provide your input in Bugzilla if you're comfortable with that; otherwise, please remark on the feedback page: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback Rob ___ 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] Pending Changes development update: October 6
Hi everyone, Pending Changes work continues apace. The big thing we'd like to call everyone's attention to: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback#Call_for_specific_feedback_on_UI_elements We'd really like to get your input on specific suggestions that we can implement quickly. Speak now or forever hold your peace. Well, maybe not forever, but until after November. At least, if you want to implement your idea by November. Here are the main development tasks that are active right now: Bug 25294 - Reject button confirmation screen in Pending Changes https://bugzilla.wikimedia.org/show_bug.cgi?id=25294 Bug 25289 - Make review load faster by speeding up display of old revisions https://bugzilla.wikimedia.org/show_bug.cgi?id=25289 We'll be deploying the updates to these just as soon as they get checked in. Here's the location of the wiki we're using for testing development versions: http://prototype.wikimedia.org/flaggedrevs ...and finally, here's the full list of issues: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=25293 For those of you who might have missed it, Pending Changes was the primary topic for Sue Gardner's office hour last week. http://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_Sue_2010-09-30 Please provide your input in Bugzilla if you're comfortable with that; otherwise, please remark on the feedback page: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback Thanks! Rob ___ 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] Pending Changes development update: September 27
Hi everyone, As many of you know, the results of the poll to keep Pending Changes on through a short development cycle were approved for interim usage: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Straw_poll_on_interim_usage Ongoing use of Pending Changes is contingent upon consensus after the deployment of an interim release of Pending Changes in November 2010, which is currently under development. The roadmap for this deployment is described here: http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/Roadmap An update on the date: we'd previously scheduled this for November 9. However, because that week is the same week as the start of the fundraiser (and accompanying futzing with the site) we'd like to move the date one week later, to November 16. Aaron Schulz is advising us as the author of the vast majority of the code, having mostly implemented the reject button. Chad Horohoe and Priyanka Dhanda are working on some of the short term development items, and Brandon Harris is advising us on how we can make this feature mesh with our long term usability strategy. We're currently tracking the list of items we intend to complete in Bugzilla. You can see the latest list here: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=25293 Many of the items in the list are things we're looking for feedback on: Bug 25295 - Improve reviewer experience when multiple simultaneous users review Pending Changes https://bugzilla.wikimedia.org/show_bug.cgi?id=25295 Bug 25296 - History style cleanup - investigate possible fixes and detail the fixes https://bugzilla.wikimedia.org/show_bug.cgi?id=25296 Bug 25298 - Figure out what (if any) new Pending Changes links there should be in the side bar https://bugzilla.wikimedia.org/show_bug.cgi?id=25298 Bug 25299 - Make pending revision status clearer when viewing page https://bugzilla.wikimedia.org/show_bug.cgi?id=25299 Bug 25300 - Better names for special pages in Pending Changes configuration https://bugzilla.wikimedia.org/show_bug.cgi?id=25300 Bug 25301 - Firm up the list of minor UI improvements for the November 2010 Pending Changes release https://bugzilla.wikimedia.org/show_bug.cgi?id=25301 Please provide your input in Bugzilla if you're comfortable with that; otherwise, please remark on the feedback page: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback Thanks! Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] [Foundation-l] Pending Changes update for July 28
On Wed, Jul 28, 2010 at 2:48 PM, Carcharoth carcharot...@googlemail.comwrote: On Wed, Jul 28, 2010 at 1:43 PM, Rob Lanphier ro...@wikimedia.org wrote: For a variety of operational reasons, we plan to leave the feature running while the community decides whether to keep the feature on, assuming that process lasts no more than a month or so after August 15. Sounds reasonable. You will have to very firmly commit to turning it off immediately if the vote/discussion goes against it though, as some will (despite the reasonable explanation given here) see this as a back-door route to keeping it on by default. This is definitely not the case. We plan to abide by whatever consensus emerges. One question I do have is how much attention is given to the main talk page at WT:PEND? The impression I get is that most of the discussion is happening elsewhere, and some people will miss that discussion if there are not pointers from that talk pages to the talk pages of the subpages. I believe this page is getting more attention than WT:PEND: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback Rob ___ 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] Pending Changes update for July 28
Hi folks, It's been a little while since I've sent out an update (sorry about that). The Pending Changes trial continues apace, with 1,382 articles configured to use the feature as of this writing. Most of the work on the software that powers Pending Changes is focused on refactoring and stability. Some of the performance problems associated with this feature have been fixed, and we believe we have fixed all of the user-visible performance problems. Looking at our backend systems, there's some areas where this feature is still causing more load than it should, which is where our work is focused now. Aaron Schulz, who has done the lion's share of the development to date (thanks Aaron!) continues to stay involved, but at a much reduced level as he focuses on non-Wikimedia stuff, while Chad Horohoe ramps up. We'll be publishing some statistics soon which outline per page metrics on revisions under Pending Changes. Nimish Gautam and Devin Finzer (Devin is an intern that is working for Wikimedia Foundation this summer) are working on some statistics that they'll be publishing soon. More discussion is here: http://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes/Metrics It will be time for a vote soon about whether to keep Pending Changes enabled on en.wikipedia.org. We'll be pinging folks in the community about the post-trial discussion. If we're rigidly following the proposal, the trial will end on August 15, regardless of whether a vote has happened. However, we're probably already running late for making a decision by then. For a variety of operational reasons, we plan to leave the feature running while the community decides whether to keep the feature on, assuming that process lasts no more than a month or so after August 15. The main discussion area for this feature is here: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback If you have comments/suggestions/questions, that's a good place to post them. Rob ___ 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] Page load speed on some Pending Changes diff pages
Hi everyone, Anyone who has played with Pending Changes knows that in many circumstances, there were some very perceptable speed problems with the feature on complicated pages (which unfortunately, tend to be the pages that the feature is used on). The devs on the feature (Aaron and Chad) did some investigation, and figured out that we weren't caching as much as we should. This is all documented here: https://bugzilla.wikimedia.org/show_bug.cgi?id=24124 This change was rolled out on en.wikipedia.org. So, if you hadn't played with Pending Changes in a while because of speed problems, now is a good time to give it another shot. Visit here: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes ...and follow the Pages with pending edits and the All pages on trial links to find articles to try this out on. We're not done with the performance work, but this particular fix was pretty critical for the experience. Rob ___ 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] Pending Changes update for June 18
Hi everyone, As I'm sure you're all aware, the Pending Changes trial began earlier this week, and seems to be off to a great start. There are many issues to be sorted out both on the community policy side and on the technical side, but everyone here seems to grappling with the community issues without a lot of prodding. On the development front, the team now has a blissfully mundane software maintenance/incremental improvement process to deal with, as opposed to feeling antsy about needing to deploy. With the launch out of the way, William is now wrapping up and turning the project management reigns over to me. When I first started contracting with WMF back in the beginning of May, I had the mistaken assumption that I'd be taking over then, since William had/has another huge opportunity that is looming on the horizon that appeared likely to take 100% of his time. In our first meeting as we started going over the transition, he resolutely pointed out no, I'm staying until we deploy this, however long it takes. We are really glad he was able to stick with us through this, and we're extremely grateful for his tenacity and commitment. This feature would likely have been delayed longer and would have missed many critical details without him. I learned a lot about project management working with him, and enjoyed it a great deal. Thanks William! The main developers, (Aaron and Chad) plan to continue knocking down issues as they discover them, as well as continuing to whittle down the backlog of issues we postponed until after the initial deployment: http://www.pivotaltracker.com/projects/46157 Some of the most significant work surrounds the reject button an a few related tweaks. Since the topic of how exactly to optimize the workflow is still a subject of debate, we'd appreciate some feedback on the subject. The features in question are all linked to from here: http://www.mediawiki.org/wiki/Extension:FlaggedRevs/Specifications The trial itself is slated to last until August 15. After that, community consensus will be required to leave the feature on permanently. A strict reading of the proposed trial would suggest we're obligated to turn the feature off immediately around August 15, but I've seen at least one comment suggesting we leave it on that time. I've proposed here that we instead leave the feature turned on while we discuss the permanent status: http://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes/Trial#leaverunningforvote If you have any concerns that need the dev team's attention, please bring them up here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Pending_Changes_issues We're a little behind in looking at that page, but we will get back to you if you post there. We'll also get back to you if you prefer to post to Bugzilla: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensionscomponent=FlaggedRevs That's all for now. Thanks for reading! Rob p.s. I didn't want to turn this email into a parody of an overly-long Oscar speech, but I also did want to specially call out Aaron Schulz, the lead developer on this project, who did a remarkable job developing and preparing the software for this launch as well as making sure that any problems that we did inadvertently introduced were knocked down extremely quickly (often within minutes of finding out). Great work, Aaron! ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] Pending Changes launched on English Wikipedia
On Wed, Jun 16, 2010 at 10:48 AM, Thomas Dalton thomas.dal...@gmail.comwrote: For those who want to get a sense of how the system is performing in terms of throughput (e.g., average time-to-approval), please visit the Pending Changes Stats page [7]. the average, median and lag are all showing as 0.0s. That can't be right, surely? Is that a bug? Yeah, something there doesn't look right. We'll look into it further. Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] Community ready for Pending Changes (nee Flagged Protection)?
On Tue, Jun 8, 2010 at 4:34 AM, FT2 ft2.w...@gmail.com wrote: On Tue, Jun 8, 2010 at 6:29 AM, Rob Lanphier ro...@wikimedia.org wrote: 3. This set of pages: http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions ...still has the old vocabulary, and still refers to patrolled revisions as part of the trial (which is a separate feature that probably won't be completed by the time the trial is over with). [..] Might it be worth gathering all Flagged Revs pages and moving them to [[WP:Pending Changes/Historical discussions/...]] with redirects, to make clear what's what? That would be wonderful! I suspect there's some sensitivity around the word obsolete since patrolled revisions is a feature that still has a popular following. However, at this point its just not as tightly coupled with the pending changes trial as it once was. So the trick is going to be to decouple the two enough so that it doesn't confuse people about what's happening now versus what is on the roadmap, but not so decoupled that the patrolled revisions proposal gets exiled to Siberia. Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] Community ready for Pending Changes (nee Flagged Protection)?
On Tue, Jun 8, 2010 at 11:54 AM, FT2 ft2.w...@gmail.com wrote: One thing needed - can someone reply to this thread with a list of all Flagged Revs related pages (whether RFCs, proposals, or major threads) so we can see what's out there? I don't have an organized list, but I started a stub page here: http://en.wikipedia.org/wiki/User:RobLa/PC_Page_Inventory To everyone here: please add to the list. Also, feel free to move that out of my user space to wherever you feel is appropriate. Thanks Rob ___ 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] Renaming Flagged Protections to Pending Changes
Hi everyone, After much debate, we've settled on a name for the English Wikipedia implementation of FlaggedRevs: Pending Changes. This is a slight variation on one of the finalists (Pending Revisions) which has the benefit of using the less jargony term changes instead of revisions. The MediaWiki extension will continue to be named FlaggedRevs, but the greatly simplified subset of functionality that editors and readers on en.wikipedia.org will see will be referred to as Pending Changes in the user interface, help documentation, and other places that we'll talk about this feature for non-developers working on English Wikipedia. Thanks everyone for weighing in! We'll be updating the message strings on flaggedrevs.labs to reflect the new name: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Message_updates Rob On Wed, May 26, 2010 at 3:27 PM, Rob Lanphier ro...@wikimedia.org wrote: Hi everyone, It looks like the discussion on the name is dying down, so I'd like to summarize what I think we've heard here: 1. There's no clear favorite out there. In addition to the two ideas we put forward (Pending Revisions and Double Check), there's been quite a bit of discussion around alternatives, for example: Revision Review and Pending Edits. 2. There's are still some that aren't comfortable changing the name away from Flagged Protection, but that doesn't appear to be a widely held view. 3. Some people like Double Check, but some people dislike it a lot. The people who like it seem to be comfortable with the colloquial use of it, whereas the people that dislike it don't like the lack of precision and the possible confusion created by the use of the word double. 4. Pending Revisions seems to be something most people would settle for. It's probably not the hands down favorite of too many people, but it doesn't seem to provoke the same dislike that Double Check does. 5. Pending Edits is a simplification of Pending Revisions that seems to have some support, as it replaces the jargony Revision with the easier Edits 6. Hyperion Frobnosticating Endoswitch seems to have gathered a cult following. Yes, we have a sense of humor. No, we're not going there. :-) A little background as to where we're at. Double Check had an enthusiastic following at the WMF office, but we're not inclined to push that one if it's going to be a fight (it's far from the unanimous choice at WMF anyway). Revision Review seems to be heading a bit too far into jargon land for our comfort. Pending Revisions is the compromise that seems to stand up to scrutiny. A variation such as Pending Edits or Pending Changes also seems acceptable to us. That's where we stand now. If you haven't spoken up yet, now is the time, since we're only a couple of days from making a final decision on this. Please weigh in here: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Terminology Thanks Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] Renaming Flagged Protections
Hi everyone, It looks like the discussion on the name is dying down, so I'd like to summarize what I think we've heard here: 1. There's no clear favorite out there. In addition to the two ideas we put forward (Pending Revisions and Double Check), there's been quite a bit of discussion around alternatives, for example: Revision Review and Pending Edits. 2. There's are still some that aren't comfortable changing the name away from Flagged Protection, but that doesn't appear to be a widely held view. 3. Some people like Double Check, but some people dislike it a lot. The people who like it seem to be comfortable with the colloquial use of it, whereas the people that dislike it don't like the lack of precision and the possible confusion created by the use of the word double. 4. Pending Revisions seems to be something most people would settle for. It's probably not the hands down favorite of too many people, but it doesn't seem to provoke the same dislike that Double Check does. 5. Pending Edits is a simplification of Pending Revisions that seems to have some support, as it replaces the jargony Revision with the easier Edits 6. Hyperion Frobnosticating Endoswitch seems to have gathered a cult following. Yes, we have a sense of humor. No, we're not going there. :-) A little background as to where we're at. Double Check had an enthusiastic following at the WMF office, but we're not inclined to push that one if it's going to be a fight (it's far from the unanimous choice at WMF anyway). Revision Review seems to be heading a bit too far into jargon land for our comfort. Pending Revisions is the compromise that seems to stand up to scrutiny. A variation such as Pending Edits or Pending Changes also seems acceptable to us. That's where we stand now. If you haven't spoken up yet, now is the time, since we're only a couple of days from making a final decision on this. Please weigh in here: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Terminology Thanks Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] [Foundation-l] Renaming Flagged Protections
Hi Phoebe, Replies inline... On Wed, May 26, 2010 at 12:12 AM, phoebe ayers phoebe.w...@gmail.comwrote: On Tue, May 25, 2010 at 1:04 PM, Rob Lanphier ro...@robla.net wrote: We're planning to change label of the Pending changes tab to Pending revision, since what people will see when they visit that tab is the pending revision, not the diff against the old version. The nice thing about then naming the feature itself Pending Revisions is that it aligns with what people will see as the most prominent feature of the UI. Got it. Well, I personally like pending revisions, as I said (bit long for a tab label, but oh well). So, as I mentioned in my previous email, we're dabbling with the idea of Pending (something else). See: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Terminology#Pending... Can it go to the other side of the history tab though, so it doesn't show up before the edit tab when reading across? (I'm sure there's an argument to be made both ways, but I'd expect a new feature to show up as the last tab in standard UI design). I'm not sure what the rationale is, but I asked here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:FlaggedRevs_issues#Tab_placement_in_Vector_and_Monobook Where will it go in Vector? Hrm...we should probably make Vector default on the test site. I'm looking into that. At any rate, you can see it by logging in at http://flaggedrevs.labs.wikimedia.org and visiting a page that has pending revisions. An example (as of this writing) is here: http://flaggedrevs.labs.wikimedia.org/wiki/Hurricane_Vince_(2005) Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] [Foundation-l] Renaming Flagged Protections
On Tue, May 25, 2010 at 12:15 PM, phoebe ayers phoebe.w...@gmail.comwrote: On further thought... what about Pending edits ? I do like pending as part of the name, especially if this is the name going on the UI for the link/tab/whatever where you would see them. It also seems to me that the name in the UI doesn't have to be quite the same as the name of the feature itself -- here is where you see the pending edits, which are part of the revision review feature, aka special:flaggedrevs. (or something). Hi Phoebe, We considered going in that direction. The tough part about it is that the name goes against the grain of what we want to use in the UI. Take a look at this page: http://flaggedrevs.labs.wikimedia.org/wiki/Hurricane_Vince_(2005) We're planning to change label of the Pending changes tab to Pending revision, since what people will see when they visit that tab is the pending revision, not the diff against the old version. The nice thing about then naming the feature itself Pending Revisions is that it aligns with what people will see as the most prominent feature of the UI. Rob ___ 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] Flagged Protection Revert Etiquette (Re: Renaming Flagged Protections)
On Fri, May 21, 2010 at 9:58 PM, Carcharoth carcharot...@googlemail.comwrote: By the way, I'm assuming that some edits will be of the sort I would normally remove the material and start a talk page discussion. In that case, is the right thing to do to approve the edit and then remove the material and start a talk page discussion, and presumably as a reviewer, your edit removing the material won't be caught up in flagged revisions itself? Starting a separate thread since this is off of the naming topic. I don't think it's necessary to accept the edit, since the unaccepted version is never really marked as rejected in the edit history per se, but rather, just never gets promoted. The edit will still exist in the edit history, so it's not lost forever. The right thing to do is to do the exact same thing you would do with an unprotected page. If it's not obviously vandalism, you can use the undo function with a polite note in the edit comment to discuss the change on the talk page. Presumably, you're doing this as an autoconfirmed user, which means that your edits will be automatically accepted. Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] Flagged Protection Revert Etiquette (Re: Renaming Flagged Protections)
On Sat, May 22, 2010 at 12:05 AM, Carcharoth carcharot...@googlemail.comwrote: Can you reject with a let's discuss on the talk page? What I am thinking is that some people use edit summaries to alert other editors to a talk page discussion, and if this is not possible with the FlaggedRevs system, I would be inclined to accept an edit and then revert it and suggest a talk page discussion. At this very moment, there is no reject button. That's one of the last minute features that we're working on here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Reject_Pending_Revision There is already a comment entry field beside the approve (accept) button right now, and there's no reason I can see why that same comment entry field won't be used for the proposed reject button. There is currently a de-approve button (which we're renaming unaccept), but that's only for the rare case where someone has accepted a revision, and then you're unmarking it. What I'm asking is whether you need to accept first or not. Nope, you shouldn't need to. I get the impression from what you are saying that you can click undo straightaway and that automatically accepts the edit and undoes it in one step (I would replace the automatic undo summary). Not quite. This is what a whiteboard is really handy for :) I'm guessing you may have a slightly incorrect way of thinking about how the feature works, and that's causing some confusing in cases like this. It may be helpful to understand how this feature works under the hood to be able to visualize what's happening. Each revision has a flag associated with it (the accepted flag) which by default is false (unaccepted). Approving/accepting an article flips that flag to true (accepted). The article that gets shown is the latest one with the flag set true (accepted). The thing that's very confusing for people is that they want to think about three states for a given revision: approved, rejected, and unreviewed. That's not the way the feature is implemented though. Rejected and unreviewed are indistinguishable at the database level. There is a distinction that's a fair approximation for rejected versus unreviewed, which is by answering the question is there a later accepted revision than this unaccepted revision I'm looking at? If there is, then the revision is implictly rejected. If there isn't, then the revision is implicitly unreviewed. That's how this feature works. We treat unaccepted revisions after the latest accepted revision as pending revisions. So, back to your question. When you click undo on a pending revision, there's no magic accepting going on of the pending revision. Instead, you're just putting an accepted revision after it, thus implicitly rejecting that revision. Normally, when reverting and adding a custom edit summary, I load the previous page version and save that with an edit summary. But I don't think that will work here, though maybe it will. Yup, that will still work just fine. I suspect that any action by an autoconfirmed user will automatically accept something of any actions not yet reviewed. Will those autoconfirmed users get a warning that they might unwittingly be accepting edits they might not have reviewed? Yup, they do. There's a banner at the top of the page that tells them exactly this. Rob ___ 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] Renaming Flagged Protections
Hi everyone, As William alluded to, a bunch of us have been studying the user interface for Flagged Protections and figuring out how to make it more intuitive. In trying to solve the user interface problems as well as generally figuring out how we're going to talk about this feature to the world at large, it became clear that the name Flagged Protections doesn't adequately describe the technology as it looks to readers and editors. It's a tough name to work with. This iteration of the technology is very different from the German implementation, and there's no flagging in the proposed configuration. Additionally, protection in our world implies no editing whereas this feature actually opens up pages currently protected so that everyone can edit. So, we would like to make a change to the name of the Flagged Protections feature prior to deploying it to en.wikipedia.org. Under the hood, we would still be using the FlaggedRevs extension (no change there), but the name that we talk about in the user-visible portions of the site and documentation would be something new. Here were some criteria we're using to find a name: - Must not introduce obsolete terminology (e.g. there's no flagging in our proposed deployment) - Terminology should be consistent with terms we want to use in the user interface - Must not make too strong of a statement of quality/consensus or terms that make us out as publishers approving content from the mountaintop - Should not imply we're creating an elite new classes of users - Should not convey a strong sense of restriction. The feature, as proposed for the trial [1], is less restrictive than semi-protection - Should not be too geeky/too technical/too jargony - Should not be too slick/too cutesy. We're not doing this in the name of creating glossy brochures with pictures of a conference room full of people in formal business attire nodding with approval at a projection of a pie chart - we just want a name that won't be confusing. It turns out that filters out quite a few names (including Flagged Protection among other things). Here's the alternatives that made the cut: - Pending Revisions - this name is very consistent with what everyone will see in many parts of the user interface, and what it will be used for (i.e. providing a queue of pending revisions) - Double Check - this was a late entrant, but has the distinct advantage of clearly communicating what we envision this feature will be used for (i.e. enforcing a double check from a very broad community). A protracted debate on the name will likely delay the eventual launch on the feature, so we're hoping we can have a quick, respectful discussion on the merits of the different proposals so that we can make the change quickly and move on. We really need to have a name fully locked down no later than Friday, May 28. Please let us know your thoughts here: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Terminology We're in the process of working on a lot of terminology tweaks in the user interface in anticipation of the launch. If you're interested in that detail work, I'll post more information about that on wikitech-l (hopefully by end-of-day Monday), as well as on the talk page above. Rob [1] - See the proposed configuration for trial phase: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Trial ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] Renaming Flagged Protections
On Fri, May 21, 2010 at 3:34 PM, FT2 ft2.w...@gmail.com wrote: Might help to sum up what exactly it does or how it's used (2-4 bullet points) so that people trying to pick a name to match its features but haven't followed the lengthy debate, are up to date on it. That's fair. Here's the gist of it: * An unprotected article gets put under Pending Revisions/Double Check by an admin * From that point forward, edits from anonymous users are listed as pending revisions, and aren't displayed to other anonymous readers by default (though they'll be accessible from a pending revisions tab) * Any autoconfirmed user can then mark the latest pending revision as accepted, or revert to the latest accepted revision. I just uploaded a bunch of images that may help people visualize the feature as we see it: http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Terminology Here's the permissions as we're currently planning to deploy them for the trial: http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Trial Rob ___ 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] Flagged Protection trial page
Hi everyone, In William's update, he wrote: On Thu, May 13, 2010 at 10:25 PM, William Pietri will...@scissor.comwrote: Also upcoming is [...]some work with the community to figure out the remaining details of the community side of the trial (keep an eye on RobLa's activity there) More on that. If you haven't kept a watch on the following page, and you're really interested in what were planning on, I'd suggest you put this one in your watchlist: http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Trialhttp://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Trial#Reviewing This past week, I've updated the sections on Reviewing and created a new Initial article count limits section, as well as some shuffling and trimming. We want to make sure that what we have passes muster from a simplicity standpoint, so you'll notice that what's there is greatly simplified from some of the other proposals that have been floated. The idea here is to make sure we have a plan ready to go if the trial were ready to start tomorrow. That's not to say that the trial *will* start tomorrow, but we're getting close enough to being ready that we need to lock these things down, because there are very few things that require code changes that we'll be willing to consider at this point. If you have any comments/suggestions/complaints/etc about the policy, please reply here, or put them on the talk page for the trial. Thanks! Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Re: [WikiEN-l] Flagged protection and patrolled revisions
On Fri, May 7, 2010 at 10:25 AM, Aryeh Gregor simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com wrote: How about this. No message on the edit page itself. When they save the edit, they're redirected to the draft page of that article, with a message at the top saying something like This is a publicly-viewable draft, and will be shown to all viewers by default after review. There's no need to mention it *before* the edit, is there? Hi Aryeh, I think this an idea worth discussing more, but I think the idea may get lost if it stays solely on this mailing list, so here's what I'm going to recommend: 1. File a bug on bugzilla.wikimedia.org. 2. Let me know that you've done that. 3. I'll add further consideration to our backlog I'm pretty doubtful that we'll be able to get to this before launch. My understanding here (based on what I heard in the WMF meeting, but I may have misheard) is that what is being requested is how the German Wikipedia used to work, and they switched it to the current behavior. That means that, at a minimum, we'll need some more time to think about the proposed change than we'd like to let delay the initial trial. That's not to say that we won't get to it, but getting more experience with the feature would be best before tinkering with this aspect of it. Make sense? Rob ___ 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] Fwd: Ramping up the Flagged Revs trial
Hi folks, As we've gotten down to brass tacks in planning the deployment of Flagged Revisions on en.wikipedia.org, it's become obvious that we'll probably need to limit the number of articles put under Flagged Protection at first. A couple of reasons for doing this: a) Performance - we know already from de.wikipedia.org and from watching flaggedrevs.labs.wikimedia.org that this feature can impact performance. So, we'd like to start small and build up from there b) Community norm development - we'd like to give the community a chance to use this in production in a limited way to start with to get a feel for the feature in the wild. We suspect many people will appreciate the opportunity to see this in action and get a better sense of the policy implications without having to worry about finding that half of English Wikipedia is under Flagged Protection. So, we're planning on putting an upper bound of 2000 articles when we start the trial. We'll then see how this plays out. If performance takes a severe hit, we'll need to work with the admin community for a plan to back down from that number (in lieu of total reverting the feature). If things are going well on all fronts, we can possibly bump things up. I've outlined this here: http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions/Trialhttp://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Trial What would be useful for this group to figure out is: 1. What articles would be the best candidates to start off with? From a technical perspective, it'd be really handy to have a representative sample of traffic characteristics (e.g. high traffic and low traffic articles), since caching is one of the big areas of performance hit. 2. If we need to start weeding out articles to get the total count down, what order should we go in? Please leave your thoughts on the talk page, and/or flesh out the portions of the main article that still need love (that page in particular needs some help). Thanks! Rob ___ 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] Helping out with Flagged Revs
Hi folks, As of today, I'm working as a contractor at Wikimedia Foundation, helping out with several things, one of which being the Flagged Revs rollout. One thing I'm going to be helping William and the crew out with is working out some of the unanswered questions in the description of the rollout phase: http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_revisions (and accompanying pages) I've been following the threads and playing around with the features, but I'm probably not as up to speed on this stuff as many of you are, so I'm sure I'll be begging your indulgence from time-to-time. If there is anything on the pages above that you know needs correction or clarification based on the existing consensus, please be bold make that fix. Citations back to email discussions on anything controversial would be especially helpful for me, but not required. I'll be updating those pages based on my understanding, so it'll be helpful to start from a base of current understanding rather than what the understanding was a year ago. Thanks for your help! Rob ___ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
