Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by TCO (talk | contribs) at 05:37, 14 July 2013 (→‎Discussion). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


« Archives, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Mass removal of old indefinite rangeblocks

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)[reply]

Links -

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)[reply]

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)[reply]

  • 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)[reply]

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)[reply]

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
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)[reply]

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)[reply]
  • 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) (Past espionage) 13:00, 25 June 2013 (UTC)[reply]
  • 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))[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
This is an eminently reasonable option as well. Sailsbystars (talk) 09:57, 26 June 2013 (UTC)[reply]
Yeah, this seems like a good solution. NinjaRobotPirate (talk) 13:23, 26 June 2013 (UTC)[reply]

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

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)[reply]

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?

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)[reply]
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)[reply]
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)[reply]
Sailsbystars, it is 200 indefinite ones. TheOriginalSoni (talk) 16:47, 25 June 2013 (UTC)[reply]
199 ;p ·addshore· talk to me! 17:18, 25 June 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

  • As proposer, Aye TheOriginalSoni (talk) 22:20, 25 June 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    Let ArbCom do it? XD MM (Report findings) (Past espionage) 08:08, 28 June 2013 (UTC)[reply]
    I don't think workload would be an issue, if the period is 1 year. 6 months might be a bit too frequent, though. -- King of ♥ ♦ ♣ ♠ 23:23, 7 July 2013 (UTC)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
I Like This. I think we should. MM (Report findings) (Past espionage) 08:08, 28 June 2013 (UTC)[reply]
  • Final Note - If there are further topics of discussion, please add them as a section above this line.

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)[reply]

ClueBot III does this automatically. Graham87 02:33, 1 July 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

Is there a list of, or discussion somewhere on what will become of Cluebot III tasks or any other bot tasks and/or templates that will become deprecated once WP:Flow is fully rolled out? -- Ϫ 05:50, 8 July 2013 (UTC)[reply]

Not that I know of, but that's a good idea. Wikipedia talk:Flow might be the best place to start a discussion; however, the architecture and features are still in the very early stages of prototyping and brainstorming (afaik), so it might be too early to make any kind of solid criteria, as yet. I'm not sure which of the mw:Flow Portal/Use cases#User talk namespace are being planned for, in the initial rollout. –Quiddity (talk) 20:01, 13 July 2013 (UTC)[reply]

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)[reply]

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)[reply]
It is effectively removed for many editors, because the "edit source" link on sections is HIDDEN. --Timeshifter (talk) 20:44, 2 July 2013 (UTC)[reply]
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)[reply]
It is funny to see you get stuck with one reply in spite of the barrage of new comments agreeing with me at Wikipedia: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)[reply]
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 Wikipedia).
You want an example? Here it is! [edit | edit source] 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)[reply]

(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)[reply]

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)[reply]
Well, hopefully they will put 2 direct links ("edit" and "edit source" without hover) on every section. --Timeshifter (talk) 05:34, 5 July 2013 (UTC)[reply]
FYI the bug with the missing VE section edit links is bugzilla:50731. I just asked to fix bugzilla:50540 at the same time which is about having both – "edit" and "edit source" – visible at the same time. But I'm afraid the devs are not yet aware of the hassle the hiding of the "edit source" tab causes and that hovering every time is not acceptable. --Patrick87 (talk) 09:26, 5 July 2013 (UTC)[reply]
The developers have been informed about this in several Bugzilla threads. For example in Bugzilla:50540, Maggie Dennis writes: "Note that this request is being repeated a lot, including by people who are unhappy that mousing over causes words to pop up, which they say disrupts reading the page. They would prefer the words be always visible to avoid this."
In the same Bugzilla thread: Eduard Braun writes: "This is (from what I get from the comments, the discussions linked are a little less clear I'm afraid) not about section 'edit source' links being loaded with delay (although this would be an issue, too). It's about having to hover over the 'edit' link to be able to see the 'edit source link'. They should both be directly accessible (without hovering and visibility changes)." I also have commented on this in some Bugzilla threads. --Timeshifter (talk) 11:50, 5 July 2013 (UTC)[reply]
"Have been informed" and "Being aware" aren't the same I'm afraid. Look at the importance: "Lowest enhancement" mostly means "we don't care at all". If we can't communicate to devs that this is important to us, we'll be stuck with hidden "edit source" links again as soon as gerrit:72069 lands (which is the current fix for bug 50731) --Patrick87 (talk) 12:12, 5 July 2013 (UTC)[reply]

(unindent). Patrick87. You are right. I left a longer comment at Bugzilla:50540. See the links I left there. This should be a priority and not just an enhancement. To think that future versions of MediaWiki will be crippled longterm by this incredibly buggy and slow visual editor is very discouraging.

At the very least there needs to be a preference for direct "edit" and "edit source" links built in to MediaWiki preferences on the edit tab of preferences. MediaWiki installations should not need a "gadget" preference added for this by each webmaster of every MediaWiki installation.

The hidden link to "edit source" is slowing down many editors. There have been many more comments requesting a direct link to "edit source" on each section. See:

Slowing down the many editors who will continue to need source editing to edit complex things more easily is a really dumb idea. What is the logic? That the WMF and developers will irritate and trick editors into using the visual editor? That editors will click the "edit" link instead of the "edit source" by being tricked? It is extremely irritating to have to spend extra time to get to source editing. The WMF and developers will not lack in bug reports by providing direct links to "edit source". --Timeshifter (talk) 07:15, 6 July 2013 (UTC)[reply]

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)[reply]
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 Wikipedia will still exist then. Whatamidoing (WMF) (talk) 14:28, 4 July 2013 (UTC)[reply]
Reliability and user-friendliness never go out of style. Future computers will eventually operate on DNA instead of silicon, but that isn't relevant to this discussion. Computers operating on another physical medium (with a much higher information density) are no reason not to continue user interfaces that are, well, user-friendly! This includes rather simple source editors where it is extremely easy to add cells to tables and so on and so forth. (In fact, it's easier to add table cells in Edit Source here on Wikipedia than in Microsoft Word, which was designed to be the most user-friendly word processor ever! Even copying and pasting from Excel is a pain compared to making tables in Edit Source.) So, yeah, we're talking about user interface only. Post-silicon computers, running on DNA most likely, are not an issue for this particular discussion.
Does this mean I'm against an occasional change in syntax in subsequent versions of Edit Source? No, that's fine as long as Community Consensus favors each syntax change. Indeed, we already did that with Succession Boxes. The Mysterious El Willstro (talk) 22:05, 6 July 2013 (UTC)[reply]
To put it another way, the physical medium and kernel at the core of a computer are a totally different issue from the user interface at the surface. In terms of keeping some form of a Source Editor in addition to a Visual Editor, we are concerned only with the latter. The Mysterious El Willstro (talk) 22:16, 6 July 2013 (UTC)[reply]

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 Wikipedia 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 "Wikipedia", 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 Wikipedia. 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 Wikipedia 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 Wikipedia 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)[reply]

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)[reply]
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 Wikipedia 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Notices are good, but notices are not discussion on English Wikipedia. There has been very little alpha or beta discussion on English Wikipedia until recently. All of a sudden there is substantive discussion on English Wikipedia 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 Wikipedia, or if an experienced, elected, accountable user council had been involved early on. A user council that reported back often to English Wikipedia. --Timeshifter (talk) 11:03, 3 July 2013 (UTC)[reply]
... and to ensure there are "How to turn it off"-options. --Bensin (talk) 21:27, 2 July 2013 (UTC)[reply]
You mean, like the one that's still there from before? - David Gerard (talk) 21:37, 2 July 2013 (UTC)[reply]
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)[reply]
I mean, like the one that's not there at all... (But should be per Wikipedia: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)[reply]
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)[reply]
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)[reply]
What an amazing display of dismissive, patronizing, fingers-in-ears nonsense. Thanks for your contribution, David. — Scott • talk 12:20, 12 July 2013 (UTC)[reply]
I think David's frustration, and the frustration of any user who has put up with dozens and dozens of semi-spammy announcements about VE, is understandable. He asserts that he had no warning, despite watchlist notices for weeks. Maybe we need to know more about his system: there might be a bug there, maybe he's done something to disable watchlist notices entirely, or maybe he just forgot that he clicked past it. He's an admin, but he apparently doesn't keep up with WP:AN. He also says that he doesn't interact with any of the 40 or 50 high-traffic pages that I personally posted messages to, or apparently any of the others that many other people posted messages to. This launch involved the most effort ever expended to reach people in advance. Short of spamming each user talk page, if anyone thought it could be done, it was.
He's unhappy that no one told him about VisualEditor's impending appearance—which is totally understandable—but he's not giving anyone any useful hints about how he could have been reached. He's just saying it didn't work, and that it's all our fault that we didn't reach him. So how do you think we can solve his problem? Imagine that a User Council exists and is trying to reach him and other people like him. What exactly are they supposed to do to reach this user, that wasn't already done this time? The only thing I've come up with is to make clicking past watchlist notices a publicly logged item, so that when someone claims he never saw it, we can say, "Funny, but the log says somebody using your account read and dismissed that message, and, if that really wasn't you, then let's de-sysop your account until you figure out how to keep other people from using it." What would you do? How would you reach this kind of user? Whatamidoing (WMF) (talk) 01:19, 14 July 2013 (UTC)[reply]

arbitrary breaks for discussion

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 Wikipedia. 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)[reply]
Tech News is great. I get it on my talk page. --Timeshifter (talk) 10:55, 3 July 2013 (UTC)[reply]
  • Support. Long overdue. See my user page for more info. --Timeshifter (talk) 20:42, 2 July 2013 (UTC)[reply]
  • 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 (talk/contribs) 20:48, 2 July 2013 (UTC)[reply]
  • Support Great idea. Mlpearc (powwow) 21:03, 2 July 2013 (UTC)[reply]
  • 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[omg plz] 21:10, 2 July 2013 (UTC)[reply]
    Not self appointed. They should be elected IMO. And only EN-wiki. --RA (talk) 21:15, 2 July 2013 (UTC)[reply]
    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[omg plz] 21:31, 2 July 2013 (UTC)[reply]
    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-Wikipedia 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)[reply]
    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[omg plz] 22:28, 2 July 2013 (UTC)[reply]
    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)[reply]
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 Wikipedia. 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)[reply]
  • 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 Help resolve disputes! 21:13, 2 July 2013 (UTC)[reply]
    • 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)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
    MediaWiki development does operate on consensus building--changes aren't just made by fiat. ^demon[omg plz] 21:35, 2 July 2013 (UTC)[reply]
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)[reply]
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 Wikipedia. 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 Wikipedia 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/wiki/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)[reply]
  • Support After the whole thing with the Two Faced [edit] 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)[reply]
  • 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 Wikipedia: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)[reply]
  • 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)[reply]
    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)[reply]
    @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)[reply]
    BTW, on the latest Tech newletter, "VisualEditor will be enabled for all logged-in English Wikipedia users on July 1, and for all users on July 8." πr2 (t • c) 01:35, 3 July 2013 (UTC)[reply]
    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)[reply]
    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? πr2 (t • c) 01:18, 3 July 2013 (UTC)[reply]
    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)[reply]
    @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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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 deckertalk 01:21, 3 July 2013 (UTC)[reply]
  • Too grandiose a title. Call them "editor representatives for software developments". --SmokeyJoe (talk) 01:47, 3 July 2013 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
So the council should exist more to advise the Foundation on the wants and needs of the community rather than to attempt to inform users of upcoming changes? Michaelzeng7 (talk) 12:32, 13 July 2013 (UTC)[reply]
  • 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)[reply]
  • 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 Wikipedia and other Wikimedia websites, and, if they have a life outside Wikipedia, 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
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 Wikipedia editors. --Timeshifter (talk) 10:48, 3 July 2013 (UTC)[reply]
  • Oppose Don't fix what ain't broken. I feel, Wikipedia 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)[reply]
"ain't broken"? You are kidding. See Wikipedia:VisualEditor/Feedback. Onsite forums with substantive discussion only started relatively recently on English Wikipedia concerning the visual editor. And substantive discussion connected with an alpha/beta version of VE working with articles on English Wikipedia 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
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 Wikipedia. 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)[reply]
"If enough people dislike something they will edit less."citation needed
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)[reply]
Anonymous, registered, and bot edits. English Wikipedia timeline. More charts are needed.
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 Wikipedia 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 Wikipedia.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)[reply]
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)[reply]
I only pointed out the 2 to 1 ratio of edits by registered editors versus anonymous IP editors. Hopefully the developers will put 2 direct links ("edit" and "edit source" without hover) on every section. --Timeshifter (talk) 05:42, 5 July 2013 (UTC)[reply]
  • 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 ~I/O~ 15:11, 3 July 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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 Wikipedia 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)[reply]
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 Wikipedia 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)[reply]
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)[reply]
  • 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 (talk) 00:04, 4 July 2013 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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 resistant 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, as 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)[reply]
  • In other news, I just discovered that an English Wikipedia (San Francisco) User Council was already formed few days ago, it's called roundtable 1. --Nemo 08:16, 5 July 2013 (UTC)[reply]
    that's a commendable effort by the foundation to explore how editing works, and I encourage them to continue. (I would not want to do it myself; I don't do well in that sort of structure.) Watching people do it is helpful. What's even more helpful is editing oneself. Perhaps the first month of everybody hired by the WMF should be an apprenticeship, editing and fixing problems on a project of their choice on what ever topics they care for, and perhaps every WMF employee should spend about 10% of their time doing it. This isn't paying people to edit, because they'll do whatever they like, and interact with the community in the normal way and learn from the interactions.
    But it's not the sort of user group I think we have in mind. Our group will be run by us, in our way, and do what the people in it think necessary and important. DGG ( talk ) 23:42, 5 July 2013 (UTC)[reply]
    I think Nemo was joking (I hope so!). The 1st roundtable was a cross between an in-person IRC office hours, and a 1 day editathon. I think they hold the latter, at the offices, quite frequently? (ask at Wikipedia:Meetup/San Francisco for info, perhaps)
    I completely agree with your suggestion that WMF staff should each spend some time regularly (at least an hour a week) editing articles, even if it's as an IP/anon. That would help in oh so many ways. –Quiddity (talk) 00:46, 6 July 2013 (UTC)[reply]
  • Oppose. I think the idea of getting user input is great. I just don't think a council is the way to do it. In my experience councils end up being lots of non value added work and no matter who you put on it they tend to represent their own interests not the community as a whole. I think a better use of resources is to do more empirical assessment of how users actually use Wikipedia and what they want to see from it. Mdebellis (talk) 23:47, 5 July 2013 (UTC)[reply]
  • Support First off, the patchwork of a dozen different forums, most of which are not designed for projects and tool suggestions, is not working. Second, when something is everyone's job, it is no one's job. This is an area where the community needs a task-force of point people who are willing to take responsibility for interfacing with the developers. I'm not saying that everyone shouldn't give feedback, but we need more focus. II | (t - c) 04:18, 6 July 2013 (UTC)[reply]
  • Some of the arguments in favour of this proposal have pushed me to Oppose. Agree with Demon above that we don't have any shortage of ways to feed into software and user interface development. Agree with DavidGerard and others that the idea that we weren't given enough notice of the visual editor just seems obviously false: I don't know how regular editors could not have heard of it multiple times before now. RA phrased the proposal carefully in terms of involving current and potential users, but the way some other people have interpreted it is as entrenching the conservatism of the existing user base, which is bad because they are not representative of all the people who could constructively contribute to Wikipedia. I'm not even persuaded that RA's proposal above solves a problem, but creating a project page for User advocacy (below) seems like a good next step. MartinPoulter (talk) 14:37, 6 July 2013 (UTC)[reply]
  • Oppose. As User:Steven Zhang mentioned, the Wikimedia staff are doing a fine enough job and I AGF that they have Wikipedia's best interests in mind. -- œ™ 05:27, 8 July 2013 (UTC)[reply]
  • Support Council. This idea, of a "#User Council" at least attempts to empower the enwiki community to remind WMF about things that really matter to thousands of users. To my horror, I discovered how simple fixes to auto-merge wp:Edit_conflict revisions were not implemented to improve diff3 merge, and in fact, there was no plan to fix edit-conflicts, as if VisualEditor were a million times more important than auto-merging 95% of edit-conflicts which need only a few hours of software changes. Plus, to my recent horror, I discovered how "[http:...]" web-links implicitly add a trailing slash "/" which prevents linking a URL address which has some CGI parameters (such as: http://tools.wmflabs.org/xx&ns=1), although the bug seemed to have been fixed hours later. Then there is the wp:Expansion depth limit, of 41/40 nesting levels, which should have been raised, years ago, to 50 or 60 or 80 levels deep, but instead we get no improvement. Then there is the need to set a parameter value during template processing, such as {{#set:x|45}}, to make some templates run 20x-40x times faster by checking a stored result, but the WMF does not value that simple, crucial improvement. Plus page names need to end with '#' such as "C#" (C-sharp). I think the WMF seems totally out-of-touch with reality, fiddling with an expensive wp:VisualEditor which will take 3 years to become adequate, while ignoring numerous critical changes to make page processing much easier and several times faster, years sooner. By the way, I discussed issues at wp:Bugzilla and got no positive feedback from WMF. So, I support a User Council to try to emphasize the priorities to get important problems fixed, years sooner. I can appreciate that the typesetting conniptions for 269 languages (with non-Latin alphabets) has been very time-consuming, but some language support needs to wait a few months while massive problems in the English Wikipedia get fixed, and those fixes will then likely apply to hundreds of other-language Wikipedias. -Wikid77 (talk) 21:04, 10 July 2013 (UTC)[reply]


Wikipedia: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 Wikipedia: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)[reply]

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 Wikipedia talk:User Advocacy. Hopefully that will help both this discussion, and that advocacy page, move forward. –Quiddity (talk) 05:35, 4 July 2013 (UTC)[reply]
Quiddity, thanks for your comment. I've intentionally not replied so as to leave the discussion to others. I see a positive discussion has opened between you and another user. --RA (✍) 13:15, 7 July 2013 (UTC)[reply]
I've worked a little on initial tasks a User Advocacy effort could work on. This is just an initial list, as follows:
  • Brainstorming: We need to plan and build awareness of the User Advocacy effort.
  • Roadmap: User-accessible information the software roadmap is being drawn up.
  • Features: A list of individual software features for for feedback is being prepared.
  • VisualEditor: Research question and methodology proposals are being prepared.
  • Volunteers: An audit of people, skills and resources available to the User Advocacy effor is being compiled.
Please contribute to the areas above if you can. Thanks, --RA (✍) 13:15, 7 July 2013 (UTC)[reply]

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 — Preceding unsigned comment added by Nanopavan (talk • contribs) 22:58, 4 July 2013 (UTC)[reply]

I'm not familiar with the Google spreadsheet, but I think you're talking about something like a scrollable spreadsheet with a locked header. The problem is that it is the page that is scrolling rather than the table. But there's probably some means to code a table with a moveable header block that stays within the field of view. The rows would need to be shifted to accommodate the insertion, but in theory it should be do-able. In long tables the easy alternative is to repeat the header at regular intervals. Praemonitus (talk) 14:45, 5 July 2013 (UTC)[reply]
This is outstanding feature request 40763. —TheDJ (talk • contribs) 22:43, 6 July 2013 (UTC)[reply]

Motto of the Day

I feel that WP:MOTTO is strong enough that it should deserve a spot on the Main Page. There are many people who work on it, and it has a reasonable process for choosing them. Below is an example of one. buffbills7701 01:55, 6 July 2013 (UTC)[reply]
Today's motto...

→ Being the richest man in the cemetery doesn't matter to me ... Going to bed at night saying we've done something wonderful... that's what matters to me.
  • I'll get the ball rolling here. In general what qualifies as a motto, and about how many of them are there that could be used on the main page? Hot Stop talk-contribs 01:59, 6 July 2013 (UTC)[reply]
  • This has been suggested before (at Talk:Main Page/Archive 78#Motto of the day, Talk:Main Page/Archive 126#WP:MOTD, and Talk:Main Page/Archive 164#MOTD at the least) - The primary objections have always been: There are too many mottos that require insider knowledge; there are too many in-side jokes; there are too many links to humorous essays that will confuse the hell out of non-editors.
    These are mottos that are for editors to read, not for readers (the target audience of the Main Page). There are some good quips in there, and it's a fun thing for editors to participate in and place on their userpages; but it's simply not suitable for the Main Page. Sorry. –Quiddity (talk) 02:23, 6 July 2013 (UTC)[reply]
  • Today's motto is "His ignorance is encyclopedic." I'd rather not have that on the front page. Shii (tock) 11:20, 7 July 2013 (UTC)[reply]
  • Oppose as political landmine: It is too dangerous to post an MOTD (msg of the day) on a million-user system. I once managed a U.S. Federal Government computer system, with visibility to the agency headquarters in Washington, D.C. and the MOTD became a nightmare when one day, I quoted a contemporary black female politician, so the MOTD was permanently shutdown. That system had less than 500 users, but the visibility for high-ranking U.S. officials created the atmosphere of propaganda messages, rather than just a variety of daily quotations. MOTD is too dangerous. -Wikid77 (talk) 19:52, 10 July 2013 (UTC)[reply]
  • Oppose This will only cause trouble. Every second day the quote will come from a person controversial somewhere, and even though wiki isn't censored, I don't think we need the main page riling up editors. ★★RetroLord★★ 08:39, 12 July 2013 (UTC)[reply]

RFC proposing an adjustment to the governance of featured-article forums

Community input is welcome here. Tony (talk) 10:56, 7 July 2013 (UTC)[reply]

What is going on with WP:ITN/C?

I've been sending this link around to my non-Wikipedian friends and their reaction is uniformly bewildered. Can we look at the big picture here for just a second? No news editor anywhere in the world hesitated before putting this crash on the top of all the world's front pages, but Wikipedia has developed this really weird "consensus" process so that a passenger plane crash that causes Chinese tourists to die on the runway of an airport in one of the world's largest cities might not be important because it is "US-centric". No words.

Since the sole purpose of all the arguing at WP:ITN/C is to put a link on the front page for a week, maybe Wikipedia should rethink the benefits of devoting so much energy to this frivolous task and merge ITN with the more permanent P:CE, or else eliminate it entirely. I'm certain that is not going to happen because ITN is such a long-standing main page tradition, but holy crap, that discussion is nothing if not a cry for help. Shii (tock) 11:17, 7 July 2013 (UTC)[reply]

No comment on the specific issue at hand, but remember ITN is not a news ticker, in fact despite the name isn't really about the news per se so any considerations primarily based on what news editors would do is fairly flawed. Nil Einne (talk) 17:04, 7 July 2013 (UTC)[reply]


ITN/C is not a newsticker. ITN/C is not a news aggregator. Wikipedia is not Reuters, or Google Reader (God rest it's soul), or BBC News. Items are posted with consensus. I know very well - for I wear the scars - just how frustrating ITN/C can be. But the experience you've posted is one of many which could be argued for to-and-fro for months. It's not without faults, but it's not as bad as you're trying to paint doktorb wordsdeeds 18:47, 7 July 2013 (UTC)[reply]
Given that Wikipedia doesn't want to focus on breaking news coverage, and the opposition that many of the crime news items get when people edit them, has anyone considered refocusing ITN on major planned events of historical significance? No more air crashes and school shootings - rather, bills signed into law, treaties ratified, space flybys returning data = stuff that is no surprise, that people will have complete articles written about long before it is time to feature them?
I'm not saying I like that idea - I rather like focusing on top-of-the-news items and editing in everything right when it happens. But if we do that, and want to feature it, we should do it unapologetically, not half-heartedly. Wnt (talk) 21:51, 7 July 2013 (UTC)[reply]
Sorry, I can't find a policy page for ITN (which is itself concerning) so I have to ask here. If "in the news" is not meant to be news, what is it? When did it stop being news? Why do the guidelines for ITN still refer to "news blurbs"? Shii (tock) 03:20, 8 July 2013 (UTC)[reply]
  • ITN is for subjects which a) people are likely to be reading about in the news right now which b) have good Wikipedia articles we can point them to. That's about it. There are always difference of opinions as to how much weight to give to each of those criteria, but you'll notice that the very item you're complaining about not being posted got posted. People have opinions, and they express them. And then the right thing gets done anyways. Other that proposing that we silence people whose opinions the OP doesn't agree with, what is being proposed here? ITN didn't even get this one wrong from the OPs point of view, so what is the complaint about? --Jayron32 03:45, 8 July 2013 (UTC)[reply]
    • I'd like to clarify that the first point, while true, also should be to draw potential editors to a page that is in reasonably good shape, as to add useful and beneficial information, as with all other front page items. --MASEM (t) 04:28, 8 July 2013 (UTC)[reply]
    • I'm confused about the purpose of ITN/C and why discussions happen the way they do. If it's "for subjects which people are likely to be reading about in the news right now", why did a discussion arise about the newsworthiness of this item at all? I'm not bitching that a discussion didn't go my way, so there's no need to put obvious facts in bold. I'm saying something needs to be rethought here. The discussion illustrates a blatant distinction between the mind of a real newspaper editor and the mind of an ITN/C editor which is visible every day. Shii (tock) 04:38, 8 July 2013 (UTC)[reply]
      • Again, are people not allowed to express their opinions in Wikipedia discussions? --Jayron32 04:39, 8 July 2013 (UTC)[reply]
        • Do you seriously not understand what I'm talking about? Shii (tock) 04:41, 8 July 2013 (UTC)[reply]
          • You've complained about a thread at ITN/C. I can only imagine one of two problems 1) The thread did not end up with the result you believe was just and right. I interpret your comments to mean that you wanted the item posted, the item was actually posted, so that can't be your problem. 2) The other possible problem is that you disagree with the comments made by people who opposed the posting of the item. I'm unclear as to how the fact that you disagree with those people is an actionable issue. Well-meaning people have good faith differences of opinion. Which is why I am perplexed by what action you are seeking here, because we're not going to silence people from expressing unpopular opinions, and the item in question that you wanted posted, was in fact posted before you even started this here discussion. So perhaps you could restate, as plainly as possible, what action you are seeking because neither of the possible actions I read as deriving from your initial post make any sense to me. --Jayron32 04:51, 8 July 2013 (UTC)[reply]
            • I don't know how you could think I want to silence other users when I specifically started a discussion to solicit input from other users. I wrote in my initial post, "maybe Wikipedia should rethink the benefits of devoting so much energy to this frivolous task and merge ITN with the more permanent P:CE, or else eliminate it entirely". Despite this misunderstanding, the ensuing discussion has been fruitful for me and hopefully for other users as well. I have learned that ITN has unwritten guidelines, which you have helpfully explained, and that these guidelines are linked in some way to this neverending free-for-all competition to dominate a corner of the main page. In my own free time I also discovered the existence of the horrific page WT:ITN/R, where the importance of notable recurring events is collectively weighed. The rules of WP:RS and WP:V that help keep Wikipedia sane are of course irrelevant in such discussions and it is basically anarchy. Furthermore, none of this is helpful to building an encyclopedia, because no matter what consensus is decided on, every blurb vanishes after a week or so. All of this has cemented my belief that ITN should simply be shut down or drastically rethought. I hope this discussion continues. Shii (tock) 05:12, 8 July 2013 (UTC)[reply]
              • The guidelines are not unwritten. They are written very clearly at Wikipedia:ITN#Criteria. Your characterization of ITN seems to be completely your own invention, as I have no idea where it comes from. Like every section of the main page, there are discussions among Wikipedia users where items are nominated, discussions are weighed against the guidelines and criteria, and decisions are ultimately made. DYK does this at T:TDYK, Today's Featured Article does this at WP:TFAR, etc. I still am perplexed at your singling out of ITN as a location where decisions are made by discussion, nor do I understand why you believe that people should not discuss how an item is put on ITN (or DYK or TFA or OTD, etc.) Again, you've presented no evidence that WP:RS and WP:V aren't used, indeed, ITN is very restrictive in terms of its dependence on reliable sources and verifiability, and your assertion that they are not appears to me to be completely baseless. If you could point to some examples where you think ITN failed in some way, perhaps we could analyze those events, but your assertions seem to be, at this time, your own invention. --Jayron32 14:30, 9 July 2013 (UTC)[reply]

Relabel the "Edit source" tab so it reads "Edit wikitext"

(Note: I've been assured (see WP:VPT#Changing the labels on the "Edit" (VE) and "Edit source" tabs) that modifying the label on a tab isn't a problem, technically. (Moving tabs around is, and I'm not proposing that.)

Many moons ago, the "New section" tab at the top of talk and Wikipedia namespace pages had a much shorter label: "+". After much discussion (and a new gadget to maintain the "+" label for those who preferred it), "New section" became the default label. I want to propose a similar change for the "Edit source" tab, which is seen (now) on articlespace and userspace pages for (a) logged-in editors who (b) have not turned off VE via preferences and (c) are using a VE-supported browser (not Internet Explorer, for example).

I'm proposing this change because the label "edit source" is potentially confusing to many editors who don't realize they still have a choice - that the older user interface is still available. It's confusing because the word "source" (in "Edit source") sounds like "source code", which wikitext is not. "Source" is also the word used in Chrome (View > Developer > View source), in Firefox (Tools > Web Developer > Page Source), and in Safari (in the [optional] Develop menu, select Show Page Source), that gets someone to a view of the html underpinnings of a web page. But, as discussed at Help:HTML in wikitext, html and wikitext are not at all the same thing.

If it makes sense to stop using "Edit source", then why use "Edit wikitext" instead? The term "wikitext" isn't consistently used at Wikipedia; it's often called wiki markup. For example, see Help:Wiki markup. But as the wiki markup article says, "wikitext" and "wiki markup" are alternative names for the same thing. And "Edit wiki markup" sounds (to me) almost as confusing (unclear) as "Edit source". So I'm suggesting "Edit wikitext" as the label for this tab. -- John Broughton (♫♫) 03:54, 10 July 2013 (UTC)[reply]

  • I support this change. Makes sense. Killiondude (talk) 03:59, 10 July 2013 (UTC)[reply]
  • Comment. I agree with you John that "source" is somewhat problematic for all the reasons you mention. However, I'm not particularly convinced that the made up word "wikitext" is all that much better. Sure "wikitext" works well for experienced editors, but I assume most of those will figure things out either way (if they don't simply turn VE off). From the point of view of new users, my gut instinct is that "source" is actually marginally clearer. So, call me ambivalent on this suggestion. You are right though that the interface change is certainly possible from a technical standpoint. If we do make a change, then it is probably best to change both the tab at the top and the matching text that appears in the section edit links. Dragons flight (talk) 09:01, 10 July 2013 (UTC)[reply]
  • Comment. While I personally would like "Edit Wikitext" I'm afraid some new users might not understand what "Wikitext" actually is. At the same time I think "source" is not appropriate either for reasons given – much more approriate would be "Edit markup". But then again I'm afraid newbie also might not know what "markup" is. So probably it's best to keep "source" although not optimal. --Patrick87 (talk) 09:12, 10 July 2013 (UTC)[reply]
While I think over it I get to the conclusion that newbies who do not know what "markup" is probably shouldn't use the Wikitext editor anyway. Therefore "Edit markup" would be a suitable label I assume (if they don't know what it does they don't use it; if they know what it does they can use it). --Patrick87 (talk) 11:09, 10 July 2013 (UTC)[reply]
Yes, definitely. "Wikitext" is a specialty of Wikipedia – even a professional wouldn't know what it means the first time he visits Wikipedia! While "source" might not exactly describe what it's all about it is recognized even by newbies (they might think "ew, source code, better not mess with that" but is that bad in the end? Isn't it OK if newbies just go on with the VisualEditor? Do you want them to mess with Wikitext when they do not know what they are doing?
That's why I recommend "Edit markup" personally. It precisely describes what the button does, while being common enough to be directly understood by professionals and has probably more or less the same effect on newbies as "source". --Patrick87 (talk) 22:45, 10 July 2013 (UTC)[reply]
More than who understand "Edit wikitext", yes. --Yair rand (talk) 23:11, 10 July 2013 (UTC)[reply]
It's "edit source" currently, I think we can leave the code out anyway, can't we? Besides that, Wikitext is markup text, and not source code (unless you consider markup to be source code, too). --Patrick87 (talk) 23:01, 10 July 2013 (UTC)[reply]
I know that it's not the same thing, but it's close enough for people to have an idea of what will they find if they click there Cambalachero (talk) 01:21, 11 July 2013 (UTC)[reply]
For people who have an idea of what will they find if they click there we can use the correct terminology (therefore "markup"). For all others it probably doesn't matter. --Patrick87 (talk) 02:04, 11 July 2013 (UTC)[reply]

List VisualEditor glitches to beware

As you know, there has been massive resistance and horrors with the VisualEditor (VE). Technical experts are warning how, even with Preferences set to skip VE, it is still loaded in background as an "energy vampire" to slow the normal wikitext editor somewhat. Among the crazy text glitches inserted into pages, beware:

  • all kinds of spurious nowiki-tags, such as someone adds a blank space: <nowiki> here</nowiki>.
  • wikilinks chopped with prefix letters:  "C[[ommandant General]]"
  • wikilinks with nowiki-tag split as 2 links: "[[Toffee|<nowiki/>]][[toffee]]" to show one link: toffee.
  • wikilinks with no-wiki brackets: "[[Cricket (insect)|[[Cricket<nowiki>]]</nowiki>s]]" to show: [[Cricket (insect)|[[Cricket]]s]]

We need to keep a current "wp:VisualEditor list of glitches" to warn people about which glitches are not yet fixed, as problems to still beware. I think a Bot could be written to scan pages and auto-correct many bad wikilinks. Meanwhile, users can check Special:AbuseFilter/550 to show the latest garbled articles (perhaps 25 per hour, 600 pages per day?), but many are soon fixed when their authors see the mangled text:

http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550

Also, some articles get strange formats from the VisualEditor, but pass for normal, where a fix-it is not necessary. The most complaints seem to be about garbled wikilinks, which almost always need re-edits. Many senior admins think the wider deployment of the VisualEditor is unstoppable, into WP discussion pages next, as an intense mandate from WMF. So, editing of all pages would get slower until the "remove VE" option really omits VE, rather than load it into the background of the wikitext editor. Also, I confirmed how an erstwhile change to the same page, even of one word (anywhere), will crash an entire VisualEditor session (losing all changes), rather than merge the one changed word into the new keystrokes. People are advising to tell friends (or anyone) not to use VE yet. More later. -Wikid77 (talk) 07:46, 10 July 2013 (UTC)[reply]

Kumioko was evidently thinking along similar lines and has set up Wikipedia:VisualEditor/Known problems. I'm sure more input would be welcomed there. As a "senior admin" myself - although I don't believe in such distinctions - and a software developer by trade, I think this rollout has been absolutely appalling in every respect. — Scott • talk 11:49, 10 July 2013 (UTC)[reply]
On the issue of the "energy vampire": VE is now responsible for about 2% of what gets loaded when you read an article. NB that this number was calculated before the appearance of the Universal Language Selector, so it's probably less than 2% now. Whatamidoing (WMF) (talk) 17:53, 10 July 2013 (UTC)[reply]
  • Another unexpected "feature" of VisualEditor is that it does not show comments. A lot of articles use to remind editors not to add rumours or unsourced info to articles; I just added such a comment to Artpop#Recorded tracks. If editors using VE don't see it, they're put at peril for a block over a comment they didn't see. —C.Fred (talk) 16:41, 12 July 2013 (UTC)[reply]

Let's merge the idea lab to this pump.

The idea lab village pump is underused, and really insufficiently distinguished from this one to merit being a separate discussion area. The way in which this one and that differ is very ill-defined, and potentially confusing to new users (would they really want to "incubate" an idea?); so I strongly recommend that we "keep it simple, stupid!" and reduce the number of places for people to propose and discuss ideas for the site to just one. The traffic level at the idea lab is low enough that bringing it here won't make this page unusably busy.

Also, "The Four Pumps" sounds like a Motown quartet. That's not really a formal benefit, I just thought I'd mention it. — Scott • talk 12:22, 10 July 2013 (UTC)[reply]

  • Proposals are plausible but Idea Lab is for dream features: This pump, wp:PROPS, is mainly for tangible improvements, with many easy to implement, while wp:VPIL allows for blue-sky dreaming, with some dreams realized here when more details are finalized. However, we want to keep the separation, to allow wp:VPIL to discuss a radical new concept for months, if needed, without being auto-archived in the rampant foot traffic of the numerous proposals here in wp:PROPS. -Wikid77 19:38, 10 July 2013 (UTC)[reply]
  • Oppose. VPR and VPI should be kept separate. VPI is good for developing ideas through input from other editors, but if no judgement of whether the proposal is to be approved or rejected by the community is sought yet. VPR is where the community expresses whether they approve or reject a proposal. -- Toshio Yamaguchi 21:19, 10 July 2013 (UTC)[reply]
    • I've seen a lot of things get posted to VPI that would have made perfect sense to be posted here. They're usually barely commented-upon and then vanish into the archives forever. I've also seen posts on here get the kind of discussion that's apparently intended for posts over there. The separation is entirely artificial, inconsistent, and pointless. — Scott • talk 12:17, 12 July 2013 (UTC)[reply]
  • Support: Scott does have a valid point. The descriptions for the two pages have a lot of overlap, and the criteria for choosing one or the other is somewhat vague. It might be better to have separate pages based upon the scale or scope of the proposal—one for easy to implement ideas and the other for major projects. Praemonitus (talk) 15:11, 13 July 2013 (UTC)[reply]

Replace the term "transclusion" in VisualEditor

"Transclusion" is a unfamiliar word for most people, so much so that Dictionary.com and the Oxford English Dictionary don't even recognize it as a word. As a result, such terminology will be hard on new users and is a poor choice for labeling the template features in the Visual Editor. Several people have already complained about the use of the word "transclusion" in the Visual Editor. In addition, most of our template related help pages have names like Help:Template, Help:A quick guide to templates, WP:Template messages, not to mention that the namespace is called "Template:" (though WP:Transclusion does also exist).

Given this, I would propose replacing "Transclusion" on the Visual Editor template button and on the title of the template editing dialog with "Template Editor".

"Template Editor" is still somewhat opaque, but "Template" is a real word and most of our documentation is already written in reference to "Templates", so I believe this is an improvement. Of course if anyone has an even better suggestion, then now would be a good time to offer them. Dragons flight (talk) 16:43, 10 July 2013 (UTC)[reply]

This is actually already in bugzilla, and is something I'd like to see fixed at the dev end. Even if we fix it on enwiki, it will still be confusing on our other ~270 wikis. Okeyes (WMF) (talk) 18:00, 10 July 2013 (UTC)[reply]
The devs are free to fix it when they get to it, but that doesn't mean we can't fix it first. I'm perfectly happy to recommend any change we make here as a role model for the devs, but I don't expect (and honestly wouldn't want) the devs to be spending much time right now worrying about labels given the very large backlog of bugs and missing features. Dragons flight (talk) 18:10, 10 July 2013 (UTC)[reply]
  • I'm not so sure about "Template Editor". It sound's a bit like you will be editing the actual template rather than just filling in the parameters, and people might be scared of that. But I agree that "transclusion" is bad, and my spell checker agrees, too. — HHHIPPO 21:29, 10 July 2013 (UTC)[reply]
  • See mw:VisualEditor talk:Template test for some background as to why it is called "transclusion editor". Calling it "template editor" might be OK, but it needs to be made clear that it does more than just edit a single template at a time. — This, that and the other (talk) 01:19, 11 July 2013 (UTC)[reply]
  • Why can't the button just say something like "Fill out template" or even "parameters"? I think that would be much easier to understand. I've been around here far too long and it took me awhile to realize what the "transclusion" button meant. Keilana|Parlez ici 04:27, 11 July 2013 (UTC)[reply]
  • Insert Template should be the tooltip of the button (and the title of the resulting window). --Patrick87 (talk) 08:52, 11 July 2013 (UTC)[reply]
    The same tooltip is used on the hovering button that opens the template editing dialog for existing templates. In that circumstance, "insert" isn't a great choice. Dragons flight (talk)
    I see. In this second case I'd vote for "Edit Template" or (regarding concerns above this might indicate one was editing the template itself) "Edit template parameters". The most precise term would probably be "Edit template transclusion", maybe this works as well, since it mentions "template", so on understands it also when one doesn't know what transclusion is. --Patrick87 (talk) 15:42, 11 July 2013 (UTC)[reply]
  • Strong Support. It should be labeled as "Add template..." or "Insert template...". My complaint was originally here. -- SnoFox(t|c) 17:57, 11 July 2013 (UTC)[reply]
  • Let's just do it. When the "transclusion" dialog box opens, it includes a "Remove template" button. (Why the text is in red is unclear; why this doesn't say "Delete" rather than "Remove" is also unclear .. but I digress). So the developers already are using the word "template" to indicate what is happening. (Apparently they couldn't bring themselves to label the button "Remove transclusion".)
    • Yes, "Edit template" isn't 100% perfect, but it's way better than what is in place now. We have consensus on that, at least. Based on that consensus, someone should make the change; there is always the opportunity to build a consensus around something even better, if that something exists. And we'll send a strong suggestion to the developers that they should change it officially before people start preparing translations for the other 270+ language Wikipedias. -- John Broughton (♫♫) 00:08, 12 July 2013 (UTC)[reply]
      • @John Broughton: "Before"? You do realise that this software is live on all Wikipedias right now, and has been being translated for months, right? Engagement earlier in the process would have been nicer. :-) Any decision made now doesn't need to be rushed on the grounds of making life easier for translators - it's the changing that's the burden. Rushing to a judgement now and then changing it again increases, not decreases, the load on our volunteers. Jdforrester (WMF) (talk) 02:04, 12 July 2013 (UTC)[reply]
  • We're actually mid-discussion about replacing this right now inside the team; the problem is that we don't have a good term for either "block of things, some of which are content transcluded from somewhere else, some of which are not" ("transclusion" in the current interface) or "thing inside said block, which is either content transcluded from somewhere else, or a code block that generates some output" ("template" in the current interface). We don't think the term "template" is right for either of these items, and though "transclusion" is more correct for the second we're not keen on it either. We'd really like to remove these terms entirely and call them something that's obvious to users, but, stumped for ideas, we've yet to find something that works. What do you think we should use? Jdforrester (WMF) (talk) 02:01, 12 July 2013 (UTC)[reply]
    Sorry, but what's wrong with "Template"? Templates are what usually get's transcluded. Sure, people can transclude almost everything, e.g. whole pages, but then again that's not how transclusions are normally used. Also I don't think we should even encourage editors to transclude anything other than templates from "Template" namespace (this is surely useful, but only if one knows what one does, and then the label shouldn't be an issue anyway).
    While "Transclusion" might be the most correct term we probably shouldn't use it at all. It's not an English word and probably nobody new to Wikipedia knows what it means. That said, it's great that Wikipedia has such a unique feature as template transclusion which was even given an unique name, and we achieved to make the word "transclusion" known to Wikipedians. So maybe we can even make it more commonly known by promoting it wherever we can.
    Personally I'd not risk a feature not understandable for newbies though and I'd totally go for "Insert template" for the new template button in the toolbar and "Edit template transclusion" for the edit template button when highlighting an already present template. --Patrick87 (talk) 08:36, 12 July 2013 (UTC)[reply]
    Strictly speaking "transclusion" isn't new to Wikipedia. The concept of transclusion has been used in computer science contexts (mostly around web and HTML type things) since before Wikipedia existed, but it is still very much a bit of specialist jargon. Dragons flight (talk) 16:20, 12 July 2013 (UTC)[reply]
  • Re-label "Transclusion" as "Template/Insert" to denote both: The other "Template" button might suffice, but soon rename the "Transclusion" button as "Template/Insert" to indicate access to both templates and other insertions. I just cannot think of an easier label, as also perhaps in German, "Vorlage/Einsatz" or French "Modele/Inséré" or Swedish "Mall/Infoga" or Spanish "Plantilla/insertar" (or "/Poner"?). Thanks for working this issue so quickly. -Wikid77 (talk) 05:34, 12 July 2013 (UTC)[reply]
  • @Patrick87, Dragons flight, and Wikid77: I don't think "template" is remotely obvious to a new user either. "Generated content block" isn't great, though. :-) "Gadget" would be the nicest one, but that's taken; "widget" isn't terrible, but it doesn't feel good enough to introduce as wholly-new language (and is possibly a little too scary/techy for people to discover naturally). Jdforrester (WMF) (talk) 16:28, 12 July 2013 (UTC)[reply]
    I agree that "Template" is also jargon (though jargon based on a word many people will know), but it has the distinct advantage that "template" is the descriptive term widely used through-out our existing help documentation and interface. In the absence of some clearer phrase, I think it makes sense to fall back on the widely used terminology. "Widget" falls down, in my opinion, for much the same reason as "transclusion". It's novel terminology that isn't going to be either clear or widely used in documentation. That said, the point made above that we don't necessarily have to be so economical with space in dialog box headers and tooltips is a good one. Things like "Template parameter editor", "add / edit template parameters", "add / edit content block from preformatted template(s)" and other long phrases could be used if there is some phrase that might provide more clarity. I'm not sure what the answer is, but I do think "template" is a better choice of terminology than "transclusion" or "widget". Dragons flight (talk) 16:42, 12 July 2013 (UTC)[reply]
    @Wikid77: totally unrelated, but in French the verb part would probably be "insérer", not its past participle :P Œuf corse, we should leave the translations to native speakers on translatewiki.net. πr2 (t • c) 04:00, 13 July 2013 (UTC)[reply]

Wikipedia:VisualEditor/RFC

Please participate in the VisualEditor Request for comment. Adam Cuerden (talk) 23:17, 10 July 2013 (UTC)[reply]

Desysop / reconfirmation RfA proposal

I've seen the discussion on the bureaucrats' noticeboard regarding a bureaucrat-led desysopping process, and I thought I would take a break from my break to offer a concrete proposal that I hope addresses some of the frustrations the community has about administrator accountability without encouraging an "open season" on administrators who have to make difficult and sometimes unpopular decisions.

Here is my idea for a 'crat-led "simple desysop" process:

  1. Any active bureaucrat can select an administrator for a reconfirmation RfA if they are persuaded that a "vote of confidence" by the community is needed to ensure that the administrator retains the trust of their fellow editors.
  2. If selected, the administrator will be asked to run a reconfirmation RfA within one month. If they decline to do so, a bureaucrat will remove their sysop flag, which they may regain in the future through a successful RfA.
  3. At the reconfirmation RfA, the selected administrator will need to gain the support of a simple majority of their colleagues, although the closing bureaucrat will be given discretion to discount bad faith supports or opposes. If the reconfirmation RfA is unsuccessful, the closing bureaucrat will remove the administrator's sysop flag.
  4. If any community member (including the administrator in question) objects to the close, they may appeal to ArbCom, who will decide whether the close was a reasonable exercise of bureaucrat discretion.

To ensure the integrity of the process, these safeguards would be included:

  1. An administrator may only be selected for a reconfirmation RfA once. If they pass the reconfirmation RfA, any future concerns about that admin's conduct must be handled through the existing processes (RfC/user and ArbCom.)
  2. Each individual bureaucrat may only make 3 reconfirmation selections in a calendar year.
  3. The bureaucrat who selects a candidate for reconfirmation cannot close that reconfirmation RfA.
  4. If no bureaucrat feels a reconfirmation RfA is warranted, the community retains the right to use the existing processes (RfC/user and ArbCom) to address administrator conduct.
  5. If the bureaucrat corps in general is slow to select administrators for reconfirmation, the community is free to nominate for bureaucratship (via the existing RfB process) any editors they feel would be more (or less) willing to select administrators for reconfirmation RfAs.

I think this proposal strikes the right balance between (on one hand) the community's legitimate desire to hold administrators accountable for poor conduct or decision-making without long, tedious ArbCom cases and (on the other hand) administrators' legitimate desire not to be subject to constant, frivolous "recall"-like processes that sap everyone's time and energy and encourage drama and pitchforks. 28bytes (talk) 15:53, 13 July 2013 (UTC)[reply]

Discussion

  • Questions - 1. Why does your proposal place the power to call a no confidence vote in a single Crat (seems pretty powerful, as is, as it will be essentially a no confidence vote by that Crat that starts the process)?
2. Are there standard criteria for the each Crat to apply in calling the vote?
3. Would there be a "call for the question [of a n/c vote]"/petition process by others to bring to the Crat's? Thanks. Alanscottwalker (talk) 16:08, 13 July 2013 (UTC)[reply]
    • My thinking was there should be some quick way of getting the process started, and that bureaucrats would not tend to make such selections frivolously, especially as they would only be able to make three selections per year (safeguard #2.) And if they do make a frivolous selection, the community gets the chance to say so by retaining the selected administrator in the reconfirmation RfA; that administrator would then be insulated against any additional selections for the rest of his or her career (safeguard #1). But as I commented to AlanBbb23 below, a two-crat trigger sounds like a good compromise. 28bytes (talk) 16:47, 13 July 2013 (UTC)[reply]
  • I didn't have any formal criteria in mind; rather, the editor(s) who felt an administrator should run for reconfirmation would need to make their case for why the administrator is not meeting the standards the community expects. Reasons could be a refusal to answer reasonable queries about their admin actions (per WP:ADMINACCT), a large number of admin actions that were overturned by the community (e.g. poor blocks), noticeable WP:BATTLEGROUND behavior (e.g. picking fights with other editors, nursing grudges, etc.) 28bytes (talk) 17:25, 13 July 2013 (UTC)[reply]
  • Strong Support this is best proposal yet and we've simply got to do something about the sordid mess we're in. Hopefully 28bytes can come up with an RFA equivalent. PumpkinSky talk 16:11, 13 July 2013 (UTC)[reply]
  • Support — Ched :  ?  16:14, 13 July 2013 (UTC)[reply]
  • Comment. I agree with PS that this is best proposal yet, or at least the best I've seen. However, I'll reserve support or opposition until I decide whether any proposal is needed, whether I can support the final proposal, and whether the change will eliminate the rancor among some members of the community. Here are my tentative comments:
    • Along the lines of what Alan said, I would prefer two crats select an admin for reconfirmation, not just one. There wouldn't have to be a consensus among the crats, just a minimum of two who agree it's needed.
    • Only auto-confirmed users may vote at a reconfirmation RfA.
    • If an administrator objects to a negative close and they choose to appeal to ArbCom, their sysop flag will not be removed pending a decision by ArbCom, and ArbCom will handle the appeal on an expedited basis.
    • A crat may select for reconfirmation only two admins per year, not three.
    • Number 5 in the second box is unnecessary and should be struck.
    • --Bbb23 (talk) 16:31, 13 July 2013 (UTC)[reply]
  • Those all seem like reasonable amendments to me. The two-crat rule in particular makes sense, as it's important to strike a balance between not concentrating power in the hands of one person vs. not devolving into a death-by-committee situation where nothing gets ever done. 28bytes (talk) 16:47, 13 July 2013 (UTC)[reply]
  • Support preferably as modified by Bbb23. I would add to it that the same two crats can act together only once in a calendar year. Normal rules of conflict of interest to apply as regards the nominating crats and the admin. And no admin shall be subject to this within a year of election, or within six months of being subjected to action by ArbCom (time to find feet, time to reform).--Wehwalt (talk) 16:34, 13 July 2013 (UTC)[reply]
  • Support with two Crats modification. Maybe some minor tweaks to how many times, how many times the two can act together, etc. Needs more thought, but this is a reasonable basis to start a change. I strongly support the simple majority rule, which I think will compensate for previously blocked "haters" piling on. Hopefully this would be a rare event, but just having it available can restore faith in the community re: admin accountability. Dennis Brown | 2¢ | WER 16:56, 13 July 2013 (UTC)[reply]
  • Support. At this point, I do not see how this proposal can harm if accepted, however some modifications are desirable (Bbb23's suggestions are a good starting point).--Ymblanter (talk) 17:06, 13 July 2013 (UTC)[reply]
  • Perhaps if private info is involved (say CU or OS info), ArbCom should continue to handle it? --Rschen7754 17:09, 13 July 2013 (UTC)[reply]
  • Support: There needs to be an organized and logical system to do this, as opposed to random mobs with pitchforks and torches. Montanabw(talk) 00:41, 14 July 2013 (UTC)[reply]
  • Oppose this proposal isn't really much different from the failed WP:CDA proposal from a few years ago, except the acceptance requirement has been changed from 10 editors in good standing to one bureaucrat, and the success threshold is much lower. Bureaucrats aren't selected for this situation, of course. The problem with reverse-RfA desysopping proposals is that admins who do work in controversial areas tend to make enemies, even if the work they do is great, and that those enemies will vote against them in an RfA. This will, in turn, reduce the number of admins prepared to get involved in controversial areas, exacerbating a problem we have already. The fact that this proposal has come from angry protests over a block of an editor who has plenty of sympathisers prepared to make noise on their behalf is not encouraging in this respect, as those sympathisers would doubtless love to use this process to get revenge on the blocking admin. RfA is not generally considered to do a very good job of selecting new admins, so it's difficult to justify using it on existing ones, especially ones who have done something controversial recently. The proposal seems to require that only admins can vote in recall RfAs, or that only their votes will be counted, which isn't going to inspire much confidence in the results. Hut 8.5 18:16, 13 July 2013 (UTC)[reply]
  • Support, with the two-crat threshold for the initiation of the process. In response to Hut 8.5, I would expect the two bureaucrats to use good judgement -- and not call for a desysopping discussion solely on the basis of unpopular actions in controversial areas. --Orlady (talk) 18:48, 13 July 2013 (UTC)[reply]
  • The criterion for a bureaucrat to open a reconfirmation doesn't say about what the admin is supposed to have done, only that there is some perceived need for a reconfirmation. Hut 8.5 19:20, 13 July 2013 (UTC)[reply]
  1. I would instead of one bureaucrat a maximum of three times, say three crats acting together. Those crats cannot act in combination more than once in a calendar year but may join with other combinations of crats. Normal rules of conflict of interest apply.
  2. Crats who have not used their powers significantly (either closed an RfA or done some quantity of other work) in a given time period may not act at all, let's say one year.
  3. No admin shall be subject to this within one year of election, or within six months after being the subject of action by the Arbitration Committee (i.e., no double jeopardy). PumpkinSky talk 18:44, 13 July 2013 (UTC)[reply]
Let's say … a subpage of WP:BN?--Wehwalt (talk) 20:45, 13 July 2013 (UTC)[reply]
Yes that makes sense—leaving it unsaid does not, IMO :) John Cline (talk) 21:31, 13 July 2013 (UTC)[reply]
  • I have been saying for years that Community de-adminship is a must-have feature, and this is an interesting idea. What strikes me as notable is the nomination process by bureaucrats, and the fact that 'crats were not elected to do this type of work and have answered no questions about it, etc. Since the role of the bureaucrat or bureaucrats is larger than it was in the failed 2010 Cda proposal, and since I have not seen any of that membergroup go on record as for or against such responsibilities, I will poll them on their board. If they aren't in favor, this proposal is moot. Jusdafax 21:35, 13 July 2013 (UTC)[reply]
  • A question and modification: First, do you propose any sort of unit of measure to determine if a reconfirmation RFA is warranted, or is this pretty much based on the whims of the one or two crats? Second, and in the interest of protecting admins from harassment via this process, I would suggest that no admin should be forced through this process more than once in a specific and long period of time - I'd say three years or even longer, or even only once for any admin. Nobody should be forced to run the gauntlet repeatedly until certain elements bully their hated admin off Wikipedia. Any further concerns within the 'protected' time frame should be directed to arbcom. Resolute 23:59, 13 July 2013 (UTC)[reply]
    • Additionally, how do you expect the reconfirmation vote to work? Since he individual in the prisoner's box is already an admin, it is the votes opposing continued adminship that matters, rather than overall support. Would be be a simply 50%+1 vote? Resolute 00:05, 14 July 2013 (UTC)[reply]
      • Striking most as these concerns were already addressed in the proposal. I read it, but my utter failure to have it stick in my mind was just pointed out to me. Resolute 02:20, 14 July 2013 (UTC)[reply]
  • Support per Bbb23. Andreas JN466 00:52, 14 July 2013 (UTC)[reply]
  • An important point has been raised at the 'crat noticeboard in the comment section of the poll I have added. Not only should the 'crats approve this proposal to expand their Bureaucrat rights, the Wikipedia community at large should be asked to approve this concept as well, which I imagine would involve a Wiki-wide Rfc. Jusdafax 01:29, 14 July 2013 (UTC)[reply]
    • That's a good idea, Jusdafax, and I expect that will be the next step, after people are done finalising the wording and have confirmed the 'crats are interested in taking on the task. -- Diannaa (talk) 02:16, 14 July 2013 (UTC)[reply]
  • Strong support yes, probably the best idea I have seen yet. AutomaticStrikeout  ?  03:22, 14 July 2013 (UTC)[reply]
  • Support. Anything to change the current system. Too many entrenched power players. Minor tweak would be to make the revote same percentage as normal. But I'll take anything...TCO (talk) 05:35, 14 July 2013 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=564186963"