Misplaced Pages

This is an old revision of this page, as edited by DGG (talk | contribs) at 04:41, 5 July 2013 (→User Council). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

• Table of contents
• First discussion
• End of page
• New post

• WP:VPR
• WP:VP/PR
• WP:VPPRO
• WP:PROPS

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Misplaced Pages:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Misplaced Pages:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Misplaced Pages:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Misplaced Pages:Requested articles.

Centralized discussion Village pumps policy tech proposals idea lab WMF misc Refining the administrator elections process Blocks for promotional activity outside of mainspace For a listing of ongoing discussions, see the dashboard. view edit history watch archive talk purge

Misplaced Pages is too big. Please make it smaller.

Let's figure out a little bit more about how new editors are signing up

Every day we get around 3-4,000 people signing up for Misplaced Pages. The majority of these people (~70%) do absolutely nothing with their accounts. With work like GettingStarted, VisualEditor, and others we're trying to change that, but we still know very little about what people who are signing up every day want to do. My team recently just finished the redesign of the signup and login pages, and that includes a tool that has been around in some form before: the ability to add a campaign name to a link, so we know how many people sign up via it. (It only works on the account creation page, and it's not publicly logged anywhere.)

Anyway, of the many experiments my team might run, some are aimed specifically at the kind of editor who is trying to edit a page but doesn't yet have an account. We'd like to get a handle on this by adding campaigns to the anon edit notice and the view source notice for semi-protected pages. I've dropped notes at both those pages (here and here) but they're not very high-visibility, so I'm cross-posting. Please comment there if you're interested. If we can learn how many new signups happen because pages they are trying to edit are semi-protected, or because they decide to signup after clicking Edit on any other page, that helps us know how much effort we should be spending on this area, as opposed to say, new article creators.

Let me know if you have any questions. Campaigns are easy to set up and are potentially something that could be of use to WikiProjects or groups like the Teahouse, so if you're curious please speak up. Steven Walling (WMF) • talk 01:27, 19 June 2013 (UTC)

Could/should we add campaign links to the various anon-specific welcome templates ? Possibly we're already tracking this? –Quiddity (talk) 02:05, 19 June 2013 (UTC)

Not a bad idea. We're not already tracking that, to my knowledge. Steven Walling (WMF) • talk 02:09, 19 June 2013 (UTC)

And Misplaced Pages:Why_create_an_account? which is linked from quite a few places (including the templates you linked to). —TheDJ (talk • contribs) 13:02, 19 June 2013 (UTC)

Where I just did a bit of cleanup. —TheDJ (talk • contribs) 13:30, 19 June 2013 (UTC)

Has anyone thought of the possibility that the accounts being signed up and then not used are spam or bot accounts, similar to the accounts that are signed up on forums? I don't know the inner workings of MediaWiki all too well, but bots that invade forums have been able to bypass both their captcha and re-captcha, so I don't doubt the same is possible here. Adversly, I believe it has been discovered that spam "people"/companies are hiring humans to bypass the captcha and then turning the accounts over to a machine to use for malicious purposes. I don't mean to discourage the efforts to introduce potential editors to the encyclopedia, just thinking of all of the possibilities that we have so many accounts being signed up but hardly any used. Jguy _Talk 15:41, 19 June 2013 (UTC)

Historically, there have been a lot of spam/vandal throwaway accounts registered. However, before the edit filter it was quite easy to see what proportion of those actually became spam/vandal accounts, since they inevitably went on to do so - but this still left a lot of registered-but-never-edited accounts. Andrew Gray (talk) 20:32, 21 June 2013 (UTC)

Not sure how to find out the statistics, but I would surmise that many of these 70% of new users never record and promptly forget their password after changing from the initial random one. A gentle reminder ("Please record or memorize your new password") shortly after password changes would seem like an easy way to avoid much of this. Also, was the 70% figure based on all the connected wikis, or just the English-language Misplaced Pages? LeadSongDog come howl! 18:01, 19 June 2013 (UTC)

Also consider accounts of readers who never edited, but changed their user preferences. Are they being counted in the 70%? Kilopi (talk) 10:57, 20 June 2013 (UTC)

Yes, I mean all new accounts. Steven Walling (WMF) • talk 21:11, 20 June 2013 (UTC)

It's definitely a mix of reasons. Some of the people are actually trying to edit, but wikitext scares them away. Others are trying to upload a file, and find out they need to be autoconfirmed. But yeah, I think some of them are forgetting their password and failed to register an email address. The new signup form still marks it as optional, but we know that more people register with an email address in the new form though, so it helps combat the "I lost my password and have no way to recover it" problem. Steven Walling (WMF) • talk 21:05, 19 June 2013 (UTC)

• It could also be because people may (mistakenly) believe they need an account to read Misplaced Pages, or otherwise may be missing some content by not registering. Many people may just create accounts to every website that allows them to do so, including Misplaced Pages, and they may never have any immediate desire to edit Misplaced Pages. They likely either mistakenly believe they need to to read it, or they simply register for everything, unthinkingly, and semi-automatically. --Jayron32 21:26, 20 June 2013 (UTC)
• Support I understand this proposal as a request to conduct A/B testing on advertisements which would make offers to help new users become engaged to follow through with their motivation for registering an account. I hope that the tests are documented a bit and that you continue to maintain good communication about the research, but this kind of testing and research needs to be done and I support this completely. Blue Rasberry (talk) 05:51, 21 June 2013 (UTC)
• If a username is unused after (say, a year), cancel it and free it for re-use? (How many total usernames are listed for Misplaced Pages?) Anthony Appleyard (talk) 07:32, 21 June 2013 (UTC)
• @Anthony Appleyard: Special:Statistics says there are 19,181,153 registered accounts, of which only 124,793 have edited in the past 30 days. I make that that only 0.65% of all user accounts are active. I agree something needs to be done about this - a large number of usernames are ties up, that could otherwise be of use. Mdann52 (talk) 10:09, 21 June 2013 (UTC)
• There is also a number of accounts that will 'automatically' get registered here due to existing on another wiki, I imagine this number is rather high. I am all for adding campaign links to all of the welcome templates! Would be great to be able to see! ·addshore· 10:48, 21 June 2013 (UTC)

• Update: TheDJ has gone ahead and added campaigns to the two MediaWiki messages I mentioned before. @TheDJ: @Quiddity: et al. We haven't yet added any to the anonymous welcome templates. I'm happy to do that whenever, but I have a logistical question... do we want individual campaigns for each template, or one campaign for them all? I would suggest we start with the latter, and get a sense of overall, how many new registered editors signup because of an anonymous welcome template. Once we have that overall baseline, we can talk about whether it's necessary to know which individual templates are most popular. Thoughts? Steven Walling (WMF) • talk 19:02, 21 June 2013 (UTC)
  • That sounds good to me. Relatedly, I made some comments about welcome-templates over at mw:Talk:Flow Portal/Welcome Module. We might want to consider updating some of the templates, whilst we're adding links to them? (Though I do like your minimal welcome template, too ;) –Quiddity (talk) 19:16, 21 June 2013 (UTC)
    • Okay  Done Steven Walling (WMF) • talk 21:31, 22 June 2013 (UTC)

• I'm not sure the specifics of what this proposal is, but I'm interested. As one of the users involved in testing it, i also make an obligatory canvass for WP:Snuggle, which is an interface designed at providing easier looking into and interacting with promising newcomers and dealing with new-account vandals. TheOriginalSoni (talk) 19:08, 21 June 2013 (UTC)
• We could try confirming an e-mail address, like a lot of on-line sites do. That would do two things, cut down on the number of usernames, and give them a second chance to retrieve a lost password. Right now it is really a bit too easy for someone to register a hundred new usernames. Whatever we do, though, the real goal is to encourage more people to click edit. As to usernames with no edits, bear in mind that they can be usurped, but that is not an easy process. I would recommend against deleting accounts with no edits in a year, but none in five years might be okay. I see a lot of editors who seem to think about editing, and get as far as creating a username, and their first few edits are years apart. And if to keep an account all you had to do was make one edit, that is pretty easily gamed. Apteva (talk) 19:54, 24 June 2013 (UTC)
  • We already do ask that people confirm their email address. Steven Walling (WMF) • talk 21:44, 24 June 2013 (UTC)
    • But as far as I remember it is not necessary to confirm the email address to be able to edit but only recommended? As for cleaning up old accounts I'd propose to remove those that never did any edits and were not logged into for over a year. This way probably no harm is done. --Patrick87 (talk) 22:28, 24 June 2013 (UTC)
      • Right, confirming your email address is only required to get emails, not anything else. Regarding clearing out old accounts: we should discuss it, but right now we actually don't have an ability to "delete" or reset accounts as far as I know. Steven Walling (WMF) • talk 03:59, 25 June 2013 (UTC)
        • Hehe! Other than rename them to some random name "lskjafjahoiuhfjkn" ·addshore· 11:09, 25 June 2013 (UTC)
• If anyone cares, it took me 5 attempts before I was able to register a few days ago. It seem that everything was taken except for random strings, arbitrary numbers, or very long phrases. 20 million is far more than words in the dictionary, probably including all common names. This is exacerbated by the fact that the software considers a pretty wide range of names similar, so the number of actually prohibited user names is probably around 100 million to a billion. Someone not using his real name (talk) 13:50, 27 June 2013 (UTC)
  • One problem with recycled user-names is that a new user can be confused with the previous user. Having said that, it might make sense to derive a formula whereby a username is deleted after 1 + a + b years where a = time that the account was active and b = a function of the number of edits made by the person. We do of course have to look at the problems caused by sockpuppets - their names should never be recycled as they are tainted. Martinvl (talk) 14:35, 27 June 2013 (UTC)
    • On the other hand, since a majority of them "do absolutely nothing with their accounts", we could reclaim a large number of names simply by releasing the zero-edit/zero-action accounts after a year or two (or five, if you want to be conservative). An account that has never been used is not going to be an account that was used for socking. WhatamIdoing (talk) 15:21, 27 June 2013 (UTC)
    • We should not delete Accounts with edits (even if only few were made). I think by deleting accounts without edits we would already free a large enough amount of usernames, without the need for any controversial formulas or the problems of "recycled user-names" Martinvl mentioned. --Patrick87 (talk) 15:40, 27 June 2013 (UTC)
    • I agree with the "1 + a + b" formula, but I disagree with the "...sockpuppets - their names should never be recycled as they are tainted." Technical 13 (talk) 16:04, 27 June 2013 (UTC)

Add ability to delete usernames / inactive accounts

Could anyone on the WMF Team actually implement a username deletion system into the MediaWiki software? This is my take on the second part of this conversation (the amount of usernames taken), as for the first part (welcoming new users) as a guy who watches special:Log/newusers yes there are an overabundance of usernames being made per minute and only a few of them are blue in contributions after a few minutes when they drop off the list. I don't really have anything else to add to that part of the conversation :|

So yeah, I think a username deletion tool is the way to go. MM (Report findings) 13:42, 25 June 2013 (UTC)

How about mw:Extension:UserMerge? — HHHIPPO 16:52, 25 June 2013 (UTC)

So let me get this straight, since 2008 we have been able to delete all usernames by just merging them to Unused (talk · contribs)? Apteva (talk) 18:14, 25 June 2013 (UTC)

The extension is not installed here. And if it was, normal users would hardly have the right to use it. And one should probably not merge to what seems to be a real user. So to answer your question: no. — HHHIPPO 19:00, 25 June 2013 (UTC)

Right. Well I would support activating the feature, with appropriate restrictions on how it was used. I chose that name, though any similar one could be used, and that name could be renamed to free it up. The assumption was that only usernames with no edits would be deleted, and thus would never add to the three edits made in 2006 by "Unused". All three of those edits were immediately reverted. Apteva (talk) 19:44, 25 June 2013 (UTC)

Remember that bureaucrats are soon to be losing the right to rename users (it's all going to be done on Meta, apparently by stewards), since WMF want to expand our unified login thing. If we were to install this extension, I expect that it would be usable only by stewards as well. Nyttend (talk) 21:11, 25 June 2013 (UTC)

Well, since soon only SUL will be available I think we need a solution that works globally anyway. At the same time I think the changes around SUL are a perfect occasion to also think about some cleanup strategies. When everything is unified there will be even more unusable (and probably unused) usernames needlessly blocked for new editors. --Patrick87 (talk) 21:32, 25 June 2013 (UTC)

m:Bureaucrats do renaming, and I would expect they would be deleting accounts as well, although to delete a million accounts will require a bot. For non SUL accounts there is the sticky issue of requiring a local bureaucrat to do the renaming/deleting, which though, might just be overlooked. I would suggest pursuing this topic at m:Wikimedia Forum or m:Requests for comment. Apteva (talk) 00:54, 26 June 2013 (UTC)

There will be no non SUL accounts after m:SUL finalisation. After that, m:Stewards (and possibly their delegates) will handle global renaming requests. There will be no more local renaming by bureaucrats on public WMF wikis. πr (t • c) 02:33, 3 July 2013 (UTC)

Generic images

We currently have tons of generic images, such as File:Map.jpg, File:Image.jpg, and File:Photo.jpg. They're all the same image (purely a little text, "Please don't upload files with this title. Use a more precise name."), and they're all protected to prevent people from uploading other images on top of them, which is good. However, having lots of them clogs up the list of identical images. What if we chose one as the "official" name and redirected all of the others to it? This is basically what they do at Commons; File:Name.jpg is the "official" name, and as you can see at http://commons.wikimedia.org/search/?title=Special:WhatLinksHere/File:Name.jpg&hidelinks=1, most or all of the other generic image names are redirected to it. Of course I'm not suggesting that we unprotect anything or change the way we decide what to regard as generic; this is simply a housekeeping proposal. Nyttend (talk) 03:33, 19 June 2013 (UTC)

Seems reasonable, though I'm unaware of any other reason not to do it. --MASEM (t) 03:55, 19 June 2013 (UTC)

Sure. I don't see a problem. Jguy _Talk 21:29, 19 June 2013 (UTC)

Unlike Commons, however, we should protect those files that have redirects. It seems that commons does not do this for every file. :P Case in point: http://commons.wikimedia.org/search/?title=File:Photo003.jpg&action=edit Jguy _Talk 21:32, 19 June 2013 (UTC)

They have no need to do it — the point of the protection is simply to prevent uploads, and at Commons I don't believe that it's possible to upload on top of redirects. It's definitely not possible with that image: I tried to upload a one-pixel image (complete with a speedy-deletion tag) at File:Photo003.jpg and got a big warning message from Commons:Titleblacklist-custom-filename. No real need to protect what's already been uploaded, since nothing can be uploaded on top of it. Nyttend (talk) 04:53, 20 June 2013 (UTC)

• Support There are no added benefits and multiple drawbacks to the current practices as compared to your proposal. Nyttend, what you propose is exactly how things should be. Blue Rasberry (talk) 05:46, 21 June 2013 (UTC)
• Support See Blue Rasberry above. smileguy91 03:33, 22 June 2013 (UTC)

Support It reduces how much unneccessary text Misplaced Pages holds. It's only a speck of it granted but it is a part of it and even a part of it can make a difference. MM (Report findings) 13:19, 25 June 2013 (UTC)

Comment If this goes through and consensus is reached (I don't see a reason why it wouldn't), we should construct a list of what needs to be redirected. I'd be glad to help with adding redirects to those files in accordance with your proposal. Jguy _Talk

You can't do the actual redirect adding — MediaWiki's page-protection setup makes it impossible to prevent uploads without preventing editing, so these files are unredirectable except by admins. List-constructing help would be appreciated, of course. Nyttend (talk) 21:09, 26 June 2013 (UTC)

Aw, sad day. I'd be happy to help with lists, though :). Jguy _Talk 21:26, 28 June 2013 (UTC)

Proposal to add a template to medical article talk page

WikiProject Medicine has discussed and reached consensus on a plan to add a template, {{Reliable sources for medical articles}} near the top of the talk pages of many medicine related articles. Discussion here.

The template provides links to search results to help editors find reliable sources. User:Anomie has agreed to add this template to about 12000 article talk pages via his bot, but we would first like to get broader community input.

Some precedents for this kind of template are:

1. User talk:VIAFbot - This bot went to biographies and if WorldCat had an authority control identifier for the subject of the article, then it put a template linking the article to their library listing
2. Misplaced Pages:GLAM/smarthistory - a project to apply templates which link out to Khan Academy videos on art and culture
3. Template:Library resources box - John Mark Ockerbloom's proposal to add a link to all Misplaced Pages articles which could connect any user to resources in their local library

Comments? Klortho (talk) 02:34, 21 June 2013‎ (UTC)

• Support, same as I did when the idea was floated at WT:MED. Zad68 02:45, 21 June 2013 (UTC)
• Support, given the importance of WP:MEDRS, this seems similar to {{BLP}} to me, and should be equally prominent. Chris857 (talk) 03:03, 21 June 2013 (UTC)
• Support These are great links to high quality sources. Should help fellow editors improve Misplaced Pages. Doc James (talk · contribs · email) (if I write on your page reply on mine) 03:08, 21 June 2013 (UTC)
• Support per WP:NOTBURO, WP:BOLD, etc. --Jayron32 03:10, 21 June 2013 (UTC)
• Support I am from WikiProject Medicine and while I do not believe that standardized infoboxes would work for most fields, in medicine there are a small number of repositories which contain copies of the majority of published articles. Linking to these sources on the talk page does not directly modify Misplaced Pages articles themselves, but will give talk page visitors the option to automatically perform searches based on an article's title in document repositories. Guidance for users to find the research in those repositories is critical the development of articles and these repositories are irreplaceable as catalogs of the best available publications. Blue Rasberry (talk) 05:41, 21 June 2013 (UTC)
• Support Opens the door for more improvement in articles! smileguy91 03:38, 22 June 2013 (UTC)
• Comment Pointing people to good sources is a good thing. However, WP:MEDRS is an overbearing policy used to exclude interesting research and ideas from articles, and anything that helps it therefore does a lot of harm. I am also quite skeptical of the "review article" filter in NCBI - my feeling is that it points you to a lot of obscure little commercialistic journals with odd POVs that are not accessible in your university library, while typically missing the "good stuff". It would be better to find or build a NCBI results filter that points people to the big guns (everything from Nature to PLOS), though selecting them is quite subjective. Wnt (talk) 18:12, 22 June 2013 (UTC)
• Support. This template won't be a panacea. No combination of policies, guidelines, templates, and search filters can substitute for cautious, contemplative, informed editorial judgement, nor supplant the role of competent subject-matter experts in building some of our most technical content. Nevertheless, this looks like it provides some useful tools for our content builders, and equally importantly offers a constructive reminder of how we should approach writing medical articles. Well done. TenOfAllTrades(talk) 02:23, 23 June 2013 (UTC)
• Support the general idea, but the template shouldn't use click here links. Unfortunately I can't think of an elegant solution to this problem at the moment. Graham87 12:53, 26 June 2013 (UTC)
• Support. Could help. Can't hurt. --LukeSurl 00:43, 28 June 2013 (UTC)

RFR "reclaiming rights from old account" problem:

Hello all, I have noticed that many users go into RFR claiming that they are requesting rights for a new account either because their account was vanished (WP:VANISH) or they could not retrieve the password for that account, like this case: I suggest adding a new rule on the top of every "add request" page, like in the box on the top (e.g. "If you are requesting rights for an account that has been vanished by an administrator or one that you have forgotten the password to, it will most likely not be entertained" or alternatively "...will not be entertained"), because these requests are denied 99% of the time because of lack of concrete evidence that the requesting user is in fact the user that they say they were. smileguy91 03:30, 22 June 2013 (UTC)

If your account was vanished you have already agreed you will never edit Misplaced Pages again under any identity, so they are breaking that agreement, which they would already be aware of, by even making such a request. If they are claiming WP:CLEANSTART it's the same deal, it's not a clean start if you want permissions based on who you used to be. The present instructions already indicate that you must make an edit with both accounts if you are requesting rights for an alternate, so that pretty much covers all those cases. Beeblebrox (talk) 20:11, 24 June 2013 (UTC)

I was simply proposing a "do not attempt" notice. :) smileguy91 22:53, 1 July 2013 (UTC)

Yet I do understand policy. I'm relatively experienced at NAO ((Non-administrator comment)) on RFR, and some users come in claiming they have 15000+ edits. If you have 15000+ edits, you should understand policy quite well already, but it's impossible to tell (well, nearly) who's telling the truth and who's not. smileguy91 22:55, 1 July 2013 (UTC)

Mass removal of old indefinite rangeblocks

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Misplaced Pages proposals Misplaced Pages policies and guidelines When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Currently, there are about 200 indefinite rangeblocks on various IPs, most of which are non-required now. A previous proposal on this Village Pump, which sought to remove these old rangeblocks under controlled conditions passed successfully. This proposal is to finalize all the various details on that proposal, and to carry forward with it. TheOriginalSoni (talk) 06:37, 25 June 2013 (UTC)

Links -

• The first (failed) discussion on restricting RangeBlocks to CheckUsers which led to the current proposal
• The passes proposal at the VP, which was an RfC and also advertised at CENT

The general agreement in the previous discussion was -

1. All rangeblocks beyond a certain time period will be reviewed.
2. The rangeblock is reverted unless there is strong reasons not to.
3. All reverted rangeblocks are placed in a special category for monitoring
4. After sufficient time of activity,
   • If the IPs are good faith, they are removed from the monitored list
   • If they continue with their vandal behaviour, they can be reblocked as the blocking admins see fit. If they get indefinite rangeblocked again, the rangeblock could again be reviewed after the time period in Step 1.

If there is any confusion or disagreement regarding the above "general agreement" steps, please start a new discussion section below on the same so that we can discuss them, and other possible alternatives. TheOriginalSoni (talk) 06:37, 25 June 2013 (UTC)

Discussion

The sections below are for finalising and having discussion on the other ambiguous details that have been left out in the original discussion. Please feel free to add more sections, or more options to the ones already given, or to support, or have discussion on any of the options already mentioned. TheOriginalSoni (talk) 06:37, 25 June 2013 (UTC)

• In my opinion, indefinite rangeblocks should simply be prohibited entirely. Even for the most abusive sockpuppeteers or the widest open proxies, chances are, the IP's been reassigned. I would support a 2 year max for most cases, and a strict 5 year max in the most extreme cases. -- King of ♥ ♦ ♣ ♠ 00:57, 26 June 2013 (UTC)
  • I agree that indefs shouldn't be used. I've never blocked any IP more than a year myself. Dennis Brown | 2¢ | © | WER 01:00, 26 June 2013 (UTC)

Here is the list of all indefinite IP rangeblocks. With the exception of the Toolserver soft blocks, all will need to be reviewed. A couple of them seem to have been requested by the administrators of the IP ranges in question - perhaps we need a better process for documenting such requests in greater detail. — This, that and the other (talk) 07:28, 29 June 2013 (UTC)

Time period before review

How much time should it be before the previous rangeblock is reviewed?

1. 3 months
2. 6 months
3. 9 months
4. 1 year
5. 2 years

• 6-12 months - If the range is rotten it won't take long for problems to show up. In a /16-/18 or so i seem to recall seeing proxies popping up at about 6 month intervals. Sailsbystars (talk) 09:31, 25 June 2013 (UTC)

Wait, is this rangeblocks in general (I was originally thinking this was just the old indefs which should be lifted and then reviewed after 6-12 months)? If so, I would distinguish strongly between hosting and ISP blocks. ISP blocks should rarely longer than a few months before they should be reviewed. If we're talking hosting providers, a year or two for review after a first block, five years for repeat offenders. Rotten hosts tend to stay rotten hosts, and the useful to useless ratio for those ranges tends to be exceptionally unfavorable with very little activity. Sailsbystars (talk) 13:31, 25 June 2013 (UTC)

• 6 Months if it's their first review. 1 Year afterwards. MM (Report findings) 12:58, 25 June 2013 (UTC)
• 3 months on first review. 6 months on second review and yearly after that. NinjaRobotPirate (talk) 13:35, 25 June 2013 (UTC)
• Basically I do not think we should be creating a list of 200 mostly unneeded range blocks, but I am not sure how a rangeblock can be reviewed without releasing it and seeing if any edits ensue. I would personally prefer an emphasis on helping rogue editors learn how to contribute positively instead of just blocking the IPs used, but I would opt for a standard 3 month review of all range blocks, so that unneeded ones did not accumulate. Apteva (talk) 18:45, 25 June 2013 (UTC)
• Both ninjapirate and apteva are in the ballpark, I'm going to say 3 months on the first review and six months thereafter, with broad discretion given to whoever does the unblocking.Tazerdadog (talk) 19:50, 25 June 2013 (UTC)
• 12-18 months Sure, some will be free before then, but all should be reassigned within 12-18 months... Very few should "still" be an issue. I'd rather see less frequent and more thorough passes. Technical 13 (talk) 22:33, 25 June 2013 (UTC)

  Why do you believe that all IPs are reassigned within 12–18 months? I know of some that haven't been reassigned for 18 years. WhatamIdoing (talk) 07:14, 26 June 2013 (UTC)

• 1 year or so before any mandatory review is required. This is not at all to say the current review process/procedures are affected by this either. This is just an additional review that should have no bearing, implied or otherwise, on current rangeblock procedure. Shadowjams (talk) 22:59, 25 June 2013 (UTC)
• 1 year, since a 1-year block on a highly abusive IP range is standard. -- King of ♥ ♦ ♣ ♠ 00:51, 26 June 2013 (UTC)
• 1 year, per King of hearts above. Kudpung กุดผึ้ง (talk) 05:47, 26 June 2013 (UTC)
• 1 year, also per King of Hearts ·addshore· 09:42, 26 June 2013 (UTC)
• 1 year was my favoured time period too. Sounds best. TheOriginalSoni (talk) 12:09, 4 July 2013 (UTC)

Who participate in the reviews

Which group of users will participate in the reviews before the old rangeblock is lifted?

1. Bureaucrats only
2. A specialised elected/selected group of trusted editors (may be chosen along with one of the other options)
3. Administrators only
4. Administrators + Rollbackers
5. Administrators + Reviewers
6. Autoconfirmed
7. Everyone
8. One of the other categories + a group of trusted users

• Specialised/ selected groups - Checking the range involves proxy-checking skills, which some users have and some admins have. That's the main source of rotten ranges requiring long term rangeblocks Or I could run for admin, since I'm not aware of any other specialised non-admin users. Sailsbystars (talk) 09:31, 25 June 2013 (UTC)
• Specialised Group: Namely I say we give ArbCom a bit more to do. The Arbs are bound to have a CU on the team if it's needed or they can just ping one. I mean a CU is hardly going to refuse to help our top line of nitwits editors now are they? MM (Report findings) 13:00, 25 June 2013 (UTC)
• Specialized group. I'm not too concerned with this detail. Elected/selected volunteers, arbcom, or admins. I'm switching to Everyone. We could also put up regular, recurring RfCs and invite comments by Autoconfirmed users. Could be fun. NinjaRobotPirate (talk) 13:39, 25 June 2013 (UTC) (update: 13:28, 26 June 2013 (UTC))
• Everyone. The person reviewing the IP should be the person responsible for monitoring that IP. If you can take responsibility for the monitoring, you should have the authority to decide the review (within reason and policy)Tazerdadog (talk) 19:53, 25 June 2013 (UTC)
• Specialised/selected group of trusted users that should be given a smaller package of the admin tools. Rights that should be included are the ability to (un)block (single|range), check-user, override title blacklist, noratelimit, at least to start. These are the minimum tools needed to complete these tasks, and if the users are trusted/elected, it shouldn't be an issue. Technical 13 (talk) 22:42, 25 June 2013 (UTC)
• Everyone, but of course more weight should be given to the opinions of checkusers and skilled proxy checkers. -- King of ♥ ♦ ♣ ♠ 00:52, 26 June 2013 (UTC)

This is an eminently reasonable option as well. Sailsbystars (talk) 09:57, 26 June 2013 (UTC)

Yeah, this seems like a good solution. NinjaRobotPirate (talk) 13:23, 26 June 2013 (UTC)

• Everyone of course. Seems like a nobrainer. I can't believe there's even a suggestion that an appeal process like this would exclude outside input wholesale. Shadowjams (talk) 05:27, 26 June 2013 (UTC)
• Everyone , because reviews will be decided on the weight of the arguments and not on a tally of the !votes. Kudpung กุดผึ้ง (talk) 06:07, 26 June 2013 (UTC)
• Checkusers, because checkusers are the only people that can actually monitor the behaviour of an IP range. All the rest of us can judge is the quality of the anonymous edits inside the range.—Kww(talk) 23:37, 29 June 2013 (UTC)

Who monitors the activity

Which group of users will monitor the activity after the old rangeblock is lifted?

1. Administrators only
2. Administrators + Rollbackers
3. Administrators + Reviewers
4. Autoconfirmed
5. Everyone
6. One of the other categories + a group of trusted users

• Everyone - Problems can be reported to WP:AIV, WP:ANI and/or WP:OP like any normal disruption. The same group involved in reviewing the blocks above can then look for complaints that resulted from monitored ranges. Sailsbystars (talk) 09:31, 25 June 2013 (UTC)
• Everyone: Same process as with any old IP. If they're acting up then drop em off at AIV. MM (Report findings) 13:02, 25 June 2013 (UTC)
• Everyone. Agree with previous users. NinjaRobotPirate (talk) 13:40, 25 June 2013 (UTC)
• Everyone should pitch in, but the responsibility ultimately lies with the reviewers of the specific range unblock here.
  Just a point to mention. I am working under the assumption that we will be monitoring the activity of the recently unblocked users at a particular location so we can keep an eye out for the ones who might be going back to bad faith edits If not monitoring them (specially) is what others have in mind, we can clarify that with a discussion. TheOriginalSoni (talk) 22:14, 25 June 2013 (UTC)
• Everyone - Problems can be reported to WP:AIV, WP:ANI and/or WP:OP like any normal disruption. The same group involved in reviewing the blocks above can then look for complaints that resulted from monitored ranges. Technical 13 (talk) 22:43, 25 June 2013 (UTC)
• Everyone - the more eyes the better. Kudpung กุดผึ้ง (talk) 06:25, 26 June 2013 (UTC)
• Everyone - admins will need to make the ultimate decision, but most of the monitering work can be done even by anons who regularly edit without creating an account. עוד מישהו Od Mishehu 21:44, 2 July 2013 (UTC)

How are the changes monitored?

How should the changes be monitored? Through a WikiProject, something similar to the pending changes (a special category), or a bot? Discuss below TheOriginalSoni (talk) 06:37, 25 June 2013 (UTC)

• Bot existing tools are a bit of a pain in the tuchus for checking this sort of thing, it would be nice to have a page listing contributions from these ranges. Sailsbystars (talk) 09:33, 25 June 2013 (UTC)
• Bot if someone can make such a bot then why not? All the rangeblocks that WP has to deal with would be painful for a group of people to handle. MM (Report findings) 13:07, 25 June 2013 (UTC)
• Bot. Makes sense to me. NinjaRobotPirate (talk) 13:41, 25 June 2013 (UTC)
• A Bot does indeed seem like the logical path to follow! ·addshore· 17:20, 25 June 2013 (UTC)
• Agree, a bot is the correct course. Tazerdadog (talk) 19:57, 25 June 2013 (UTC)
• Unsure I'm not convinced that using a bot for this is the appropriate course of action. Let me think about it some more and see if there may not be a better alternative. Technical 13 (talk) 22:44, 25 June 2013 (UTC)
• Bot - Seems like an easy answer. It should be mentioned that most of the load would be offline anyway. Simple monitoring of the block log would be enough. Shadowjams (talk) 05:19, 26 June 2013 (UTC)
• Bot sounds like a good idea. Kudpung กุดผึ้ง (talk) 06:26, 26 June 2013 (UTC)

Blacklist?

What should be done with the worst case rangeblocks? Should we have a blacklist for them, or give them a little WP:ROPE and reblock after bad-faith edits after every review?

• Some combination of the above. Blocks shouldn't be permanent (in case ranges change hands), but certain repeat offenders (e.g. theplanet hosting) should be named, shamed, and blocked at the slightest hint of trouble. Sailsbystars (talk) 09:31, 25 June 2013 (UTC)
• WP:ROPE as this rule states that you can give them so long before you hang them. If they still don't get the picture after a 2 year block on the situation then they're just not going to get it ever. MM (Report findings) 13:11, 25 June 2013 (UTC)
• 3/6/12 month review period, as above. Open to supporting longer periods, too. Permanent blacklists seem too punitive. IP blocks can and do change ownership. NinjaRobotPirate (talk) 13:44, 25 June 2013 (UTC)

NinjaRobotPirate but then there will be some proxy-offering websites, or permanent troubles who would better be handled with a blacklist. TheOriginalSoni (talk) 13:51, 25 June 2013 (UTC)

Repeat offenders can go on a separate list that has no probationary period. At that point, the only problem becomes workload. If reviewed yearly or biennially, workload should be manageable. I dislike the idea of a permanent block for an entire IP range. If we all get an IPv6 address tattooed to us at birth, this may change, but, for now, IP addresses are not people. NinjaRobotPirate (talk) 15:32, 25 June 2013 (UTC)

I don't think permablocks are the answer either, but for bad hosting providers, they seem fairly stable over periods much longer than 12 months. The amount of workload involved is quite extensive. A thorough and proper check of an IP range can easily take an hour. I don't know our total number of rangeblocks, but I'd guess it's in the thousands. For annual reviewing, it would be equivalent to one or more full-time real job. Sailsbystars (talk) 15:44, 25 June 2013 (UTC)

Sailsbystars, it is 200 indefinite ones. TheOriginalSoni (talk) 16:47, 25 June 2013 (UTC)

199 ;p ·addshore· 17:18, 25 June 2013 (UTC)

So Soni could you clarify if you mean for all of the subpoints of this proposal apply to all IPs, or just the ones that currently are under an indef block? If so, I agree that checking the 200 or so wouldn't be a huge problem. Sailsbystars (talk) 19:21, 25 June 2013 (UTC)

Yeah. That's my understanding. Some of them are easy. Voluntary blocks, commercial proxies, etc don't require much effort to validate. Professional spammers and determined vandals (GNAA/4chan) will be where most of our efforts go, I think. They may actively try to hide their nefarious intent. For something like The Anonymizer, you just make sure it's still running and at the specified IP range. NinjaRobotPirate (talk) 19:48, 25 June 2013 (UTC)

Just the indefinite ones. I thought it was clear from my header. Also, if there was no indef-block, the block would go away anyways. (Assuming no admins block for a very long period of time, in which case, we might have to check all blocks larger than our review period too) TheOriginalSoni (talk) 20:04, 25 June 2013 (UTC)

Well, yes, but the current practice has moved to 2-5 year rangeblocks for disruptive hosting ranges. Hence why I'm a little hesitant about some of the proposed remedies if they would make review more frequently. This practice seems to have been fairly successful, but it would be nice if it had endorsement from the broader community. Sailsbystars (talk) 21:08, 25 June 2013 (UTC)

• Blacklists should be extremely rare, and probably limited to stuff like outstanding legal threats, and maybe gross intentional violations on a BLP beyond petty vandalism. (e.g. Joe Shmoe is a rapist...) Tazerdadog (talk) 20:01, 25 June 2013 (UTC)
• ROPE them... Plain and simple... Technical 13 (talk) 22:44, 25 June 2013 (UTC)
• ROPE. Eventully, the guilty user(s) will be gone and it should then be unblocked. עוד מישהו Od Mishehu 21:42, 2 July 2013 (UTC)

Additional Proposal

Following Sailsbystars' concerns at the above section, I propose that After the expiration of the said review period for definite rangeblocks, they will be undergoing a the same (review) process that other indefinite rangeblocks have. So if the review time is decided to be 6 months, then ordinarily, all definite-blocks older than 6 months will also get reviewed under the same rationale as the indef blocks. TheOriginalSoni (talk) 22:20, 25 June 2013 (UTC)

• As proposer, Aye TheOriginalSoni (talk) 22:20, 25 June 2013 (UTC)
• Meh, I see this as more of an on-going process and not a circular thing. It's either going to be the same person on the other end of the IP or it's not... After 12-18 months, "most" IPs should have changed hands at least a few times. I don't see any reason not to assume good faith and let the IP start with a clean slate for each pass. Technical 13 (talk) 22:47, 25 June 2013 (UTC)
• Comment - I'm not thrilled about the idea of complicating this specific question with additional issues like this. The question of if a definite rangeblock of 3 years is worse than an indefinite one is unclear. My gut instinct is to leave it aside, although after some thought I think that erasing the distinction between indefinite (which always seems like a cop out to me) and definite but long, is a good thing. Shadowjams (talk) 05:25, 26 June 2013 (UTC)
• This seems eminently logical. I can't really see any reason why it wouldn't work like this, except for workload. Considering that, we might need to re-think the frequency of reviews. NinjaRobotPirate (talk) 17:50, 26 June 2013 (UTC)

Let ArbCom do it? XD MM (Report findings) 08:08, 28 June 2013 (UTC)

• Comment My concerns would be allayed if we distinguished between hosting IPs and ISP IPs. For the ISP IPs (or corporate filter webhosts or really, most IPs), I have no problems whatsoever with limiting those to 3-6 months. Web hosts, however, tend to be rather static, and have a.) much lower IP contribution rate than ISP IPs (I did a little experiment once and came up with a ratio of either 10 or 100x more edits from the ISP range) and b.) low helpful to harmful contribution ratio and c.) never NEED to be edited from. Based on experience, certain hosting ranges have earned 2-5 year blocks, and nothing of value was lost. An aside, I realize this is a bit of instruction creep and would be difficult to manage due to the fact that blocks can't be sorted by the block log notes (at least as far as I'm aware). Sailsbystars (talk) 21:11, 26 June 2013 (UTC)

I have no idea what these two are. Could you please explain in a simple way too? Thanks. TheOriginalSoni (talk) 21:37, 26 June 2013 (UTC)

Examples of an ISP IP would be ones from Comcast or Verizon in the USA, British Telecom in the UK, or Orange SA in France. Cell providers, government or uni IPs would fall under this category as well. Examples of hosting providers would be SoftLayer, Rackspace Hosting, or Go Daddy. Basically, under normal circumstances, all of us edit from an ISP of one sort or another. All of these involve a computer sitting on a desk somewhere connected to the internet. With hosting providers, the computers are all sitting in a data center somewhere with no human at them. Under normal circumstances, most edits from webhosts are from people trying to escape scrutiny or evade a block/ban as they involve an extra effort beyond what one normally uses to connect to the web(e.g. anonymizing services, proxies, some VPNs, on the rare occasion one own's server). Hope this helps? Sailsbystars (talk) 05:13, 27 June 2013 (UTC)

I Like This. I think we should. MM (Report findings) 08:08, 28 June 2013 (UTC)

• Final Note - If there are further topics of discussion, please add them as a section above this line.

Discussion about spacing between lists (refs/ELs) and navboxes

There seems to be a protracted, site-wide style war between editors who prefer more and those who prefer less vertical space above the first navbox. This mostly involved edit warring by manually adding and removing blank lines and similar devices. Luckily, it seems that a uniform technical solution exists for this issue. Unfortunately, participation in the discussion at WT:MOS has been rather low and took a turn for personalization recently. Perhaps people watching this page have an opinion on how much spacing looks good? If so, please contribute at WT:MOS, for the sake of keeping the discussion in one place. Thanks, Someone not using his real name (talk) 13:44, 27 June 2013 (UTC)

Don't remember ever running into this kind of thing. Could you provide a diff so I can understand better? Nyttend (talk) 17:16, 27 June 2013 (UTC)

Perhaps I'm missing something but this issue seems to be of no importance. Praemonitus (talk) 00:57, 29 June 2013 (UTC)

Talk page archival with automatic redirects to former discussions

Can the system be made to automatically create a redirect when a talk page discussion is archived? Such a feature would make talk page wikilinks always work, rather than having them break upon archival. For instance, Talk:Tree#Help might be placed on someone's talk page or in an edit summary, but when it is archived, the wikilink breaks to become something new: Talk:Tree/Archive 1#Help. I propose having a redirect automatically written to bring the reader to the archived discussion when they click on Talk:Tree#Help.

To make this work, identically named threads must be differentiated in some way, perhaps by time stamp. Binksternet (talk) 02:15, 1 July 2013 (UTC)

ClueBot III does this automatically. Graham87 02:33, 1 July 2013 (UTC)

That's one of a few hundred things that WP:Flow will solve completely. We'll have to wait until that's written and released, though.

Otherwise/currently, Cluebot III is our only hope. (Afaik Cluebot III and the 3 Miszabots are the only functioning archivebots?) –Quiddity (talk) 03:09, 1 July 2013 (UTC)

I looked at the contribution history of Cluebot III and I could not find it doing any redirects. How does it work? Looking forward to Flow... Binksternet (talk) 05:22, 1 July 2013 (UTC)

One example of cluebot III fixing a link.

I'm not sure what its parameters/methods are though - does it check every page on "What links here", or something? Possibly need to ask at its talkpage. –Quiddity (talk) 05:46, 1 July 2013 (UTC)

With regard to Article editing interface

At the very least, I move that we should always keep good old fashioned source editing available alongside the new what-you-see-is-what-you-get mode. This may be counterintuitive, but it is actually easier to edit Infoboxes and other tables in source. That seems like reason enough to me. :-) The Mysterious El Willstro (talk) 14:10, 2 July 2013 (UTC)

We hope that it will not always be easier to edit templates and tables in the source, but at this point, VisualEditor still needs some features added or expanded. I can assure you that there are no plans to turn off wikitext source editing. (Who knows what will happen years from now, of course, but no current plans at all to remove the old editor.) Whatamidoing (WMF) (talk) 16:05, 2 July 2013 (UTC)

It is effectively removed for many editors, because the "edit source" link on sections is HIDDEN. --Timeshifter (talk) 20:44, 2 July 2013 (UTC)

Hi Timeshifter, I know you don't like the section edit links. Last I checked (which was a couple of days ago), I believe that only you and one other user had complained about them, and many editors had praised the design. If you believe that most editors are unhappy about that particular detail, you might brainstorm some alternatives and request that the most popular be considered as a replacement. Whatamidoing (WMF) (talk) 08:29, 3 July 2013 (UTC)

It is funny to see you get stuck with one reply in spite of the barrage of new comments agreeing with me at Misplaced Pages:VisualEditor/Feedback, and in spite of my previous direct replies to you days before pointing out others agreeing with me. --Timeshifter (talk) 08:48, 3 July 2013 (UTC)

I totally agree with Timeshifter. This is one of the issues that bug me most with VisualEditor and will be a reason to deactivate it for me (I'll might keep VE activated in parallel if it really seamlessly melds into the UI but not as long as it hides the button I'm probably using most on Misplaced Pages).

You want an example? Here it is! Simple as hell, without the need for any hovering effects.

And for the bug itself: There's even a bug for it, see bugzilla:50540. --Patrick87 (talk) 09:40, 3 July 2013 (UTC)

//Who knows what will happen years from now, of course//

Exactly, who knows what will happen years from now if anything could happen in principle. That's why I'd rather see a keep-source-editing policy set in stone now instead of leaving the future to chance and whim. The Mysterious El Willstro (talk) 13:05, 4 July 2013 (UTC)

How many years are you looking at? Do you want "keep the 2002 source editing system" to be true next century, regardless of how computing has changed during that time? The Wikimedia Foundation is hopeful that Misplaced Pages will still exist then. Whatamidoing (WMF) (talk) 14:28, 4 July 2013 (UTC)

(unindent). It only took a few days for my prediction to be proven right concerning the hidden "edit source" links on sections. It has already been reverted due to the barrage of complaints about it. The only link now on article sections is an "edit" link that goes to the wikitext source editor for that section. It would be nice if there were a preference on the edit tab of preferences for having both links ("edit" and "edit source") on sections. 2 simple direct links without hover effects. --Timeshifter (talk) 01:38, 5 July 2013 (UTC)

I'm sorry to be the one to tell you, but: according to the e-mail messages I received today, the sudden disappearance of the section edit links for VisualEditor was an unintentional bug that will be fixed on Monday. They'd fix it now, but they are trying not to make changes just before the weekend. Whatamidoing (WMF) (talk) 03:37, 5 July 2013 (UTC)

User Council

I've been irked into proposing this by issues around the introduction of the Visual Editor. However, the issue itself is age old. I feel that there is an disconnect between the Foundation and users of Misplaced Pages when it comes to rolling out software changes.

When I say "users" here, I mean users in the software sense (i.e. end users) and not in the way we often mean it here (as a synonym for "editor"). And when I say "Misplaced Pages", I mean the software hosted on this website (not the encyclopaedia or its content).

I can appreciate the desires and challenges the Foundation faces (as a software developer I face them too). In industry, a common way to resolve problems like this is by involving users formally in the process of developing and rolling out new software. One technique is to establish "user councils" that represent the end users of a product.

I propose we establish a user council for the English-language Misplaced Pages. I'm going to keep the details of this proposal very high-level so as to first gauge consensus around the basic idea.

The council, I believe, should:

• Be independent of the Foundation
• Be elected for a fixed term from Misplaced Pages users
• Have both rights and responsibilities

Rights may include:

• To be kept informed about Foundation road-maps and plans for software roll outs
• To have sign-off on software changes affecting end users before they are rolled out

Responsibilities may include:

• To ensure Misplaced Pages users are adequately informed about up-coming software
• To provide a forum for user feedback and represent user feedback to the Foundation

--RA (talk) 20:19, 2 July 2013 (UTC)

This might actually be useful. At present there are people claiming that years and months and weeks and days of talking about it, weeks of watchlist/recent changes notices and a banner on literally every logged-in page in article space constitutes not informing people; it might be useful to have one point of contact who telling officially constitutes notice - David Gerard (talk) 20:38, 2 July 2013 (UTC)

Thanks for writing a clear and succinct proposal RA. Regarding, "To be kept informed about Foundation road-maps and plans for software roll outs"... the Foundation's roadmap and planning are already public. The trouble is trying to keep the correct subset of 80,000+ active editors informed about what's in them to avoid surprise and anger. We've kicked around the idea of a special advisory body of users regarding product/engineering work at the WMF as well. However, honestly after seeing how hard Philippe, Oliver, Maggie, and others employed to "ensure Misplaced Pages users are adequately informed about up-coming software" work, I don't think it's fair to put that job in the lap of volunteers. Immediately pre and post deployment of a new feature, the effort to keep the community updated and respond to feedback is not only a full time job, it's a grueling and often stressful one. Also, to be frank I doubt users surprised by a change will accept the response of "Well, we didn't tell you, but we told this tiny select group of users. It was their job to let you know, so go yell at them." When the WMF makes changes to the software, the responsibility ultimately rests with us to keep people informed. Steven Walling (WMF) • talk 20:40, 2 July 2013 (UTC)

I do not envision a user council as a vehicle for the Foundation to shirk its own responsibilities. The Foundation has a responsibility to ensure users are properly and adequately informed about up-coming changes IMO. A responsibility of a user council would include making sure (ensuring) the Foundation lives up to that responsibility. --RA (talk) 20:46, 2 July 2013 (UTC)

Is this an achievable goal, though? Note my example above, which is not in fact exaggerated in any degree whatsoever - that's literally what's happened. What would constitute reasonably informing people, to your mind? - David Gerard (talk) 21:10, 2 July 2013 (UTC)

Example: I currently (finally?) have notice of the roll-out of the Visual Editor in my watchlist notices. I also have notice of a meet-up in the UK. The roll-out notice is in a small font and the UK meet-up is advertised is in a large font. Needless to say, the roll out of major changes the editor is much more important to the vast majority of editors compared to a meet up they are not going to attend.

The WMF guys have a lot on their plate and it's easy to make simply mistakes like this. A user council is focused and one of their roles can be to remind the WMF guys not to make mistakes like that at another roll out. --RA (talk) 21:24, 2 July 2013 (UTC)

There were at least three separate watchlist notices: 07 June, 17 June, 02 July. The two most common explanations for failing to see notices that were deployed to everyone are user error (e.g., failing to pay attention) and software bugs (e.g., some interaction between your browser's settings and Mediawiki's software). BTW, that's just watchlist notices. That doesn't include the CentralNotices, messages to dozens of high-traffic discussion pages, or other announcements that were made. Whatamidoing (WMF) (talk) 08:40, 3 July 2013 (UTC)

Notices are good, but notices are not discussion on English Misplaced Pages. There has been very little alpha or beta discussion on English Misplaced Pages until recently. All of a sudden there is substantive discussion on English Misplaced Pages about the visual editor. It is too little too late. There are many serious design flaws that could have been avoided if earlier substantive discussion had occurred on English Misplaced Pages, or if an experienced, elected, accountable user council had been involved early on. A user council that reported back often to English Misplaced Pages. --Timeshifter (talk) 11:03, 3 July 2013 (UTC)

... and to ensure there are "How to turn it off"-options. --Bensin (talk) 21:27, 2 July 2013 (UTC)

You mean, like the one that's still there from before? - David Gerard (talk) 21:37, 2 July 2013 (UTC)

It was recently moved out of the logical location of the edit tab in preferences, and buried in the gadgets tab. --Timeshifter (talk) 21:45, 2 July 2013 (UTC)

I mean, like the one that's not there at all... (But should be per Misplaced Pages:VE). Also, a User Council is not only necessary for the VE-case. There was a very aggressive roll-out of the article feedback tool which certainly did not had consensus the first time. --Bensin (talk) 21:54, 2 July 2013 (UTC)

No, I think I can reasonably state that if the barrage of notices about the impending VE were not adequate, then nothing would be adequate. You cannot, in fact, demand an arbitrary magical flying unicornetto pony - David Gerard (talk) 21:37, 2 July 2013 (UTC)

Not a "an arbitrary magical flying unicornetto pony". A pretty straight-forward industry technique for resolving the kinds of issues raised. Including the ones you have. --RA (talk) 22:15, 2 July 2013 (UTC)

RA, thanks for thinking about this issue. Regarding the item "To be kept informed about Foundation road-maps and plans for software roll outs": people like you might like to subscribe to talk-page delivery to receive the weekly Tech News summary on your talk page on English Misplaced Pages. Monitoring and understanding all the technical activity happening across the Wikimedia movement is definitely a difficult and time-consuming task. By subscribing to Tech News, you can help monitor recent software changes likely to impact Wikimedians, and receive a weekly summary on your talk page, without technical jargon. And if some Wikipedians would like to have more resources for informing other onwiki users and helping technical folks get user feedback, it would be great if they'd check out the Tech ambassadors resources; the Tech ambassadors are technically-minded volunteers who help other Wikimedians with technical issues, and act as a bridge between developers and local Wikimedia wikis. I know this does not address the whole of your proposal, but I thought I would mention it for those who are interested. Thanks. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 22:20, 2 July 2013 (UTC)

Tech News is great. I get it on my talk page. --Timeshifter (talk) 10:55, 3 July 2013 (UTC)

• Support. Long overdue. See my user page for more info. --Timeshifter (talk) 20:42, 2 July 2013 (UTC)
• Support. We should definitely have a say on what software is rolled out to us, because after all, we are the ones that will be using it. Insulam Simia (/_contribs) 20:48, 2 July 2013 (UTC)
• Support Great idea. Mlpearc (powwow) 21:03, 2 July 2013 (UTC)
• Oppose. We've had this discussion before in various forms over the years now, and I think it boils down to a single thing: people want to have input without participating. MediaWiki, deployed extensions, and nearly every aspect of WMF development is carried out in public on mailing lists, Bugzilla, Gerrit, MediaWiki.org/Wikitech, any of which people are more than welcome to participate in. Problem is: nobody wants to participate. If enwiki wants to come up with a group of users who do want to contribute with developers and report back to the community, that's perfectly fine (and I've always encouraged people who *are* interested to jump in). However, I adamantly oppose a self-appointed council on enwiki having effective veto power over software changes that affect people other than enwiki--that's simply not how we develop MediaWiki, nor has it ever been. ^demon 21:10, 2 July 2013 (UTC)

  Not self appointed. They should be elected IMO. And only EN-wiki. --RA (talk) 21:15, 2 July 2013 (UTC)

  Point taken. But my main point remains the same: we develop software using consensus as well, it's just not done via an elected committee. Software changes are proposed in Bugzilla or Gerrit where they are debated/revised and (if they're good) merged. And "affecting end users" is far too vague...nearly everything effects end users to some degree or another. ^demon 21:31, 2 July 2013 (UTC)

  I appreciate that. But, I'm not talking about MediaWiki. That is a separate project(s). I'm only taking about deployments to the live EN-Misplaced Pages environment.

  But take bugzilla (and similarly, wikitech-l) as an example: must users couldn't understand what's discussed in tickets. A user council represents users in "user terms", not "developer terms". And it represents the "receiver" of a product, not the "producer" of it. That can involve liaising with developers but it doesn't take away anyone's job or duplicate it. --RA (talk) 21:56, 2 July 2013 (UTC)

  But aren't the two inherently intertwined? We deploy new versions of MediaWiki on a rolling weekly basis--for which there are detailed release notes. Having a committee to review those changes and approve them prior to deployment either A) makes us slow down deployments (something we've been trying to get better at) or B) makes deployments a mess (having to back out changes that aren't "approved"). Again, I'm all for having a group of people who liaison with developers, but the proposal as it stands doesn't jive with how we develop MediaWiki or consequently deploy it. The proper time for discussion is when changes are being proposed or written, not before they're deployed. I appreciate that most people aren't able to understand technical discussions--but isn't that the point of this committee? ^demon 22:28, 2 July 2013 (UTC)

  This is the kind of detail I wanted to avoid (I'd preferred to have left it for later) - but it is important. I presume you're talking about day-to-day patches, updates, etc. not roll-outs of major new user-facing functionality, changes, plugins, etc.. I'm not going to say that a user council wouldn't be interested in those but I don't think it's in anyone's interest to have a committee rubber stamp those kinds of things. There are some things where developers know best and it's not in the users interest to go sticking their heads into it. But it's informative to know about them and have them explained to you in terms you understand.

  I agree that "the proper time for discussion is when changes are being proposed or written, not before they're deployed." And that's when a user council should liase (and translate "developer talk" to "user talk") so that when software gets delivered everyone knows what to expect.

  TBH that kind of thing doesn't need a formal council and should happen anyway. (I'd be willing to put some effort in around that, if you'd assist.) A formal council (with "rights") would only be needed when things go bad. --RA (talk) 23:11, 2 July 2013 (UTC)

demon, you wrote: "The proper time for discussion is when changes are being proposed or written, not before they're deployed." Discussion needs to occur at all stages. It is unrealistic to expect this continuous discussion to occur between developers and users when the discussion occurs mainly on smaller wikis. This is due to the lack of cross-wiki watchlists. Developers hang out on their wikis and mailing lists and Gerrit, Bugzilla, etc.. Users hang out on their main Wikipedias. Few developers make much effort to maintain longterm discussion on software issues on English Misplaced Pages. Users may try to go to the developer wikis but then soon tire of looking at multiple watchlists waiting for an eventual answer, and give and take. An elected user council puts an accountable group between users and developers. Its advice does not have to be binding to be very useful to all. --Timeshifter (talk) 08:42, 3 July 2013 (UTC)

• • +1 - do any of the people here e.g. bother following wikitech-l? I do - David Gerard (talk) 21:15, 2 July 2013 (UTC)
• Oppose - I honestly feel this is a solution in search of a problem. In my opinion, the Philippe, Maggie, Oliver, the E3 team and the rest of the Foundation is doing a fine job of informing and involving the community in software and strategy changes. Short of spamming every single users talk page with a notice on every change, I don't think there really is anything else they can do to ensure everyone is notified, and I don't see what creating another body will do that is not already being done. Steven Zhang 21:13, 2 July 2013 (UTC)
  • Apparently it's intended as a vehicle to make staffers' jobs more painful: "The Foundation has a responsibility to ensure users are properly and adequately informed about up-coming changes IMO. A responsibility of a user council would include making sure (ensuring) the Foundation lives up to that responsibility." Note nothing there about what would actually be sufficient (apparently, banners on every logged in page aren't) nor about said concerned users getting off their backsides to find anything out themselves. RA, what do you do to keep yourself informed? - David Gerard (talk) 21:18, 2 July 2013 (UTC)
• Comment. Do we really need this if WMF starts communicating all details of a new software? In the latest example we had the chance to look at the VisualEditor for weeks and it was OK. Nobody told us that the option to turn VE on/off would be gone with the "final" release, though. Although all at WMF did a good job to communicate with us, the just missed a key fact. That should (must) be avoided in future!

Additionally I think there should be a better channel from the users back to the developers at WMF. If I'm informed about a change I don't like but have no ability to communicate this back (or am only getting reassured that "everything will be fine") the whole point of communication has failed.

I don't know if adding a small group of volunteers in between can really solve this fundamental problem or if it will only shift the point at which communication is failing to fewer shoulders. --Patrick87 (talk) 21:21, 2 July 2013 (UTC)

• • What on earth are you talking about? The option to switch it off is right there in your preferences, precisely where it was before - David Gerard (talk) 21:34, 2 July 2013 (UTC)

It has been moved out of the logical location of the edit tab in preferences, and buried in the gadgets tab. --Timeshifter (talk) 21:41, 2 July 2013 (UTC)

• Support. Existence of a User Council would not mean WMF is relieved of its responsibilities to involve users in software development or build consensus before implementing them. Personally I see the need for a User Council so it can ensure WMF lives up to the requirement of consensus building we set for every user of the Wikimedia projects. User Council should do its best to determine what the consensus of the user community is and not allow WMF to implement changes (software or other) without it. --Bensin (talk) 21:24, 2 July 2013 (UTC)

  MediaWiki development does operate on consensus building--changes aren't just made by fiat. ^demon 21:35, 2 July 2013 (UTC)

Article feedback tool did not have consensus at the first roll-out. It was aggressively pushed by WMF with little consideration to the user community. --Bensin (talk) 21:58, 2 July 2013 (UTC)

• Comment. A user council is a good interim solution to the lack of cross-wiki watchlists. Here is the medium-term communication solution until cross-wiki watchlists are implemented: Some of the leaders at the level of the Wikimedia Foundation board and staff have been promoted beyond their level of current competence (per the Peter Principle), since some of them are fairly inexperienced at editing Misplaced Pages, or dealing with the intricacies of Misplaced Pages. Some of them hang out at Meta-Wiki, where ideas go to die. Or they create other small wikis such as the Strategy wiki, Usability wiki, Outreach wiki, etc.. To get more in-depth participation in projects, move projects to the Wikimedia Commons, or better yet, back to English Misplaced Pages. English Misplaced Pages has far less systemic bias than in the past. The Commons gets a lot of participation from editors worldwide. For more info see: Misplaced Pages:Misplaced Pages Signpost/2013-01-07/Op-ed, "Op-ed. Meta, where innovative ideas die", especially the comments. See also this article and comments: Misplaced Pages:Misplaced Pages Signpost/2013-05-27/Foundation elections. "Meta: 'a specific kind of mess'?"

Commons has a huge number of active editors (registered users who have performed an action in the last 30 days). Compare the number to English Misplaced Pages. Here are the numbers as of June 2013:

• commons:Special:Statistics - over 30,000 active registered users on the Commons in the last month. 272 administrators.
• en:Special:Statistics - over 124,000 active registered users on English Misplaced Pages in the last month. 1,446 administrators.

Meta, Strategy, Outreach, Usability, etc. would still exist if they were moved to the Commons. They would be independent projects on the Commons. All the documents would still exist. For Meta, everything would continue on: board elections, steward elections, chapter documentation, translations, Wikimania bidding, policy drafting, committee work, GAC/FDC, etc.. The only difference would be that they occur on the Commons where there are far more active editors from around the world. Until there is an Integrated watchlist this is the best way for such projects to get broad participation.

One way is to do it with folders. As on Mediawiki.org at mw:Technical communications/Mobile documentation consolidation where there is a folder for Technical communications subdivided by sub-project. There are many such folders for various projects on MediaWiki.org. It would be easy to do this via meta:Special:Export on Meta, and commons:Special:Import on the Commons. One uses "Destination root page" in the Special:Import form on the Commons, and enters "Meta". So all pages moved from Meta to the Commons would start with commons.wikimedia.org/Meta - I have tested this on another wiki when importing stuff between wikis. It works. If small wikis were moved to the Commons, then templates would no longer have to be duplicated on all those wikis. --Timeshifter (talk) 21:37, 2 July 2013 (UTC)

• Support After the whole thing with the Two Faced Link Wizard and the Quest for the Magical Hidden Off Switch, I am convinced that the WMF people have no clue how encyclopedia editors (or website users in general) work.—Love, Kelvinsong talk 22:04, 2 July 2013 (UTC)
• Support. The intentions are good with the VE and similar, but they get rolled out when the devs think they are ready from a technical point of view, not when the end users think they are ready from an editor's or reader's point of view. See also the Misplaced Pages:Petition to the WMF on handling of interface changes that was launched following the change to notifications (which still have not been fixed). Thryduulf (talk) 23:00, 2 July 2013 (UTC)
• Oppose per Steven and Analogdemon. Just sign up for m:Global message delivery/Targets/Tech ambassadors and you'll know about everything. --Rschen7754 23:04, 2 July 2013 (UTC)

  Ummm. I signed up for that. Not a word about this going live on that mailing list. In fact, one of the reasons I signed up for it was to know when there would be significant software changes, but most of them aren't discussed there. Nor are they discussed on Wikitech-L. And every time I complain, I'm told to sign up to another mailing list, or to post on another project. Communication is an ongoing problem that has never really been solved. Risker (talk) 01:24, 3 July 2013 (UTC)

  @Risker: The link above is actually an on-wiki newsletter, not a mailing list (which I am also subscribed to). It's actually quite interesting, I've been able to follow ULS and Wikidata stuff. --Rschen7754 01:31, 3 July 2013 (UTC)

  BTW, on the latest Tech newletter, "VisualEditor will be enabled for all logged-in English Misplaced Pages users on July 1, and for all users on July 8." πr (t • c) 01:35, 3 July 2013 (UTC)

  RE: Risker. For the record, viz editor was mentioned on wikitech-l - http://lists.wikimedia.org/pipermail/wikitech-l/2013-June/070141.html. However, I would not recommend wikitech-l as a good way to keep abreast of upcoming changes, since its a list for internal development, and the majority of its contents is not about what's going to change tomorrow, but how are we going to go about making feature X which might be done 6 months from now (Which could also be interesting to average users, but is a different use case). Bawolff (talk) 02:33, 3 July 2013 (UTC)

  Agreed. Anyway, I don't understand the scope of this. Will they block changes to all Wikimedia sites because one wiki (enwiki) isn't happy? Or will this just affect deployments here? πr (t • c) 01:18, 3 July 2013 (UTC)

  Just here. But if a council got into the game of just blocking releases then it would have failed IMO. I would imagine the right to block a release as being a big stick (if that power was given to such a council, at all). Really, the focus of a group of this sort should be on ensuring that it never has to use the big stick (i.e. that releases go smoothly and are communicated well, from an end-user point of view). --RA (talk) 06:31, 3 July 2013 (UTC)

  @Rschen:, it's not merely about advance notice but the nature of notices. I first became aware of the plans for the VisualEditor from an announcement on the Admin Noticeboard on June 18 (discussion). There, I was informed, an A/B trial was planned involving a percentage of new accounts. I asked a few simple questions (e.g. how long will the trial run, how will the data inform future decisions, etc.), which went unanswered. I was then informed that the trail would be postponed.

  On the 24th of June another thread opened (discussion) informing me that A/B testing was back on. Again, the talk is about A/B testing on new accounts. Next thing, a week later, and apparently without notice, the VisualEditor is live for all logged-in accounts and planned to be rolled out for all other users a week later again. Gone is A/B testing, gone is a trial just on newbies, and the basic questions I asked on June 18th are still unanswered.

  I appreciate that the WMF guys are enthusiastic (and possibly under pressure). A responsibility a user council could have is to ensure that no release of such major significance and proportions goes ahead backed by such poor communication. That doesn't necessarily mean blocking a release (which is a big stick) as much as simply ensuring that there is clarity and good communication ahead of releases and trials (which is what is needed most of all). --RA (talk) 06:17, 3 July 2013 (UTC)

• Support. This is an excellent idea. As a volunteer project, it seems only natural that we should have something like this. Everyking (talk) 23:41, 2 July 2013 (UTC)
• Half-way Support. I definitely support the spirit of this proposal, although I suspect that similar goals could be accomplished with less bureaucracy if (1) interested users would watchlist wherever development is being discussed, and provide input there, and (2) the WMF folks would pay attention to those discussions and take community concerns seriously. Above, someone pointed out several WMF staff people who are highly responsive to community concerns. I agree that there are a bunch of staff people who are truly a pleasure to work with. Unfortunately, some other WMF staff seem to have an attitude that they know better than experienced editors what is good for us. The very fact that this discussion and others like it exist is evidence that the WMF needs to do better at working to support the editing community, rather than talking down to us. --Tryptofish (talk) 23:47, 2 July 2013 (UTC)
• Support. This is getting out of hand; the WMF has (especially recently) been levying changes upon the entire user interface and technology without bothering to make sure that we know or respect our existing user preferences or comments. About half the time, this works out nicely and everybody is happy. The other half, there can be incredible backlash (as is the case now with VE), including among practically every editor who actually opted into the alpha period before now, and the WMF doesn't bother to even try to fix it. They just tell us, "Well, we told you that it was going to happen in an unnoticeable box at the top of the watchlist you might rarely check, didn't listen to what anyone had to say about it, and deployed it when we said we would in the roadmap buried deep in a proposal discussion. If you don't like it, go away." This isn't really helpful to the community.  — TORTOISEWRATH 01:00, 3 July 2013 (UTC)

• Oppose I applaud the intent, but when push comes to shove, "To have sign-off on software changes affecting end users before they are rolled out" is never going to hold if the Foundation and the community disagree on a question, and that's the core of the reason I'd support the proposal. As a result, I believe this particular exercise will, in the end, not actually solve the problem. Ask yourself: Would the user council have gotten WP:ACTRIAL off the ground? I doubt it. --j⚛e decker 01:21, 3 July 2013 (UTC)
• Too grandiose a title. Call them "editor representatives for software developments". --SmokeyJoe (talk) 01:47, 3 July 2013 (UTC)

  Other terms used for groups like combine "user advocacy" or "user representative" and "group", "committee", "panel", etc. --RA (talk) 06:20, 3 July 2013 (UTC)

• comment: I don't think it would be a bad thing to require community consensus when enabling new features (read: extensions), particularly in cases where they are only being enabled on a single project. Honestly it seems like community consensus is sought when enabling features on projects that aren't enwikipedia, I'm not sure why enwikipedia should be different (To be clear: Only talking about changes aimed at a single community. Things that get enabled on all 700 odd wikis tend to be less controversial and it would be impractical to seek consensus for all of them). I don't see the benefit of a representational council, when things can just happen publicly anyways. Bawolff (talk) 02:22, 3 July 2013 (UTC)
• Comment—The en.WP community's lack of organisation in this area really shows us up against the German-speakers, who've had the benefit of a well-run noticeboard for years. I applaud this proposal. But, can one of its mission statements be to foster greater community awareness of the developers' tasks and challenges? It's a two-way thing. Tony (talk) 02:34, 3 July 2013 (UTC)

  I entirely agree. It is a two-way thing. It's about listening as well as being heard. Communication goes both ways. Involving user more closely in development, I would hope, would help demystify some aspects of it. --RA (talk) 08:41, 3 July 2013 (UTC)

• Support in principle. The Foundation has been well aware for several years of my concerns, most recently again at WT:WER where User:Steven (WMF) has provided some valuable background, but still does not address how the WMF arrives at its priorities for software development. IHMO, the Foundation creates new tools in good faith, but does not sufficiently examine whether or not they are a genuine priority for the community. I think such a council or something on those lines would be a good idea, especially so that the WMF does not allocate funds and developer time on gadgets, and focuses more on the bigger issues such as, just to cite two examples, new page quality control, and better information for new users. Most of us could probably live for a while longer without article feedback tools, WikiLove, thank buttons, visual editors, liquid threads, and notifications systems (actually quite good) that replace the orange banner. WP:ACTRIAL was a good example of how the community has brought pressure to bear on the Foundation, but there is no regulatory body to find out who is right and who is wrong. The overall impression left from ACTRIAL was that the Foundation owns the servers, and if they don't like a community consensus, they just won't implement the request, even for just a trial whose objective was to clearly measure the effect of a community suggestion that had been agreed by no small participation and a healthy consensus. Another example is the Page Curation tool set - a truly brilliant piece of software (in the right hands), and developed with a lot of editor participation and well coordinated by a Foundation contractor, but the community didn't directly ask for it, and it didn't address the core issues with new page patrolling that still persist to this day. Kudpung กุดผึ้ง (talk) 03:37, 3 July 2013 (UTC)
• Support - There clearly needs to be a countervailing force to the cavalier and uncritical attitude of the Foundation about change. Carrite (talk) 04:37, 3 July 2013 (UTC)
• Oppose. This idea seems to have arisen only because the proposer ignored years of very prominent and conspicuous requests for comment, discussions, and site notifications on Misplaced Pages and other Wikimedia websites, and, if they have a life outside Misplaced Pages, possibly also a good deal of third-party coverage in magazines, blogs, and social media. "Visual Editor is coming; your input is solicited!" has been plastered all over the place for a very long time now, and it looks like the WMF has been duly diligent in monitoring and collecting feedback from the ensuing discussions. It's not their fault if some people consistently failed to participate despite a plethora of very well-advertised opportunities. I'm all for officially designating one or more venues where the WMF must give notice and monitor discussion of technical and UI changes (which of course would not preclude further advertisement and discussion of such changes elsewhere) but given how admirably the latest change was publicized I see no need for this process to be overseen by an independent body. —Psychonaut (talk) 07:33, 3 July 2013 (UTC)

  People are busy, and separate wikis currently require separate watchlists. So people may try to join discussions on the smaller wikis that WMF, staff, and developers favor, but soon stop regularly checking the watchlists for those smaller wikis. See my long comment higher up where I explain this in detail, and propose various long, medium, and short-term solutions. A user council changes our participation from direct democracy to indirect, representative democracy. It is an improvement on the current anarchy. --Timeshifter (talk) 08:24, 3 July 2013 (UTC)

  Blaming the intended receiver of communication for not receiving the message (no matter whose fault it is) doesn't resolve the matter. There should not have been any major surprises around this (or any other) roll out. That break down in communication, irrespective of who is to blame, needs to be addressed. If the solution is that users need to participate more, then that is what this proposal is about. --RA (talk) 08:47, 3 July 2013 (UTC)

  That claim doesn't match what people are writing above: they're going "Why wasn't I consulted?!" and flatly ignoring the stupendous efforts to do so. As you are - David Gerard (talk) 09:14, 3 July 2013 (UTC)

David Gerard. It is you who are ignoring the various replies to you. And inviting people to discussions on small wikis with separate watchlists is not a stupendous effort. It is an inadequate effort which has been pointed out numerous times by many people over the years concerning communication between the WMF board/staff/developers and Misplaced Pages editors. --Timeshifter (talk) 10:48, 3 July 2013 (UTC)

• Oppose Don't fix what ain't broken. I feel, Misplaced Pages has some kind of "Just complain about anything & everything" culture. We have more that enough onsite & offsite forums for doing that. The VE and WMF guys have done a wonderful job creating and communicating their stuff, and if some guys failed to notice, it must be due to their lack of curiosity. A council of this sort would only produce endless, pointless hairsplitting and only create hurdles in progressive work. Cheers.OrangesRyellow (talk) 10:58, 3 July 2013 (UTC)

"ain't broken"? You are kidding. See Misplaced Pages:VisualEditor/Feedback. Onsite forums with substantive discussion only started relatively recently on English Misplaced Pages concerning the visual editor. And substantive discussion connected with an alpha/beta version of VE working with articles on English Misplaced Pages is what counts. It is better to have the hairsplitting earlier in the design process before major, costly mistakes are made. A user council might have helped in that area, and can help now too. We need dedicated users in it for the longterm. That is an elected user council. Average users can only check small-wiki watchlists for a few months at the most before they tire of having to check multiple watchlists. A user council is in it longterm. --Timeshifter (talk) 11:16, 3 July 2013 (UTC)

Of course it "ain't broken". It works. It has bugs, and this is only to be expected for any new software. I trust the VE team can and will fix them. Even Microsoft created Windows OS systems always come with bugs and they keep fixing them all the time. Nothing unusual or unexpected there. The VE is going to revolutionize our falling ed numbers and we should all support it. In the meantime, anyone who is unsatisfied can easily use the old edit interface. Since the old interface is readily available, I see no possibly of any major damage. I still do not see any valid reason for hairsplitting or usercouncil. Users who want to help out with testing or discussions can also do so without being elected to do so. They can self elect to do so.OrangesRyellow (talk) 13:31, 3 July 2013 (UTC)

Something can be barely usable, and broken. It's funny that you bring up Microsoft and its operating systems. --Timeshifter (talk) 21:12, 3 July 2013 (UTC)

• Not as proposed A "user council" would probably be a nice idea, but I'm skeptical it would actually change the sort of things being complained about here. It would be good to get more editor input into the development process (and hopefully the new WMF-hired community liaisons will be able to help with this too). But "sign-off on software changes", if that means "veto power" as some of the above supports are implying, no. I remember too well the reactionary site-wide CSS change that still prevents new users from having watchlist bolding until they discover gadgets, and the complaints about the diff color scheme change that thankfully resulted in a "old color scheme" gadget rather than an "override it for everyone because I don't like it!" mess.
  As for the problems most people here seem to be complaining of, I doubt a user council would have much effect. The people who missed all the various notices that VE was coming will still miss all the notices. And the people who don't like something will still complain that their input somehow wasn't considered, no matter that this user council exists. As for the council itself, it could go both ways: it could be a useful resource to get more community-focused feedback in development, or it could be populated by "Oh noes! Change!" reactionaries who would obstruct rather than help guide development. Anomie⚔ 12:30, 3 July 2013 (UTC)

Yes, this is problematic: "To have sign-off on software changes affecting end users before they are rolled out." That should be changed to "ongoing consultation". The real sign-off occurs when something is deployed. If enough people dislike something they will edit less. They have effectively not signed on. WMF then either pays attention, or there is a further slide in the total number of monthly edits on Misplaced Pages. WMF can then pay attention and fix the problem. Or the WMF gets developers to develop gadgets and preferences to ameliorate the problem for some people. A user council might prevent some problems from occurring at all. --Timeshifter (talk) 21:26, 3 July 2013 (UTC)

"If enough people dislike something they will edit less."

I've not seen any research indicating that this is likely. I've seen evidence that contradicts this claim when "dislike" is measured within the first few weeks after a major change, rather than after the established users have had enough time to explore the new system: it's normal for power users to dislike change to "their" website, no matter what the website is or what the change is. WhatamIdoing (talk) 11:34, 4 July 2013 (UTC)

It only took a few days for my prediction to be proven right concerning the hidden "edit source" links on sections. It has already been reverted due to the barrage of complaints about it. It is not a matter of just getting used to something in many cases. If people continue to dislike something enough, or if it continues to hinder their editing enough, or if it continues to slow them down enough, then many of those people will edit less. Since Misplaced Pages is a volunteer effort this is more true than for employees at a company using software. They have to tolerate the software if that is what their boss wants. According to the chart on the right there are twice as many edits by registered users as anonymous users. It would be a bad idea to believe that we can afford to slow down editing by registered users in the hope that providing any visual editor (no matter how buggy) will cause the number of anonymous IP editors to increase enough to create a net increase in the number of monthly edits. See File:Edits per month on Misplaced Pages.gif The WMF needs to think more clearly about the net effects of changes to editing. They would be able to do that better if there were a user council. --Timeshifter (talk) 01:42, 5 July 2013 (UTC)

As I said above, the edit section links will be restored on Monday.

You seem to believe that sheer number of edits is proof that registered users write the articles. Have you read any of the research on that point, like Aaron Swartz's? Registered editors revert a lot, and they do a lot of gmoning and copyediting, but IPs are responsible for providing a lot of the content. Whatamidoing (WMF) (talk) 03:42, 5 July 2013 (UTC)

• Oppose. I think that more a cooperative relationship between the WMF and its wikis is a good idea, but I would rather have it done using the existing community input processes (e.g. RfC) rather than add bureaucracy. Kudu  15:11, 3 July 2013 (UTC)
• Reluctant support. Things like that should be handled informally, with developers (and/or related non-developers) doing proper requirements elicitation and collaborating with the users (the Community). After all, that's just how software engineering is supposed to work. Then the final decision before deployment would be a mere formality that would not need additional bureaucracy. But, unfortunately, instead of that we get complaints that "The proper time for discussion is when changes are being proposed or written, not before they're deployed.". Sorry, but that is exactly when discussion is vital. Since someone mentioned buggy pre-Service Pack versions of Windows - well, the whole point is that then it's the user (not Microsoft) that makes the decision if he wants to install the new version or not. (It is only natural that this decision should be done when we know what exactly has been created - not until development is finished.) How comes that it is the "supplier" that makes this decision in our case? Something related to sunk costs..? (But, I hope, the pay of developers does not get postponed until deployments..?) So, if that is the way in which the users (in this case - the Community) can make decision to deploy something or to refuse to deploy it, that probably should be done... Though still, informal approach with developers (and/or related non-developers) actively looking for friendly but harsh criticism and engaging it in good faith would be far more preferable... --Martynas Patasius (talk) 18:48, 3 July 2013 (UTC)
• Seems rather useless. The people who want to be involved in these things find out and get involved. Others just don't bother to get involved until deployment. That will not change. And what the council "likes" in your user interface and what others like will still be two (or more likely many) different things. Then you will get conversations, like the council trying to explain to others all the great work they did, and others arguing back that they did terrible work and should resign, etc. etc. and on and on. Alanscottwalker (talk) 19:46, 3 July 2013 (UTC)
• Oppose. Some fancy scheme to elevate representatives distracts from the main point that WMF developers need a more visible central announcement board that users can easily check to know about everything coming down the pipe whatever it is. If they do their job to notify a council they can do their job to notify a central announcement board, and conversely... (To be clear, I think that users as a whole should enjoy the "rights" of the proposed council above) Wnt (talk) 22:27, 3 July 2013 (UTC)

The WMF and developers have been "announcing" the visual editor for years. Notices and announcements are not the problem. Notifying a council is not enough either. What is needed are easy ways of substantive engagement. That did not occur until recently. --Timeshifter (talk) 23:10, 3 July 2013 (UTC)

This is fatuous. We have just conclusively demonstrated that there exists no place to notify that no editor will claim they did not see and that it's an outrage - David Gerard (talk) 23:13, 3 July 2013 (UTC)

Why the frequent drama in your comments, O David Gerard? Notifying is not the problem in my opinion. We need a longterm place for easy discussion, and give-and-take, at an earlier stage of a specific software project. "Easy" means via an English Misplaced Pages watchlist, or a cross-wiki watchlist. "Easy" means not using LiquidThreads for discussion. "Easy" means a separate discussion page for each project. --Timeshifter (talk) 23:35, 3 July 2013 (UTC)

Sorry, but there is a simple process to inform and "survey" a significant part of users when you really need it. It is described in "Evolutionary prototyping". Make a "prototype" - perhaps a "release candidate". Enable it for, let's say, a day (with announcements before that). Then roll it back and ask if the users like that change. The problem with current announcements is that, well, there is an impression that it does not really matter if we will read them. Let's say, everyone will read an announcement "Change C will happen on day D.". What difference does it make, if there is a perception that the change (perhaps with minor modifications) will happen no matter what..? After all, it is really just an announcement, not a request for harsh criticism. For example, m:Tech/News/2013/27 says: "VisualEditor will be enabled for all logged-in English Misplaced Pages users on July 1, and for all users on July 8.". Well, if it will happen and the user can do nothing about it, why should he care before it gets enabled..? For that matter... When is the last moment when opposition of users can actually stop major UI changes..? --Martynas Patasius (talk) 00:33, 4 July 2013 (UTC)

My emphasis above was meant to be on the visible. It may be fatuous, but I'm not sure if I've even heard of m:Tech/News before, though it certainly does look like a good effort. I don't see it linked anywhere obvious at the top of the various village pump pages or the community portal. Wnt (talk) 01:16, 4 July 2013 (UTC)

• Support. Something seems to have broken down in the relationship between editors and the Foundation, and this might help to get it back on track. SlimVirgin 00:04, 4 July 2013 (UTC)
• Somewhat support. I think there could be real value in creating a more formal consultation process between the WMF and the community to discuss technical issues, especially those surrounding new features. It could help to set priorities and communicate community concerns. However, I think anyone who imagines that the "User Council" (or whatever one wants to call it) could have a veto over the WMF is pretty much dreaming. Dragons flight (talk) 01:22, 4 July 2013 (UTC)
• I support the establishment of a group of volunteers to work with software developers on software changes. I do not necessarily support an elected body of representatives, nor do I think it realistic to propose that our representatives have any veto power over the changes.—S Marshall T/C 18:54, 4 July 2013 (UTC)
• Oppose in part, primarily the idea of giving any sort of veto power or a consensus model for technical enhancements. Doing it that way is the surest way to ensure nothing ever changes or improves. Better to come up with ideas that improve visibility of the notices and discussions that do go out, and allow for better consultation with editors. Resolute 01:49, 5 July 2013 (UTC)
• Support if necessary, There are two reasons why we must do something. first, the WMF is responsible for the development of the software, but on any particular WP, the community of editors there is responsible for how to use it. There will be occasions when the wmf will judge something the community wants as not practical, or where the WMF finds that maintaining a reasonable degree of consistency mandates something the community does not really like, and these will have to be resolved by discussion. (As I see it, the use of notifications was one where the decision should have been left to the community entirely. On the other hand, a visual editor should be a general feature of editing across all WPedias, though practical considerations may require slightly different implementations.) If the developers are of the opinion that the community is being unduly resist to reasonable modernization, the proper way is to convince us, just as any other group or individual who wants to introduce changes. I do not think the wmf accepts this principle, and I think we in the community would be right in doing whatever we can to convince them to accept it,a the only basis for collaboration. second, the WMF has shown itself not very competent at communication to the community, and probably the community is not much better. The WMF tends to think meta and other discussion media under its control are sufficient, and that notices will do for implied consent. Neither is realistic, and the response to their trials indicates it. None of us can be everywhere, and the place to discuss the English WP is the English WP, which is where the people working on it primarily work. . The overall development of MediaWiki is another matter, but the implementation on enWP must be discussed on enWP. The community here, for its part, tends to solve problems by multiplying the number of forums, delaying decisions, and letting steadfast opposition prevail over rationality. therefore once it is accepted that these matters must be discussed, we need a single centralized place on enWP to do so, where things will be discussed and rfcs conducted according to our accustomed manner. But this will only work if the WMF accepts the first part, that the community will be the responsible body for deciding, just as they are for content and working procedures. I doubt they will, and in that case, the community needs some countervailing power. If so, a council of this sort is the best solution. Since the WMF by and large finds its manner of work requires it to speak in a single voice according to its own consensus, the community will need some way also., and a council of this sort can be an effect intermediary, if it is necessary to see this as different groups vying for power. DGG ( talk ) 04:41, 5 July 2013 (UTC)

Misplaced Pages:User Advocacy

I believe the taking the first step if you want to see change, so I'm going to be bold.

I think there's consensus above that something be done, but I don't think there is consensus at this time for something as formal as what I proposed. In all, I think a consensus position can be summed up by Tony1's comment at 02:34:

The en.WP community's lack of organisation in this area really shows us up against the German-speakers, who've had the benefit of a well-run noticeboard for years. I applaud this proposal. But, can one of its mission statements be to foster greater community awareness of the developers' tasks and challenges? It's a two-way thing.

I've created a project page at Misplaced Pages:User Advocacy. The purpose of that page, I hope, will be to act as meeting point between EN wiki users, developers and the Foundation. I believe there is consensus above for a step like that.

I'm deliberately not creating a WikiProject because I don't believe this should be a matter of special interest to a few users. The tools we use is something that affects the project as a whole. The page does not create a committee, or council, or cabal of any kind. However, the phrase "user advocacy" is often used in describing the kinds of committees that the proposal above is based upon.

I hope that it will facilitate discussion, knowledge sharing and exchange of ideas. I hope too that it will act as a venue for those advocating greater user engagement to engage themselves in that area and spread the word. I hope too it will draw in the imagination, expertise and knowledge of developers and Foundation staff in support of their efforts.

The page is deliberately in a brain-storming state. I've just created a few headers for now. So, please, everyone is welcome and invited to contribute and participate. --RA (talk) 23:13, 3 July 2013 (UTC)

I've written an extensive reply with notes and pointers and thoughts, but I didn't want to overwhelm your description here, so I've placed it at Misplaced Pages talk:User Advocacy. Hopefully that will help both this discussion, and that advocacy page, move forward. –Quiddity (talk) 05:35, 4 July 2013 (UTC)

Modern Tables

Hi,

I wold like to suggest you to implement the following. For every table in wikipedia, can you keep the first Row on top, so that one does not need to go up for checking what each column stands for. (Just like in Google spreadsheet )..

Cheers

• Misplaced Pages noticeboards
• Misplaced Pages proposals
• Pages automatically checked for accidental language links
• Misplaced Pages requests for comment