Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

New ideas and proposals are discussed here. Before submitting:

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

« Archives, 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, 213, 214, 215

Main Page redesign

Screw process, I'm going all-in. I spent over a year working on it, and now I feel it is finished and ready to deploy.

Visually more of a restyle then a redesign, most of the changes are under the skin: the entire page is competely fluid, so it adapts to any screenwidth. There is not a single table in the code, all divs. There are some modern features, but none are detrimental to old browsers.

I'm looking for people who want to participate with ideas for functionality and design, bugs, and coding. Test it out on everything you have, resize you browsers, abuse it. Then say Yes or No. Simple as that. Then answer: do you want to build further on this design? Questions and constructive feedback always welcome. — Edokter (talk) — 15:20, 8 March 2014 (UTC)

Main Page

Discussion/Comments

Moved from "No", due to the question's modification. —David Levy 13:41, 9 March 2014 (UTC)

• I'm impressed, but I disagree that this is "ready to deploy" and dislike this proposal's binary format. In my opinion, this design is off to a very promising start, but it could use some collaborative tweaking. —David Levy 15:42, 8 March 2014 (UTC)

  Tried that. I can't seem to get people interested in collaborating. — Edokter (talk) — 16:13, 8 March 2014 (UTC)

  Let's try again. —David Levy 16:17, 8 March 2014 (UTC)

  Isn't that what the comments/discussion section above is for? You say that you are impressed, and that it is just not ready (which implies with a few tweeks you would say yes). I feel the same which is why I'm reserving judgment pending discussion and collaborating above. ;) — {{U|Technical 13}} ^{(t • e • c)} 16:22, 8 March 2014 (UTC)

  I feel that more than a few tweaks are needed. As the choices are "yes" (the design "is finished and ready to deploy") and "no" (it isn't), the latter is the appropriate response. —David Levy 16:35, 8 March 2014 (UTC)

  I see, Discussion/Comments is just above Yes. The choices I see are: Discussion/Comments (not ready, please fix "X", "Y", and "Z"); Yes (it's ready, deploy it now); No (there's nothing you can do to fix it, I don't ever want to see it deployed). /me wanders away mumbling to hisself. — {{U|Technical 13}} ^{(t • e • c)} 16:56, 8 March 2014 (UTC)

  Given the context, I disagree that "no" means "there's nothing you can do to fix it". The question is simply whether the design is ready for immediate deployment (and my response is "no, it isn't").

  I also believe that more work is needed than can be carried out in the "Discussion/Comments" section. (I don't regard this as a "fix X, Y and Z and it'll be good to go" situation.) I see this as a solid proof of concept with technical merit, but I'm not sure about the specific implementation (layout, coloration, etc.). —David Levy 17:31, 8 March 2014 (UTC)

  Please tell me your concerns. The main problem is lack of feedback. Fixed one bug already, so yes, I may have been a bit brisk. I crave input; it is the only way to move formward. — Edokter (talk) — 17:11, 8 March 2014 (UTC)

  My main concern is that more discussion and experimentation are needed. It isn't a matter of elements being objectively broken, but one of room for aesthetic improvement. I don't think that it would be helpful for me to list my personal opinions regarding the colors, gradients and such (with which others are bound to disagree). I think that we need to sandbox some variants (including alternative layouts) and see what clicks. —David Levy 17:31, 8 March 2014 (UTC)

  But it is exactly that reason why this keeps failing; not giving your opinion. I Have no problem with multiple implementations, but no one else is stepping up producing them, and there is only so much I can do. — Edokter (talk) — 17:43, 8 March 2014 (UTC)

  I realize that. To be clear, I overlooked your previous attempts to solicit feedback, so I'm seeing this for the first time today. I would like to experiment with some variations (and I hope that others can be persuaded to participate in the process). —David Levy 18:01, 8 March 2014 (UTC)

• I don't want to say yes or no. I like the modernization, but there are a couple things that set me off about it.
  1. "Today's featured picture" image is way too large on my screen
     • It is more than three times the length of the accompanying blurb at 1320×825×24 (1.089 MegaPixels)
     • At 640×480 the blurb is 30% longer than the image
     • At 480×300 (mobile in desktop mode) the blurb is more than twice as long as the image, which doesn't fit on one screen.
  2. The "Wikipedia's sister projects" section is half the page because instead of filling in the entire box using multiple columns, it is a single column.^(screenshot)

• It shold have fallen back to floating divs. Removed columns for now. — Edokter (talk) — 16:08, 8 March 2014 (UTC)

• I'm using Firefox 27 in case it turns out to be a browser specific issue. — {{U|Technical 13}} ^{(t • e • c)} 16:19, 8 March 2014 (UTC)

• Weird. I could have sworn it worked on my Firefox 27. Columns are gone now. — Edokter (talk) — 17:54, 8 March 2014 (UTC)

It also throws me as odd that "Today's feature picture is looking left from the left side of the screen away from her blurb like she is saying get me the heck out of here. — {{U|Technical 13}} ^{(t • e • c)} 15:41, 8 March 2014 (UTC)

POTD shows no different then on the current main page; I have no control over that. — Edokter (talk) — 16:05, 8 March 2014 (UTC)

• I like the overall look of it but I feel there is a bit too much whitespace if two of the 'boxes' don't have the same height. For example, there is quite a bit of space below the Did you know box, because the Be an editor box is a bit higher. Also, I think the vertical spaces between adjacent boxes should be reduced (for example between the In the news and On this day boxes), as I find the vertical space more distracting than the horizontal space. Apart from that I feel the overall increased space between the boxes helps uncluttering the page a bit, which is good. -- Toshio Yamaguchi 15:43, 8 March 2014 (UTC)
  • Boxes should be equal height, but your browser may not support flexboxes. What is your browser? — Edokter (talk) — 16:10, 8 March 2014 (UTC)
    • @Edokter: I am using Safari for Windows. -- Toshio Yamaguchi 20:47, 9 March 2014 (UTC)
      • That's basically Webkit. If you have a recent version, you should see equal-height boxes. — Edokter (talk) — 20:51, 9 March 2014 (UTC)

• Works fairly nicely in Mercury on iPhone 4. Easier to read and use than current page. Not keen on the extended blurb in the box at the top of the page. Also, in my experience the only way I've personally seen effective changes to something like the Main Page was a small discussion with someone who actually coded stuff together, followed by boldly implementing it after the small group egged an admin into doing it, followed by tweaking based on the ensuing discussion that only happened after the change. Collaborative, yes, but it isn't reasonable to go for full community involvement, especially since most editors won't care enough to engage properly with the process. 86.161.109.226 (talk) 19:34, 8 March 2014 (UTC)

  The most recent successful main page redesign (in 2006) involved collaboration among a small number of editors, followed by a poll with nearly 1,000 participants. —David Levy 20:13, 8 March 2014 (UTC)

  And I would seriously love that to happen again. Really. But people can't just wait around for a mandate before doing this stuff: it has to look like it's actually happening. This is no longer the community where, for example, a load of editors would just share out archiving large talk pages regularly, even ip editors, and manually create archive pages because they needed doing. This is a community where most editors now expect grunt work and administrative tasks to be done by bots and some nebulous 'others': I just don't see people jumping in to these tasks in the way they used to. I suspect a large portion of the community is under the impression that the Main Page is some foundation responsibility, and outside their purvue: but this is just my impression. I would love to be proved wrong by an enthusiastic and productive response. 86.161.109.226 (talk) 21:49, 8 March 2014 (UTC)

  Several redesign attempts have been made since then, attracting significant interest but ultimately fizzling. These failures are attributable to various factors, but I believe that the single greatest problem has been a lack of focus. Everyone involved wanted to improve the main page, but there was no agreement on how to go about it. So instead of actually collaborating, individual participants arbitrarily cobbled together "drafts" reflecting their personal preferences (not actual goals identified by the community), most of which were vastly inferior to the current main page.
  Things were simpler in 2006, when it took very little to spice up the page's incredibly plain design. And while its successor seems technically outdated, a worthwhile update requires a level of coding expertise that most of us lack. I regard Edokter as one of the few Wikipedians up to the task. But collaboration (ideally with Edokter's work as a reference design and his direct involvement throughout the process) remains essential. —David Levy 22:31, 8 March 2014 (UTC)

  I would be surprised if you could actually get a meaningful set of "actual goals identified by the community". The community here is very diverse and does not agree on whats ideal for that page. For example, we know from prior discussions that some people want to showcase only the best work, and others insist that it must include pages that a good-faith newbie could likely improve. You can't have it both ways. I've no objection to you trying to lead such a discussion, of course, but I think it is doomed to producing "no consensus" on anything that is concrete, measurable, and realistic. (Consensus can be had on glittering generalities, but that's not pointful.) WhatamIdoing (talk) 21:33, 9 March 2014 (UTC)

  Any attempt to rework the main page's encyclopedic content en masse is doomed to failure. For the most part, we can only hope to improve its technical performance and aesthetics. Edokter evidently realizes this. —David Levy 22:09, 9 March 2014 (UTC)

• I really like the changes to the content ("Become and editor" box and the little blurb in the "Welcome to Wikipedia" box; everything in boxes), but honestly, I like the original color scheme better. Is it possible to have a way to change back to the old one while still keeping the new content and layout? Supernerd11 :D Firemind ^_^ Pokedex 21:44, 8 March 2014 (UTC)

• I like that Edokter (talk) has gotten the ball rolling. This is, at least, something we can start with as a basis to build some community support / consensus from; and a very good start. GenQuest ^{"Talk to Me"} 22:57, 8 March 2014 (UTC)

• (edit conflict) I've taken a look on the latest versions of Firefox and Chrome for Windows, and Dolphin browser for Android, and it looks pretty good (to me) in all of them. The "Welcome to Wikipedia" box could stand to be a little smaller, I think, it tends to draw my eye more than the Featured Article box, which doesn't seem desirable. I noticed that the boxes don't all have the same vertical height on Dolphin, so mobile browsers may be less likely to support the flexboxes, but I'm not sure whether or not that's a big issue since there's a separate main page for the mobile site anyway. Novusuna ^talk 23:00, 8 March 2014 (UTC)

  We could probably use some input from editors familiar with accessibility and usability, as well. Novusuna ^talk 06:32, 9 March 2014 (UTC)

• Comments:
  1. Under many display settings, today's tall TFA image protrudes from the box (due to its reduced height), breaking the formatting of the two boxes below. (I believe that This, that and the other refers to this issue below. Note that it wasn't present with yesterday's image.)
  2. It seems that this poll is unclear. What, exactly, is the question being asked? I interpreted it as "Is this design 'finished and ready to deploy'?". If the intended question actually is "Do you like this design and wish to pursue its continued development?", I'll change my answer. —David Levy 05:18, 9 March 2014 (UTC)

  That was unexpected (I have a small screen). I've added overflow:hiden; to the boxes which should prevent such breakouts. — Edokter (talk) — 12:06, 9 March 2014 (UTC)

  Yes, that appears to have fixed it. —David Levy 13:41, 9 March 2014 (UTC)

• Looks good on a Samsung Chromebook, I like the fact that it doesn't use tables, and the symmetry is achieved with mirrors sets of different sized boxes. Overall, a vast improvement. --NickPenguin_(contribs) 06:10, 9 March 2014 (UTC)
• I agree with David Levy. This thread is asking for a simple approve or disapprove. Right now I can't approve of this as it changes things too much from the current consensus for sectioning. Changing the main page is hard....VERY hard and I think it is meant to be. Maybe harder than any other page on Wikipedia. Taken some time to accept this fact but yeah.....this seems to be attempting an end run around a lot of discussion.--Mark Miller (talk) 06:25, 9 March 2014 (UTC)

  I have adapted the question at the top. — Edokter (talk) — 12:06, 9 March 2014 (UTC)

  I've changed my response accordingly. —David Levy 13:41, 9 March 2014 (UTC)

My main concern is the orange and the black-on-color contrast, now that the main issues with the MP design have been resolved. The text is less readable than on the current main page, and I'm still somewhat concerned about the readability of text on the MP and clarity of which section is which (I thought ITN was DYK for a few moments before my eyes actually picked up the header.) In other words, I'd just like it to be highly readable, and, er, not use orange (or at least, use a soft shade of red or yellow if emphasizing featured content?). It rather clashes with the cool colors. Also, there isn't much emphasis on portals; slightly tweak it to do so, perhaps, in addition to these previous concerns? If these issues are resolved than I'll gladly support. Cloudchased (talk) 22:45, 9 March 2014 (UTC)

These are all details that need to be worked out, so don't get hung up on how it looks now. If this goes forward, each and every aspect of layout and styling will be adressed. — Edokter (talk) — 23:50, 9 March 2014 (UTC)

• Totally broken in NCSA Mosaic, but that's no surprise: the rest of Wikipedia is also totally broken. --Carnildo (talk) 08:55, 10 March 2014 (UTC)
  • You really should upgrade to IE6. — Edokter (talk) — 12:14, 10 March 2014 (UTC)

• One concern I have is over the "Today's featured picture" div. It has a red background whereas the current main page's section has a very light grayish/light purple background. When I compare the current main page to your main page, today's image dramatically changes in color perception (an overall reddish cast). The current main page seems to be rather good at not altering my color perception of photos. I think the red background itself is somewhat to blame as is the lighter heading. The current main page has a darker heading. Overall though, I think your design is nice. Whether it's better, I'd need to think about. Jason Quinn (talk) 03:56, 12 March 2014 (UTC)

• If my window (or at least content-pane) gets narrower than the "Today's featured picture" picture-set itself, the box does not get side-scrolling--annoying, but grudgingly acceptable that a single item too wide to display is not easily remedied. But the text in that box still lays out to the full width of the box, which is still that "wider than my window" width of the image-set, so the text is cropped on the right too--that's a real problem. I'm using firefox-8.0.1, the highest one that appears to support x11 (and therefore remote-display use) on OS X. DMacks (talk) 03:43, 22 March 2014 (UTC)

The current mainpage (whole page) becomes side-scrolly in this situation, as for other WP articles with content that have some hardcoded minimum-width or long-lines. DMacks (talk) 03:47, 22 March 2014 (UTC)

I have no control over the content that is transcluded to the main page, so some glitches will always remain (until POTD fixes it). Always check if the same problem occurs on the current main page as well. If so, nothing I can do. — Edokter (talk) — 12:53, 22 March 2014 (UTC)

Please read what I wrote carefully. I said the main page *does* work correctly, or at least is "as best compensated as possible" for wide content, as compared to actual breakage (the result of the template is mis-handled and made worse) in yours. Your div or whatever box magic needs to enable side-scrolling or grow itself wider if overflowed width for the size of the screen. DMacks (talk) 18:04, 22 March 2014 (UTC)

I think I fixed that now. — Edokter (talk) — 19:13, 22 March 2014 (UTC)

Looks fine even on my crappy browser. Thanks. DMacks (talk) 21:56, 22 March 2014 (UTC)

• Corners of the panels look a bit rigid. Perhaps we can apply a 0.2em border-radius to .mp-panel to make it look slightly better? Zhaofeng Li [talk... contribs...] 05:47, 7 April 2014 (UTC)

Comment on the process

Why are we having the discussion here, the village pump? We already have the redesign page so either we use it or merge it with 2013. I don't have a particular preference for the discussion, but trying to implement in a covert way is not democratical. Imagine someone commenting at the main "main page redesign" page without knowing there is some parallel discussion going. This is very problematic. (Personally I don't like the current main page design and so I don't like this one either.) -- Taku (talk) 13:43, 10 March 2014 (UTC)

It is here beause the 2014 redisign page is solely preoccupied with process, and nothing to do with the actual redisign, and therefor bound for failure. It also was not advertised in any way. The Village pump is hardly covert; it is the principle page to post proposals. I am trying to get a fluid process going that has collaboration at its core, using the outcome of the 2013 RFC as its guide, and my framework as a foundation. If you read the comments (also on the Main Page talk page), you will see that many people have identified "process-overload" as the main factor in these failures.

The 2014 is definitely not the main discussion regarding this proposal. That is why I removed it (twice). In due time, when this proposal has gained enough support, we will set up a new work area where those interested will collaborate to build a new page. So please do not link to that page again. — Edokter (talk) — 14:02, 10 March 2014 (UTC)

Yes

1. It apparently needs some tweaking for the all-browsers/all-screens issues, but I like it somewhat better than what we've got. Edokter certainly needs feedback and testing over multiple days and bug reports, but design-by-committee and WP:BIKEshedding is not going to help. WhatamIdoing (talk) 18:07, 8 March 2014 (UTC)

   A great deal of middle ground exists between design by committee and the complete absence of collaboration. Likewise, a great deal of middle ground exists between focusing endlessly on trivial details and not discussing details at all. —David Levy 18:24, 8 March 2014 (UTC)

   In design work, it's my experience that the you get better results if you tell a designer what you like and dislike, and let him (or her) deal with your feedback, rather than trying to have multiple people own a design. WhatamIdoing (talk) 21:36, 9 March 2014 (UTC)

   Hence my comment about the importance of relying on someone with coding expertise. All that's missing is the feedback (though not because Edokter hasn't sought it). —David Levy 22:09, 9 March 2014 (UTC)

   My own relatively minor design contributions to WP improved light years by asking for feedback, so this is certainly the right approach, for an important page. André437 (talk) 19:46, 5 April 2014 (UTC)

2. There's room for improvement ("Be an editor" should be visible without scrolling; in "Sister projects" the columns are a bit awkward), but it definitely beats the existing main page. -- Ypnypn (talk) 01:56, 9 March 2014 (UTC)
3. I'm not particularly taken with the colours... there is tan, blue, and purple, but no green-type shades. I'm also not too keen on having the FA stretch across the entire page: the long lines are not conducive to rapid reading. Also, with very large browser window sizes (or when zoomed out), the FA image can get in the way of the "In the news" section. But: nice use of media queries (the layout adjusts flexibly for narrow screens), and overall it looks really clean and reasonably modern. Nice work, Edokter! — This, that and the other (talk) 04:38, 9 March 2014 (UTC)

   I had briefly wondered if green had been avoided because of the problems it creates for people with red–green colorblindness. It can be a difficult color to maintain legibility with. WhatamIdoing (talk) 21:36, 9 March 2014 (UTC)

   I ditched the green because the amber/blue/violet seems easier on the eyes. I am trying to be somewhat innovative, but I lack the inspiration with regards to colors and box design. So this is definitely not a final design with regards to styling. But since the CSS for styling is not inline, we could have many different styles without actually having to edit the main page. It could potentially end up withno styling at all. — Edokter (talk) — 22:26, 9 March 2014 (UTC)

4. Given the question's modification, I've switched from "No" to "Yes". I do want to build further on this design. —David Levy 13:41, 9 March 2014 (UTC)
5. An overall improvement. Rehman 15:52, 9 March 2014 (UTC)
6. To answer the re-formed question, Yes, let's build further on the design as now presented. GenQuest ^{"Talk to Me"} 16:10, 9 March 2014 (UTC)
7. Definitely the right direction. Jackmcbarn (talk) 16:34, 9 March 2014 (UTC)
8. A big improvement on what we currently have, and probably the best thought out of all the redesign proposals I've seen. the wub "?!" 17:18, 9 March 2014 (UTC)
9. I'll admit I don't love the proposed design, but against the current Main Page, it'd win my vote 90–to–1. The div/id-based structure is also great, and allows restyling of the Main Page a lot more easily than now. Cloudchased (talk) 02:05, 10 March 2014 (UTC)
10. Colour me impressed. I like the layout. Styling could stand to be a bit more bold, but that should be easy to hash out. Edokter has done well and, I'm sure, will continue to improve. — Huntster (t @ c) 20:40, 10 March 2014 (UTC)
11. I rather like it. : ) Is there a mobile version? Philippe Beaudette, Wikimedia Foundation (talk) 08:56, 12 March 2014 (UTC)

    I've tried making it as mobile-friendly as possible. If you narrow the screen, all sections should be stacked automatically. (Though I have some trouble making Android behave here; it seems to ignore the @viewport directive.) — Edokter (talk) — 12:33, 12 March 2014 (UTC)

    I think i fixed it using the proper media queries. — Edokter (talk) — 20:59, 12 March 2014 (UTC)

    I don't see why this should be much of a consideration, seeing as there is a mobile-specific Main Page. — Pretzels 13:03, 13 March 2014 (UTC)

12. Well done! Still a bit bland, but knowing that style and layout are purely subjective matters, it will be nearly impossible to get a consensus on a radial different design. More incremental changes can be built on this design. -- P 1 9 9  ✉ 22:05, 14 March 2014 (UTC)
13. I love it. Love it, love it, love it. (Did i mention I love it?). Finally a Wikipedia home page that is worthy of the 2010s. Beautifully crafted @Edokter:. Major kudos.--Coin945 (talk) 07:37, 16 March 2014 (UTC)
14. I'm a fan--it's sleeker, less clunky, and more modern. I especially appreciate the "Be an editor!" area, which will hopefully attract new editors to our project. Well done. –Prototime (talk · contribs) 21:41, 25 March 2014 (UTC)
15. An overall improvement accessibility-wise and good framework to build on, though from my current view I would give just a little extra space from OTD to the ITN text. Maybe that's personal. SFB 18:13, 1 April 2014 (UTC)
16. A considerable improvement, especially in adapting to any page width. But like some other comments, I think that 2 sections wide (not counting the left margin) on normal width pages would be better for readability. (I just realized that my usual browser window was a bit too narrow to see any side-by-side sections. Maybe minwidth/maxwidth needs to be reduced a bit on some sections ?)

    The expanded "WIKIPEDIA" and renamed "Be an editor" sections are nice as well. Welcome improvements. André437 (talk) 19:46, 5 April 2014 (UTC)

17. I like this one would like to see it as the main page. To be an editor feature is a fine inclusion to encourage IPs and stop vandalism to much higher extent. The Herald 14:01, 7 April 2014 (UTC)
18. A massive improvement on the current layout. Dynamic, interesting, with better use of colour and typefaces. It also includes similar wide/narrow variations to the proposal on Talk:Main page, which could in theory be done first but it makes more sense to do them all at once and resolve bugs and issues in one go, rather than deal with two rounds of testing and discussion.--JohnBlackburne^words_deeds 01:19, 8 April 2014 (UTC)
19. This has the potential to be a vast improvement, especially with the new "Be an editor" section and other nice improvements to flexibility. I strongly support a motion to move forward and start working on this further. --Nicereddy (talk) 07:01, 13 April 2014 (UTC)

No

Not ready. See this screenshot, using Chromium 33.0.1750.146 on Arch Linux. The "Be an editor" box is also a little small; there's a gap between it and the DYK box. Cloudchased (talk) 15:30, 8 March 2014 (UTC)

Re screenshot: can be fixed. Do you have a screenshot of the 'gap'? — Edokter (talk) — 15:35, 8 March 2014 (UTC)

Both fixed now. Sister project icons no longer use columns, and the gap should be gone. — Edokter (talk) — 17:27, 8 March 2014 (UTC)

1. No, I simply don't like this style. The background colors, boxes and drop shadows are a relic of early-2000s-style graphic design and should be shunned. Good design allows the text fields to define the layout with the minimal possible decoration. —Designate (talk) 04:44, 9 March 2014 (UTC)

   You must really hate the current main page then... I'm open to ideas. Go ahead and make your own mockup; you'll see it is really hard to come up with a good design. — Edokter (talk) — 12:25, 9 March 2014 (UTC)

   I sure do. That's why good design is something you get paid for. —Designate (talk) 12:31, 9 March 2014 (UTC)

   I'm not getting paid, and I also don't have any money to pay. Would you none the less be interested in helping out? — Edokter (talk) — 13:27, 9 March 2014 (UTC)

2. No. Sorry but this is not how we make changes to the main page. But you have David Levy impressed and that is a great start. I am willing to collaborate on another attempt at the main page but very much agree with David that this isn't time to be asking for deployment.--Mark Miller (talk) 06:31, 9 March 2014 (UTC)

   How do we make changes then? All help is welcome. I changed the question and am calling for participants. — Edokter (talk) — 12:25, 9 March 2014 (UTC)

3. I'm glad something is happening and I commend Edokter for achieving that, but this isn't a significant enough improvement on what we already have. It still has a meaningless pastel colour scheme that clashes with the Vector skin 99% of users use, the proportions and spacing are inconsistent, and it's still a wall of text. — Pretzels 18:51, 11 March 2014 (UTC)

   This is certainly not the end result; most changes are 'under the skin', making the page fluid and allowing us to apply whatever style we want. It is more of an intermediate version between the HTML1 we have now and the CSS3 flexbox model that offers near-unimited flexibility in page layout. — Edokter (talk) — 20:33, 11 March 2014 (UTC)

4. I think this is visually a slight improvement on the existing page, but there really isn't enough difference. If we're going to change the Main Page (which is definitely overdue), let's do something a bit more exciting. 86.160.86.139 (talk) 03:12, 12 March 2014 (UTC)

   [No longer a vote] Only because I don't like the pastel shades. The layout is good, and I like the slightly raised look of the panels. — Scott • talk 14:00, 12 March 2014 (UTC)

   I'm confused as to why you regard this as a reason to cease further development, particularly given Edokter's explanation that style elements (including the colors used) are subject to change in accordance with consensus. —David Levy 15:55, 12 March 2014 (UTC)

   Huh. The question this section is asking has changed since I initially saw it. Should there be further work on this? Sure. I've unnumbered my vote, then. — Scott • talk 16:03, 12 March 2014 (UTC)

   A "no" purely on the grounds of not liking the pastel shades is simply WP:BIKESHEDding. Is there an addressable problem with these shades, such as WP:CONTRAST? --Redrose64 (talk) 15:59, 12 March 2014 (UTC)

   One man's "bike shed" (nice essay - I didn't read it) is another man's "that looks like an old lady's kitchen wallpaper", which I was too polite to say the first time around. HTH! — Scott • talk 16:03, 12 March 2014 (UTC)

   Any color this shade is "pastel". To be honest, I'm stuck here because I'm not one to come up with good colors. I picked them from Help talk:Using colours. Though I'd like to have some color, peprhaps there is an alternative to using background coloring. — Edokter (talk) — 21:06, 12 March 2014 (UTC)

   I've been thinking that we could try coloring the headings instead. But that's a discussion for later. —David Levy 22:17, 12 March 2014 (UTC)

5. I think it looks nice, and is an improvement visually over what we have now. But I find the proposed design, as well as the current one, too busy or crowded for lack of a better term. I'd prefer something more radically differet, with a somewhat minimalist design. Hot Stop talk-contribs 02:46, 13 March 2014 (UTC)
6. Oppose - I'm going to start off by saying that I have a tremendous amount of respect for your desire to push through big changes and deliver a new main page. Unfortunately, while I agree that the current main page could use updating, there are a number of problems in this proposal that need fixing, as well as some design choices you made that I can't get behind.

   Visual issues - From a visual standpoint, I have several issues. First, I feel that the top bar (the one with the portals in it) looks visually cluttered. I personally don't feel that the mission statement adds any value (and I dislike the wording). If we're going to put text there though, I would have it start at the height of the "ikipedi", as opposed to the height of the larger W and A. Otherwise it looks stuffed in the top corner. I also don't think that the portals belong in the top section. They look out of place in the current build, and they look out place in this build. I love portals, and I would love to keep links to them, but there's too much going on in that top section, and of the four elements (globe background, wordmark, intro text, and portals), I feel portals are the weakest link. Second, I dislike the shading in the header of each section. The-white-fading-into-box-color thing just looks off to me, as the colors never really match up and my attention is drawn to the line where the colors meet/clash. Third, I feel that we need to lock the bottom matter (in the case of TFA, this is the "Archive – By email – More featured articles..." part) to the bottom of the box, rather than to the end of the text. The way it is now, each section has the bottom matter floating a different amount above the bottom edge of the box. On my screen, there's almost no gap between the bottom of the box and the bottom matter in the "From today's featured article" and "In the news" sections, noticeable gaps in all of the other sections, and a very large gap in the "Today's featured picture" section. Finally, I would find a new place, or evaluate the need for having, the current date and purge button. It's in the bottom of the "On this day" section, a vestige of the current design, and disrupts the visual cohesion without really adding anything. I would advocate that we pull a page from Bulbapedia's main page and put the clock up top (their clock is also a purge button).

   Layout issues - I dislike that the featured pictures section is at the bottom. I realize that everyone has different priorities in terms of what they want placed 'above the fold' (above having to scroll down, in this case), but that's my preference. I feel that kicking it to the bottom is a mistake in the current design, and would love to see the new main page have it above the fold, at least partially, so that people know it's there.

   Process issues - I feel that you took the wrong message (or an incomplete message) from my analysis of the redesign process. You latched onto the 'give the community a binary choice' part, but missed the 'there is a disconnect between what the designers are making and what the community wants' part. The 2012 redesign process, from which this emerged, didn't make an effort to reach out to the community and get an idea as to what we would like to see in a new page. It appears that a dozen designers each, in relative isolation, took the existing pieces and re-skinned them in a visual style they found appealing. Plenty of people want the main page to look "nicer", but there's no real understanding of what the community would view as "nicer", nor is there an understanding of what elements the community wants on the main page. An effort was made in 2011 to collect this information, but it suffered very low turnout, wasn't very focused, and ended up with more "no consensus" results than anything else.

   Accounting for the future - While I feel that the main page redesign needs to be community driven, I think it's also important to speak with Jorm (WMF) and the the other members of the WMF design team so that we can get a feel for what the default interface is going to look like in the future. This design seems catered towards the visual style of Vector, but Winter appears to be the future (and perhaps Athena further into the future), and it's going to change the shape and color scheme of the interface.

   Sorry for the long read, but if we're going to do this, I want to make sure that it's done right, and sometimes that calls for large blocks of text. Sven Manguard Wha? 08:44, 16 March 2014 (UTC)

   I think you completely misunderstood the question as it stands; it says "do you want to build further on this proposal with my framework as a reference design?" You "no" implies you do not want any change at all. Everything you mention are mere details, which are exactly the issues I want to work on in the next step. Again, the design you see is merely an example that is build on the reference design. The underlaying framework allows any layout and styling, but styling is the last thing we should be focussing on.

   I understood your message perfectly, and I am trying to avoid its pifalls. I am also trying to break through the barrier that seems to lock the current main page in a consensus-demanding stasis. I think a small group of people should ultimately be 'in charge' of the main page, just like the various main page projects are in charge of its content. We should not be afraid to make changes and be more dynamic; the is Wikipedia after all. Winter is going to be a few years I guess, so there's no telling how it will integrate now. But this new framework will allow the mian page to adapt to any new default skin that may come. Again, we need to let go of this fear of change, or we will still see this page in 2020. — Edokter (talk) — 12:48, 16 March 2014 (UTC)

   Winter is going to be like, next month, as a beta feature.--Jorm (WMF) (talk) 17:26, 16 March 2014 (UTC)

Main Page taskforce

I certainly don't see any objection to move forward, so let's do just that. Let's set up a place were everyone interested can throw around ideas and brainstorm (and not be burdened with RFCs and such). I'd also like to have some delegates from the various main page projects involved, so we can coordinate and improve on interoperability with the main page. Please state your interest below. — Edokter (talk) — 01:32, 16 March 2014 (UTC)

• I would be interested. My primary desire would be the inclusion of the "Become an editor" type content, and how we could best use this space. --NickPenguin_(contribs) 05:43, 16 March 2014 (UTC)
• For the record, I will join the taskforce, as I'm interested. However, I just want to say: no, there isn't much objection, but I also don't see much support, either. We all agree that we want to see the main page be updated, but there is still not much more than that (that's probably the efforts keep failing); we even have disagreement on the process. (cf. Wikipedia:2014 main page redesign proposal.) In a situation like this, I think it's better to seek a small cosmetic change, and we already have many good design ideas (e.g., Chinese Wikipedia one, which was actually originally from English Wikipedia.) I think it's better to just open a poll on designs, including ones from the past efforts and including your new design proposal. If there is no clear winner, we will run a run-off and so forth. In short, I would like to pass the brainstorm stage. (of course, maybe it's just me.) -- Taku (talk) 17:55, 17 March 2014 (UTC)
  • Competition (with users voting on various proposals to select a winner) is the one main page redesign method that's failed consistently (including in 2006, when it nearly derailed the entire endeavor). Collaboration is the only way forward.
    You keep mentioning the Chinese Wikipedia's main page, which I haven't seen anyone else cite as a desirable model. Perhaps you can explain why you believe that it "has the best chance of the community support". —David Levy 21:10, 17 March 2014 (UTC)
  • The last thing I want is process, polls, competitions, and most of all, deadlines! There is no policy that dictates how the main page should be maintained. My feeling is we should treat it like any ohter page; as a collaborative effort. Look at how MediaWiki is doing it. Community size should not matter. We lay down the basis and adjust anything that comes up. That should result in a page that conatains the best from all other designs combined. I will be setting up a workspace soon, and then we can get to work. — Edokter (talk) — 21:37, 17 March 2014 (UTC)
    • if that last bit is the case, then as I've said before, you should implement the current main page exactly as it is using your new, easier to modify framework. Once that has acceptance, and it is easier to modify the layout and such, then we can begin to propose incremental changes. In my mind, there is no other way forward, you will continuously cone up against a yes/no ultimatum and the answer will always come up no. --NickPenguin_(contribs) 23:02, 17 March 2014 (UTC)
      • Exactly. I can't see any reasonable opposition to just making the background coding more sensible, in a way that people who don't understand code won't even notice. You just need to get an appropriately empowered admin to do it, frankly. Anything beyond that, you maybe need a small group of people who care enough, and a friendly admin, while being open to input from passers by and people on the Main Page talk page. Collaborative editing doesn't mean discussing and voting on everything before doing anything: it can mean just changing something and seeing how people react. 86.157.148.65 (talk) 19:52, 18 March 2014 (UTC)

• I'm very interested in helping with brainstorming and collaborating on this, I'll gladly join. --Nicereddy (talk) 06:46, 13 April 2014 (UTC)

Proposal to implement the current Main Page using Edokter's framework

Main Page (old style)

What we have here is two conflicting desires: the desire to update the 'look and feel' and the desire to update the underlying framework; I think we need to focus on the latter before the former. As I have observed over the last two years, proposals to add or remove content have generally failed because of structural issues, especially achieving visual balance. Tables are very rigid and unfriendly to modifications. Conversely, @Edokter: has a solid design which can be easily modified to achieve balance, and it opens up a huge range of styling possibilities.

If it is the case that this design is more capable of modification, then it would seem the best way to move forward is to reimplement the page exactly as it appears now (or as close as possible), using his new framework. Then, other visual improvements can be discussed and made through consensus with a smaller, more focused group. --NickPenguin_(contribs) 01:54, 20 March 2014 (UTC)

Indeed, I would like to see the main page's current layout (or an approximation thereof) with Edokter's framework.
Next to the ill-conceived competitions, the greatest obstacle to successfully redesigning the main page probably has been the implementation of too many ideas at the same time. At the moment, this comes across as a package deal, which tends to evoke opposition from users who dislike some of the changes and oppose the entire proposal (including changes that they like). I agree that an under-the-hood overhaul would demonstrate that this isn't an all-or-nothing proposition, allowing us to discuss additional improvements more easily. —David Levy 21:38, 21 March 2014 (UTC)

I don't know if I can present the main page exactly as it is now (nor if I want to). Also, having two divs stacked is something I have not considered yet, but I'm sure willing to try (unless you want to have two section share a div, as they share a table now). — Edokter (talk) — 22:02, 21 March 2014 (UTC)

@Edokter: Yeah, I wouldn't expect such an implementation to look exactly like the current main page. I don't know what coding approach would be best, so I'll gladly defer to you on that point. The goal, I think, is to approximate the current design in whatever manner best preserves the technical advantages that you've mentioned. It should be relatively easy to achieve clear consensus for that type of improvement, at which point we could discuss other changes without placing it in jeopardy. —David Levy 00:26, 22 March 2014 (UTC)

I can try to lend a hand at approximating the current Main Page design. If that becomes the current plan. --NickPenguin_(contribs) 03:27, 22 March 2014 (UTC)

I think I have the structure laid out, see here. I have not got around to styling yet, so whatever you do, don't click here. :) — Edokter (talk) — 13:54, 22 March 2014 (UTC)

Do you object if I poke around in your workspace and try to make them look closer to the current Main Page? --NickPenguin_(contribs) 14:48, 22 March 2014 (UTC)

Not at all. I'm done playing for the moment. — Edokter (talk) — 16:04, 22 March 2014 (UTC)

I tweaked it, and everything looks the same except for two things: the headings on the sections on the new version are just slightly bigger, and the spaces between the sections are bigger too. Not sure how to fix those two things... Other than that it looks the same on my screen. --NickPenguin_(contribs) 05:51, 23 March 2014 (UTC)

I fixed most of it. Just for fun, I'd like to see if anyone can spot the difference, but, IF this is going to be on the main page, I will have to insist that the top banner and sister links are also made fluid. Otherwise, having only the main sections have adaptive behaviour is not much use at all. ~~

It renders extremely similar on my laptop, not identical, but very close. However on my phone, it appears different; TFA and ITN are stacked instead of side by side, same with DYK and OTD. Also, the extra space on the right hand of each section is filled with empty coloured space. --NickPenguin_(contribs) 19:03, 24 March 2014 (UTC)

Actually, the reason its doing that it because the text in TFP it to the right of the image instead of below, and the pictures and lower script in the other boxes are all justify right. Could this be fixed by making the text in TFP fluid? --NickPenguin_(contribs) 03:55, 25 March 2014 (UTC)

The stacking is intended. As I said before; I have no control over the content being transcluded. POTD is encapsulated in a table and its layout is dependent on the image size and orientation. — Edokter (talk) — 13:13, 25 March 2014 (UTC)

Fair enough, that could be one thing that mentioned when the final version goes before a community wide vote, probably on Talk:Main Page and advertised on WP:CENT. Is there any more work to do? It looks pretty identical to me at this point, aside from some functional differenced that would need to be addressed with transcluded templates. Maybe @David Levy: could chime in here? --NickPenguin_(contribs) 15:18, 25 March 2014 (UTC)

I'm seeing a slightly narrower left-hand column and slightly wider right-hand column, along with a bit of extra space below TFA and ITN. Otherwise, the differences seem negligible (apart from the equal division of a column's extra space between its two sections, which is an improvement). Excellent work. —David Levy 19:18, 25 March 2014 (UTC)

It looks the same, but uses my framework. The banner is still not fluid though. Perhaps that should be the first item to improve? — Edokter (talk) — 23:05, 25 March 2014 (UTC)

Well if it is the case that this version is virtually indistinguishable from the current appearance of the main page, then I think we should start a new discussion on the main page and propose the code be changed to this, and then afterwards propose some incremental/functional changes. --NickPenguin_(contribs) 12:28, 27 March 2014 (UTC)

Just want to note my strong support for this direction (change structure first, content later). Thank you so much folks. I look forward to supporting this proposal wherever needed. –Quiddity (talk) 18:16, 28 March 2014 (UTC)

I liked Edokter's redesign, but I also agree that it makes sense to update the framework first. Bravo to Edokter and NickPenguin for their work to recreate the main page. Novusuna ^talk 19:58, 28 March 2014 (UTC)

If any kudos are directed at me, then it is surely because I am riding on the coattails of Edokter; he has done all the significant development here. --NickPenguin_(contribs) 03:13, 29 March 2014 (UTC)

You did tweak the CSS a bit, but that's a fair point. Three cheers to Edokter for making the framework, and I hope consensus can be reached to implement it soon. Novusuna ^talk 21:10, 29 March 2014 (UTC)

Proposal has been posted

On Talk:Main Page#Proposal to implement new framework for main page. — Edokter (talk) — 00:21, 2 April 2014 (UTC)

Edit Counter Optin

Proposal

It was established globally, that the edit counter is to retain its optin (see meta:Requests for comment/X!'s Edit Counter). Before the global discussion, a local discussion took place leaning in favor of removing the optin requirements. I am hereby asking again, since I abruptly stopped the last discussion.

The explanation

The new User Analysis Tool, currently providing identical data to X!'s Edit Counter, honors the optin requirement, per the global discussion that took place on meta. However, the local consensus to this may be very different from the global consensus. Optin is having additional aggregated data be displayed about a user, at the user's consent. It should be emphasized that this data is publicly available. Optout is having additional aggregated data be suppressed about a user, if the user so wishes. No opt is making the aggregated data be displayed, regardless of what the user wishes. This additional aggregated data consists of monthly edit counts per namespace and most-edited pages per namespace.

The question

Should en.wikipedia be an optin, optout, or a no opt wiki for the edit counter? This change applies to this Wikipedia only.—cyberpower ^Chat_Online 21:49, 3 April 2014 (UTC)

For reference

The earlier local discussion mentioned above is at Wikipedia:Village pump (technical)/Archive 113#X!'s Edit Counter. – Wbm1058 (talk) 19:01, 7 April 2014 (UTC)

• Example opted-out user: Bot1058
• Example opted-in users: RMCD bot and Wbm1058
  • From the latter report, one can quickly learn what one article I've spent the most time and effort working on. I don't know of another way to easily determine that. – Wbm1058 (talk) 18:27, 8 April 2014 (UTC)

• There is also a discussion here from 2013 about privacy and the generation of editors' profiles. SlimVirgin ^(talk) 22:10, 11 April 2014 (UTC)

Retain the opt-in requirement

1. Support. I don't know the complete details of the edit counter or the other ways to obtain the same information, but Wikipedia should assume that its editors deserve maximum privacy unless and until they elect to give it up. Technical 13's counterargument below is significant, that conceding maximum privacy in cases that editors don't actually have it could be deceptive. However, to the extent that the tool is used, granting editors opt-in protection from use of the tool is still significant. Spike-from-NH (talk) 00:37, 4 April 2014 (UTC)
2. Support. Easy access to this kind of processed data can do some serious harm to individuals. That is the reason the German community has been vocal for dataprotection not just the legal aspect of it. Over the years people have expected the optin behaviour. Changing it now would be totally unfair to those people relying on it. Agathoclea (talk) 08:25, 4 April 2014 (UTC)
3. Support as someone who elected to opt in. This is a case in which we do not fully understand the ramifications of what we are creating, and in deference to unintended consequences and humility about our own limited understanding of what those might be, we should retain the strongest reasonable privacy controls.--~TPW 12:08, 4 April 2014 (UTC)
4. Support. Even though the information is in theory publicly available, presenting it in this format is still a privacy issue. (Just because we all walk down the street doesn't mean we'd want CCTV cameras joining up our activities and someone posting it online.) It would be unfair to people who edited on the understanding that there was an opt-in to remove it after the fact; if it's switched to opt-out not everyone will notice. If the opt-in is removed, at the very least there should be a grandfather clause so that it isn't retroactive. I'm thinking particularly of people who may have edited at work. SlimVirgin ^(talk) 15:37, 4 April 2014 (UTC)
5. Support Wikipedia traffic is now encrypted by default to make it more difficult for others to snoop on what individuals do here. There was a substantial global decision taken to maintain privacy in respect of this tool too. There doesn't seem to be any particular reason for the English language project to deviate from this. Andrew (talk) 20:53, 4 April 2014 (UTC)
6. Support Editors privacy should be respected and even if there is a workaround, at least let's not facilitate anyone snooping around. I support grandfathering the optin if the decision is to remove it.--Mariordo (talk) 04:32, 5 April 2014 (UTC)
7. Support Here we go again. --Artoasis (talk) 10:22, 5 April 2014 (UTC)
8. Support – It would be a mistake, on multiple levels, to alter this from the current opt-in requirement. Hopefully it is something an office action would dis-allow; should such an awry consensus form. Just as a consensus can not form to disregard copyright constraints, or other zero tolerance issues, privacy is fundamentally equal! No good reason has been proffered for needing this change; only that we could reach a different consensus. And any reason given could only sound like a big brother "plea of support".—John Cline (talk) 10:32, 5 April 2014 (UTC)
9. Support SlimVirgin sums it up well for me. What we have now works well; opting-in is easy, and I see no need to change. It's a good balance between transparency and privacy. Miniapolis 14:40, 5 April 2014 (UTC)
10. Support for privacy reasons, per Mariordo. Regards, Iselilja (talk) 17:17, 5 April 2014 (UTC)
11. Support I favor the opt-in policy. Shyncat (talk) 17:24, 5 April 2014 (UTC)
12. Support Essential for privacy. I thought that this was decided already; why is it here again? North8000 (talk) 18:49, 5 April 2014 (UTC)
13. Support Things involving poking, prodding, measuring and analyzing should require consent, online and off. Not that they do. But they should. We could. InedibleHulk (talk) 23:43, April 5, 2014 (UTC)
14. Support +1 What North8000 and SlimVirgin said. Djembayz (talk) 01:59, 6 April 2014 (UTC)
15. Support Optin permits a user to take action to support a change; optout forces a user to take action to prevent it, and furthermore may go unnoticed or unaddressed. That's why optout in general is an "in your face" approach, which I usually oppose for just that reason. No-opt is even more so. If there may be different takes on an issue, why not allow people to simply to respond in the most natural way: say "yes" (optin), or "leave status-quo" (nothing required)? Give people a chance to look it over, and let consensus develop on its own. In time, perhaps there will be little disagreement. If not, what's the harm of optin? Evensteven (talk) 07:14, 6 April 2014 (UTC)
16. Support Per SlimVirgin: There are many things we do publicly where we wouldn't like aggregated data to be publicly available (leaving the house, buying alcohol, seeing a doctor,... ), so "the raw data are public already" is not a reason for removing the choice. "Other tools exist" doesn't strike either, since other tools are not linked from each contributions page. The concerns about providing a false impression of privacy should be adressed in the documentation of the choice, not by removing the choice. — HHHIPPO 10:12, 6 April 2014 (UTC)
17. Support per SlimVirgin and others. It Is Me Here ^{t / c}
18. Support - I don't myself see a problem with this information being displayed, but I agree with Slim Virgin's point that it may matter to some people, and that they have edited with the understanding that these statistics would not be generally available unless they opted for it. It's the retroactive aspect that I feel isn't fair. —Anne Delong (talk) 12:23, 6 April 2014 (UTC)
19. Support —and make it easier to opt in!!! I don’t have a problem with it myself and many of the arguments for the other two options are quite valid but it would be a little unfair to those who don’t want this to totally reverse it. ☸ Moilleadóir ☎ 03:05, 7 April 2014 (UTC)
20. Support My thoughts are in line with those of SlimVirgin. While the information is publicly available, there is no reason to make it easier to access unless someone wants it to be. Again, like him, I'm thinking of those who edit at work. Zell Faze (talk) 11:52, 7 April 2014 (UTC)
21. Support - Per above.--HCPUNXKID 15:27, 7 April 2014 (UTC)
22. Support - I see the benefits of changing it, but I think the arguments given above outweigh those benefits. - Aoidh (talk) 09:46, 8 April 2014 (UTC)
23. Support. Privacy is very important. Many editors may contribute while working from the company computers. It is someone's right not to publish private information. We do not want to discourage anonymous editors from editing. -- Magioladitis (talk) 12:05, 8 April 2014 (UTC)
24. Support for now. Once the toothpaste is out of the tube you can't put it back in. SlimVirgin has valid concerns and makes good points. EditCounterOptIn.js is too obscure a means of opting in or out. I suspect that some users are not opted in because of this, and if we change it to opt-out, some may want to do that and not understand how to do that. Let's first make opt-in a check-box on Special:Preferences, then wait a while and revisit this. – Wbm1058 (talk) 17:36, 8 April 2014 (UTC) ... Just a note that I am still occasionally seeing "This webpage is not available" errors from this tool, and priority probably should have been given to sorting out the technical issues and getting the tool stablized for at least a month or two, before opening up this discussion. Wbm1058 (talk) 17:50, 8 April 2014 (UTC)
25. Support per Moilleadóir and Anne Delong. Kennethaw88 • talk 01:59, 9 April 2014 (UTC)
26. Support. I can't say I feel strongly about this. When the additional data was presented on the toolserver, it didn't worry me, but when it became opt-in I didn't think it was important so I never bothered to change my settings. I don't suppose it makes any difference to the vast majority of Wikipedians, but maybe there is someone out there who might run into trouble if we connect the dots for everyone to see. Also, I'm bothered that privacy is practically non-existent throughout most of the Internet, and I like the idea that it should be particularly respected at Wikipedia. So in a borderline case where I don't think it much matters, I'm inclined to !vote in favor of privacy. Rivertorch (talk) 05:47, 9 April 2014 (UTC)
27. Support. Users' Privacy must be provided for. Such a statistical overview is no public data. It is a personal profile that needs to be kept from the public. It may only be published if the user expressly wants to. This is a civil rights issue.--Aschmidt (talk) 12:14, 9 April 2014 (UTC)
28. Support. --Horgner (talk) 12:43, 9 April 2014 (UTC)
29. Support. Per Aschmidt. Raymond (talk) 12:57, 9 April 2014 (UTC)
30. Support. Per Aschmidt. --Zinnmann (talk) 12:59, 9 April 2014 (UTC)
31. Support per this rationale and to stay in conformance with EU legislation. --AFBorchert (talk) 13:10, 9 April 2014 (UTC)

    AFBorchert, can you explain why you believe that a non-EU person creating a non-EU tool on a non-EU computer system should care what EU legislation says? I mean, it might be nice to go along with the principle, but do you believe that it is actually required for some reason? Is the EU asserting that the EU gets to tell 100% of the world's population what to they're permitted to do on 100% of the world's computers?
    I am certainly not a lawyer, but I believe that it's typical for EU legislation to affect only people and computers that are actually in the EU. The last time I heard anything about this, Americans using American computers, or Asian people using Asian computers, or African people using African computers, were not actually subject to EU law. WhatamIdoing (talk) 20:43, 9 April 2014 (UTC)

    See Lex loci delicti commissi. The location of the computer system does not matter in this case. If this tool is accessible from Europe, it is subject to European law. --AFBorchert (talk) 08:56, 10 April 2014 (UTC)

    That article says nothing whatsoever about the supremacy of EU laws. It says that when multiple laws apply, a court first decides which ones it believes are most relevant. For an American user on an American computer, it seems to me that they would not choose EU laws. (Of course, I might be wrong, but so might you.) It seems likely to me that your claim here is an oversimplification. For one thing, what if laws in different countries directly conflict with each other? You can't just say, "this law demands that you do this, and this other law demands that you never do this, and therefore you must simultaneously do X and not-X". WhatamIdoing (talk) 15:47, 10 April 2014 (UTC)

    It is not about supremacy, it is about whether EU law applies. See here for a decision by a German court per lex loci delicti commissi in a case against the WMF concerning copyright and personality rights. --AFBorchert (talk) 05:09, 11 April 2014 (UTC)

    Since Germany has no jurisdiction in the first place, what their courts say doesn't matter. Moreover, the German claim that it does matter is reprehensible and despicable, and we should utterly condemn it. --Trovatore (talk) 23:34, 16 April 2014 (UTC)

    Agreed that German law has no jurisdiction, but the law still does matter because it affects our German editors. If providing opt in gives editors the means to follow German law, I see no reason not to provide it. The rest of us are still free to choose as we will. That much is not catering to inappropriate legal claims, but it is supporting editors. Evensteven (talk) 04:49, 17 April 2014 (UTC)

    I actually !voted for keeping opt-in. As I say below, someone can easily provide this information regardless of user consent, but I don't see why it has to be us. I just want it to be clear that we're not attorning to any claims of extraterritorial jurisdiction. --Trovatore (talk) 06:41, 17 April 2014 (UTC)

    Yes indeed, I did see your vote, and comments. I wasn't contradicting your main point, but saying there is something about that law that does matter here. I doubt that opt-in is enough for that law, which (I think) seeks some control over WP also, but if opt-in's enough to get the German courts off the backs of German editors, protecting them from prosecution, then we can do something useful in this forum, at no cost to ourselves. The rest needs handling elsewhere. Evensteven (talk) 15:50, 17 April 2014 (UTC)

    Not exactly following. Under what circumstances could German editors (theoretically) be prosecuted? Are you talking about when they use the tool, or what? --Trovatore (talk) 19:25, 17 April 2014 (UTC)

    German law applies to German users (a group that defaultly includes non-resident German citizens and non-citizen residents of Germany), so it's possible that a German editor should not use this tool. I'd guess, however, that it's more probable that the German law is prohibiting German Wikipedians from maintaining the tool, rather than from using it. WhatamIdoing (talk) 19:05, 18 April 2014 (UTC)

    Oh yes, that could be, I suppose. I guess my feeling is that, if we want to do this for good and sufficient reason, then we'll just have to do without German programming skills on this tool. I don't think we're obliged to change our approach just to give German programmers the fun of tweaking it (and if they really want to, they can make their own fork of it anyway). As I say, though, my preference is for opt-in in this case. --Trovatore (talk) 19:13, 18 April 2014 (UTC)

    @WhatamIdoing: FYI: When you sue the WMF at a German court, the WMF will be subject to German law, even though the foundation is seated in the U.S. We have already had several cases like this.--Aschmidt (talk) 20:23, 18 April 2014 (UTC)

    And how will the court enforce its judgment? --Trovatore (talk) 21:36, 18 April 2014 (UTC)

    This is not up to the court, it's the plaintiffs business. He can levy execution against the defendant from the judgement which is just another legal title.--Aschmidt (talk) 22:03, 18 April 2014 (UTC)

    And how will the plaintiff enforce it? At some point he would have to involve the US legal system, no? --Trovatore (talk) 22:06, 18 April 2014 (UTC)

    Of course. This is not wild west, our judiciaries co-operate.—In other words, this ballot may end as it will, in the very end it will be the courts who decide over the privacy of those within the jurisdiction of any European country. See AFBorchert's hint to the decision in the Loriot case the WMF lost against the heir of a German writer a while ago.--Aschmidt (talk) 22:10, 18 April 2014 (UTC)

    I believe the US is rather reluctant to extend comity in cases touching what would be First Amendment issues if tried here. That is the correct attitude to take. It is a bad thing that Germany (and the rest of the world) does not have its own First Amendment; this is one case where the US is more right than the rest of the world, and that is the most important reason we have to take a hard line against extraterritorial claims. --Trovatore (talk) 22:13, 18 April 2014 (UTC)

    Freedom of speech and freedom of the press have been adapted—as most civil rights—from the U.S. constitution. You will find those liberties in article 5 of the German basic law. Those rights also apply between citizens.--Aschmidt (talk) 22:19, 18 April 2014 (UTC)

    If it doesn't stop them from banning the Horst Wessel Lied, then it isn't strong enough. I gather that the German law wouldn't bother us because it's supposed to have an exception for educational uses, but if it didn't, we would still report the lyrics, even if it's against German law and is available in Germany. --Trovatore (talk) 22:33, 18 April 2014 (UTC)

    Please note that the Horst-Wessel-Lied has been banned in 1945 in this country by allied forces, and that this ban still prevails. Of course, any nazi symbols or content is banned in this country, so they had to import it from the U.S. for many years. What's more, you will find many usernames on English Wikipedia alluding to neonazi meanings that have long been banned on German Wikipedia. Most law professors teaching today in this country and most judges at the German Federal Constitutional Court were trained in the U.S. On the other hand, as I said, our judiciaries and the legal profession are tightly linked together and share many of the same principles, you might not be aware.--Aschmidt (talk) 22:41, 18 April 2014 (UTC)

    The point is that Wikipedia will not be bound by any such law. If de.wiki users don't want to have such content, that's fine, but German law does not stop us. --Trovatore (talk) 23:16, 18 April 2014 (UTC)

    The problem is that you won't get far this way. It will not be generally accepted and it is ethically wrong.--Aschmidt (talk) 00:30, 19 April 2014 (UTC)

    Not sure which part you're talking about. Germany is ethically wrong for the way they restrict speech.

    (If you mean the opt-in part, I support opt-in, but not because of German law.) --Trovatore (talk) 00:42, 19 April 2014 (UTC)

32. Support per Aschmidt (#27) and AFBorchert (#31) —Morten Haan (talk) 14:53, 9 April 2014 (UTC)
33. Support. Leave it up to the individual user whether this kind of data aggregation should be visible to anybody else. --RonaldH (talk) 17:41, 9 April 2014 (UTC)
34. Support We live in a world where all sorts of information is publicly available. We are being tracked minute by minute every day of our lives. That does not make harmless the act of aggregating every bit of publicly available information and displaying it for all to see, quite the contrary.--agr (talk) 18:26, 9 April 2014 (UTC)
35. Support There is no need for this to be public data, our privacy must be provided for. Imveracious (talk) 18:46, 9 April 2014 (UTC)
36. Gestapo, KGB, Stasi, Securitate, NSA, Wikimedia? No, thanks! Not all what is possible fits my sense of moral. Marcus Cyron (talk) 19:54, 9 April 2014 (UTC)
37. Supportwhy make it easyer for nsa and co. --Wetterwolke (talk) 21:06, 9 April 2014 (UTC)

    I don't follow the reasoning of your argument. It's already "easy for NSA and co.", the raw data is public domain for all to see. Xtools only converts this raw data into a user-friendly format that can be conveniently and easily read by a layperson. Removing opt-in for Xtools means that everyone can freely access this information regardless of their computer competency, and not just "NSA and co.". --benlisquare_T•C•E 05:24, 11 April 2014 (UTC)

38. Support. We are here to write articles, not to collect and aggregate data and not to spy on other users. Editors don't need this kind of information when working on articles, therefore we should not collect it in the first place or even make it publically available to anyone without explicit consent of the user (-> Opt-In). Opt-Out is no solution, because less experienced users will not be aware of it, and if this data would become available publically, we can be sure it will be misused by some. Since potentially this can cause serious harm to users in real life, we should keep it at Opt-In! Anything else would be unethical (and in some countries even illegal). --Matthiaspaul (talk) 21:42, 9 April 2014 (UTC)
39. Support. We need to be careful not to trample on international laws; "let the lawyers sort it out" is _NOT_ a good strategy with these sorts of things. I would be in favor of making this tool more visible, however, as I didn't know about it until today when I logged in and saw it mentioned above my watchlist, and I have now opted in (if I did it right.)PsyMar (talk) 06:12, 10 April 2014 (UTC)

    And "let amateurs vote on the interpretation of the law" is a better strategy? Mr.Z-man 12:49, 10 April 2014 (UTC)

    No, but "in absence of expert advice, assume the most restrictive legal interpretation" is. If we are absolutely certain that there are no legal issues in switching this to opt-out, then... well, then I still have problems anyway, but that's getting away from the point. As it stands I don't think that certainty exists, and so Psymar's support on those grounds seems perfectly reasonable to me. Aawood (talk) 11:46, 11 April 2014 (UTC)

    Should we also assume that Iranian and Saudi law might apply and remove anything from the encyclopedia that might be considered blasphemous toward Islam? Should we apply the most restrictive interpretation of North Korean law and remove anything critical of their government? WMF has a whole team of lawyers on staff, why don't we just ask them if we think this is a potential issue? If they say it's illegal, then we can just end this whole debate entirely. If not, then we can debate the issues that are actually relevant, not just hypothetical scenarios. Mr.Z-man 14:15, 11 April 2014 (UTC)

    In that case, please do feel free to contact the WMF legal team and come back with a response. Until then, we don't have anything but hypotheticals to go on and, as such, it makes sense to take the safer road. Aawood (talk) 12:06, 16 April 2014 (UTC)

40. Support per SlimVirgin. Spencer^T♦C 07:52, 10 April 2014 (UTC)
41. Support per above. NNW (talk) 08:18, 10 April 2014 (UTC)
42. Support Vogone (talk) 09:40, 10 April 2014 (UTC)
43. Support Yellowcard (talk) 11:28, 10 April 2014 (UTC)
44. Support --Leuchtschnabelbeutelschabe (talk) 11:46, 10 April 2014 (UTC)
    Discussion moved from here to discussion section below at request of user SlimVirgin. Evensteven (talk) 21:17, 12 April 2014 (UTC)
45. Support Lending my support to Opt in. One point to make is that simply going with the majority may not be the best approach here, as while the majority may not be fundamentally affected one way or another, the minority who are may be affected very harmfully indeed. I am also not convinced by the argument that "anyone can make a tool to get this information anyway"; firstly, this is simply not true (I would argue a relatively low percentage of the world population have the expertise, opportunity and desire to make such a tool), and secondly, I see no reason to make life any easier for someone that would. Finally, I am not a lawyer, but this seems the safest legal option globally. Keep it opt in, for the people here who feel strongly that it should be, and the majority out there who have no idea that there's even something to opt in/out of. Aawood (talk) 11:52, 10 April 2014 (UTC)
46. Support As for AFBorchert and Aawood. Any kind of data aggregation tool must be optin. -- Smial (talk) 11:56, 10 April 2014 (UTC)
47. Support: Always prefer a choice over forced clean-up (ie opt out). Niteshift36 (talk) 16:54, 10 April 2014 (UTC)
48. Support --Krib (talk) 21:30, 10 April 2014 (UTC)
49. Support -- even if doing so only makes accessing the info more of a challenge and doesn't actually ensure privacy (if i understand correctly) JDanek007^Talk 03:20, 11 April 2014 (UTC)
50. Support Per ASchmidt and AFBorchert. User Data are not public data. -- Andreas Werle (talk) 04:32, 11 April 2014 (UTC)

    But it is. This proposal doesn't change anything privacy-wise, it only allows for greater convenience for users with constructive requirements to use Xtools (e.g. identifying and dealing with abusive users) to be able to use it. I mean, I don't have to use Xtools, there are a handful of other tools out there as well. If I see an editor that I have suspicions with, I can simply mouse-over his name, and WP:POPUPS will tell me everything I need to know about this person. Forcing an opt-in component in Xtools is hardly helpful in terms of user privacy; it's just like hiding under the blankets, holding your hands over the ears, and pretending the problem doesn't exist, when it still does. My editing information, your editing information, everyone's editing information is still freely and readily visible to anyone. --benlisquare_T•C•E 05:34, 11 April 2014 (UTC)

51. Support --Superbass (talk) 17:56, 11 April 2014 (UTC)
52. Support --KurtR (talk) 01:16, 12 April 2014 (UTC)
53. Support. IMHO, we should allow people to decide exactly what information about their editing they want to be easily accessible. I feel the contributions list is perfectly fine, but once you've started organizing and analyzing it like the edit counter does, I feel it's crossed the boundary past which editors should have to decide whether they want it visible. (I did decide to opt in: others may not feel comfortable with doing so, and I think we should respect that and not remove the ability to choose.) Double sharp (talk) 04:42, 12 April 2014 (UTC)
54. Support. Like many others, I have opted in – or, at least, I did to the X tools. The data may be public, but that doesn't mean that all aggregates and analyses should also be public. I doubt that anyone has illusions about their privacy, and anyone with even a trivial amount of technical knowledge knows that such tools could be independently programmed. However, we're not talking about random third-party tools here; we're talking about the official tool, and it should recognize both users' concerns and global consensus. Normally, I'd scoff at such idealistic ideas, but, in this area, I believe that Wikipedia should be a model for the rest of the Internet. NinjaRobotPirate (talk) 07:00, 12 April 2014 (UTC)
55. Support: Echoing Matthiaspaul above (number 38 in comments). Fylbecatulous talk 13:51, 12 April 2014 (UTC)
56. Support: Wikipedia (English) should maintain transparency for data it collects on user editing frequency and how that editing frequency data, identified with a user name, is publicly displayed. At the present, there is no such explanation, so even finding out how to opt-in, and what that means, is a hit-or-miss proposition. Until such explanation is easily available to a new user, opt-in must be the default; otherwise there is no informed consent. Once such an explanation is prominently displayed in a post to every user talk page, then and only then, after a few months, is a change to opt-out supportable. It is not sufficient to say 'the information is already public'; even though the raw data about user editing frequency is at present publicly available in a technical sense, it is effectively not available to the vast majority of editors, users, or 'investigators'. I am 'opted-in', but for my particular situation, I could not think of a reason for not doing so. Others could be in a different situation; I do not wish to decided for others; neither do I expect Wikipedia to decide. - Neonorange (talk) 06:17, 13 April 2014 (UTC)
57. Support: I think I opted in, but I don't see why logged-in users who haven't opted in should be presumed or required to allow people get free analysis on them. I can see why an admin might be able to do this on non-opt-in users, and I can see how it might be occasionally useful for vandalism or conflict-of-interest patrollers to see other users' interests or patterns easily, particularly from anonymous IP addresses, but the occasional usefulness is not important enough that it should be easy for anyone to get it about all registered users all the time. It shouldn't be automatically made easy enough that people start assuming they can go to a tool and substitute trivia statistics for editors' actual behavior in contributions. Also, automatic availability lowers the barrier for discourteous privacy compromises: Contributors often work on articles they are familiar with, since they can discern reliable sources, and often this relates to geography, field of work, and institutions attended. With this article analysis tool, it is very easy for lazy busybodies to guess contributors' hometowns and other off-wiki attributes. We should continue to make sure that busybodies have to think about whether it's worth the effort to go figure it out by looking at actual edit history with real edit summaries, instead of just handing it to them. Those users, that don't have the experience to make an informed opinion of an editor from a contribution history the old fashioned way, probably shouldn't be given a free way to draw half-informed assumptions about other users. --Closeapple (talk) 10:38, 13 April 2014 (UTC)

    To put my concerns in another simpler way: Someone can go to a landfill and find people's documents every night; but that doesn't mean everyone's paperwork from the trash should be posted on a website every day because it's "already public". Privacy is important even when not in absolute situations: There is a grey area in which, even though some raw data is easily available, and some resulting output is logically feasible from that raw data, the result shouldn't be made easy enough that it looks like the Wikipedia community endorses that sort of output. --Closeapple (talk) 11:02, 13 April 2014 (UTC)

    Our system logs are meant to retain things. Landfills are meant to dispose of things. There's no comparison. — Scott • talk 23:01, 18 April 2014 (UTC)

58. Support: K@rl 14:36, 13 April 2014 (UTC)
59. Support - As much as possible the data should belong to the editor Drowninginlimbo (talk) 18:15, 13 April 2014 (UTC)
60. Support. Most editors aren't even aware of the tool, and (as has been said above) Wikipedia should assume that its editors deserve/want maximum privacy unless and until they elect to give it up. If you want don't care, you can opt-in. If you do care, then your privacy will have been grossly violated, for every second before you're opted out (which has to be after you're even aware of being in). There is no excuse for that systematic violation of the privacy of pretty much all Wikipedia editors. Also, people tend to underestimate, and frankly have no idea of, the consequences of the availability of data about them.--ZarlanTheGreen (talk) 00:37, 14 April 2014 (UTC)

    You make some grandiose statements ('gross and systematic violation of privacy') but you don't explain or argument them. You indicate Wikipedia should assume that its editors deserve/want maximum privacy yet Wikipedia's privacy policy clearly states that "Anyone with Internet access (..) may edit the publicly editable pages of these sites with or without logging in as a registered user. By doing this, editors create a published document, and a public record of every word added, subtracted, or changed." and "User contributions are also aggregated and publicly available. User contributions are aggregated according to their registration and login status. Data on user contributions, such as the times at which users edited and the number of edits they have made, are publicly available via user contributions lists, and in aggregated forms published by other users." (emphasis mine). Seems to me this tool is perfectly in line with Wikipedia's privacy policy, so unless it's the privacy policy itself that you object to it's not clear from your comment what those 'gross violations of privacy' are.--Wolbo (talk) 09:19, 14 April 2014 (UTC)

    Your talk of "grandiose statements" is not really in line with the rules about loaded words/weasel words ...but to deal with the important stuff: I'm supposed to give a brief summary of my reasons, not write a book on the issue. Your argument that these details can be accessed in other ways is, while perfectly true, not really valid. Numerous people have, in this section, already pointed out the flaws in that argument, so I wont bother to do so.--ZarlanTheGreen (talk) 20:29, 17 April 2014 (UTC)

61. Support. This is the first time I ever heard of such function. I understand some people's desire to share everything in the most convenient way possible, but PLEASE remember, there are some of us who view this as privacy and feel strongly about it. I'm one of those who are "under the illusion" that even if the raw data is already avaible, most people wouldn't manually search pages and pages of edit history just for the kick of it. (If you could write a program to do that, good for you.) But seriously, try to show some respect for your more privacy-oriented editors.--Gene2010 (talk) 04:12, 14 April 2014 (UTC)
62. Support.--Emeritus (talk) 19:50, 14 April 2014 (UTC)
63. Support. I think users should be able to choose what others see about them. I opted in because I didn't really care about who looks at my edits (everybody can, for God's sake!), but some people might be quite concerned at who looks at the pages they like to frequent, and being forced to have it displayed is like telling the world all the pages on your watchlist. Of course, I'd support the Opt-out option as well, but I can only pick one. --k6ka (talk | contribs) 01:51, 15 April 2014 (UTC)
64. Support, --He3nry (talk) 12:36, 15 April 2014 (UTC)
65. Support. "we are all anonymous contributors" - No, I'm not. --Martina Nolte _Disk. 15:30, 15 April 2014 (UTC)
66. Support. IW 16:17, 15 April 2014 (UTC)
67. Weak support per privacy concerns, under the presumption that statistics are still recorded if you want to access them later (if that's not the case, treat my vote as a weak support for opt-out). This feature really ought to be better advertised, though. Tezero (talk) 05:13, 16 April 2014 (UTC)
68. Support, because of strong privacy concerns. Who wants to use this tool should opt-in, but don't force others. --El bes (talk) 08:09, 16 April 2014 (UTC)
69. Support. --Eingangskontrolle (talk) 08:12, 16 April 2014 (UTC)
70. Support -----<)kmk(>--- (talk) 18:07, 16 April 2014 (UTC) let the editors be in control, how much of their meta data is publicly available
71. Support with qualifications. Here's the big qualification: We need to oppose in the strongest possible terms the villainous and despicable idea that countries are entitled to regulate what people put on the Internet in a second country, merely because it's available in the first country. We are subject to the laws that apply in Florida and California, period. We should not offer any respect whastsoever to any claim that German law applies, because any such claim deserves our utter contempt.

    That said, just because there is no valid law stopping us from doing something, doesn't mean we should. And just because, as Technical13 correctly notes, it's not hard to provide a tool that gives access to that information, doesn't mean it has to be us. --Trovatore (talk) 19:05, 16 April 2014 (UTC)

72. Support. -- It is fine as it is: opt in. I do not think we can reliably predict the effects for people around the world of making this information public. Plus, thousands will not be aware if we change this. Let's be cautious. Though the raw data is public, the analysis is not. Superp (talk) 07:12, 17 April 2014 (UTC)

    Your last sentence does not appear to be in line with Wikipedia's privacy policy which states that "User contributions are also aggregated and publicly available".--Wolbo (talk) 10:22, 18 April 2014 (UTC)

73. Support, reasons been mentioned above -- Kays (talk) 15:48, 17 April 2014 (UTC)
74. Support --Windharp (talk) 10:15, 18 April 2014 (UTC)
75. Support --An-d (talk) 10:34, 18 April 2014 (UTC)
76. Support --NebY There's a substantial difference between the accessibility of raw information on each individual edit and making comprehensive reports available to all at the touch of a button. This is similar to the principles operating in the UK under the Data Protection Act 1998, by which the duty of an organisation to disclose the data held on an individual is restricted to the data readily accessible on the organisation's systems (e.g. by existing high-level reporting facilities) rather than that which can be extracted by skilled low-level searches. Also, we do not know what further analyses and reports will be made available but for which we are now being asked to provide blanket approval on behalf of all users. NebY (talk) 14:04, 18 April 2014 (UTC)

    Comment It seems to me that (like very many of the posts in this category) this completely misunderstands the point. You quote regulations which appear to be about disclosing to users what non-public data an organisation holds about them. But the discussion here is nothing to do with non-public data! It concerns information which is already public (at the "low level" as it were); because of some bizarre ideas in Germany, it is felt that governments should attempt to restrict the logical inferences which someone can make from already public information. (This seeks to impose tyrannical restriction of thought, actually.) Wikipedia has a tool which can produce summary statistics from the raw public data: this discussion is whether people should be able to opt out of operation of this tool on public data relating to them. That's all. The data is already public; anyone can extract any information which can be inferred from it, and can already go to an external site such as wikichecker where the same "processed" information is available. So the "opt in" or "opt out" discussed here only gives a completely false sense of having "kept something private", which itself seems to me to be misleading at best. Imaginatorium (talk) 15:13, 18 April 2014 (UTC)

    Don't worry, I've read the arguments and understood that point - but it is not alone as "the point". There are others, such as questions of added value and accessibility. You'll have read about them already, above. So in adding my !vote, I've simply addressed them in a slightly different way by noting a similarity with principles of reporting and analysis as it applies to non-public data. I should add that I am saddened and a little shocked that you would describe German law as seeking "to impose tyrannical restriction of thought, actually"; it does not suggest a rounded and balanced view. NebY (talk) 15:54, 18 April 2014 (UTC)

77. Support This information is of little more than passing interest to legitimate users, and mainly only to the editor who's data it is. In case of dispute (socks, etc) the required information can be generated quite easily. Advertising to the world the times of the day, and the days of the week, that a particular editor is likely to be at home is not a good idea. We are not all anonymous you know. All the best, Rich Farmbrough, 22:30, 18 April 2014 (UTC).
    

Replace it with the optout requirement

1. Support The information can be found without the edit counter, why not just allow the edit counter to do its thang? pbp 23:45, 3 April 2014 (UTC)
2. Support: I'm globally opted in, and I really like seeing the different charts of my editing activity, but I doubt that everyone's with me on that. Letting users opt in or out doesn't really affect anyone other than them and anyone else wanting to see their edits, so let them decide for themselves. I think that opting out is better because then they see what the tool can do before deciding whether or not they like it. Supernerd11 :D Firemind ^_^ Pokedex 00:23, 4 April 2014 (UTC)
3. Support (with removing the option entirely as my second choice): I can see that some users might feel threatened by this tool. That the opt-in system ever went into place is a testament to that. But I think the opt-in requirement is putting a finger on the scale. I prefer allowing opt-out for people who feel threatened by use of this tool. But I am concerned that allowing opt-out could lead to an inference that doing so is to cover up bad conduct. Anyway, I prefer allowing people more options. —/Mendaliv/^2¢/_Δ's/ 02:43, 4 April 2014 (UTC)
4. Support I just opted in to see what the fuss was about - the stats are largely innocuous, esp. because most of them are very generic, and I remember seeing tools that aggregate this info on an hourly basis, so there's very little point in pretending these aggregates are somehow so sensitive that they need to be closed off by default. At the same time, both the monthly stats and the all-time top 10 lists are somewhat susceptible to misinterpretation - it's fine to let individual editors opt out. --Joy [shallot] (talk) 09:06, 4 April 2014 (UTC)
5. Support It's just security through obscurity, as T13 points out, but if we're talking about HR checking to see how much you're editing during work hours, a little obscurity is a good thing. --SarekOfVulcan (talk) 10:05, 4 April 2014 (UTC)

   Noopt as second choice, though. --SarekOfVulcan (talk) 13:01, 11 April 2014 (UTC)

6. Support. There are many good reasons for editors to make this info visible and I think they should. BUT, we want to devolve that decision down to the editor, I think. As a general rule, "opts" (opt-in or opt-out) are good in a system if you can allow it without serious negative consequences (as I think we can here), because 1) it's psychologically beneficial to give the user control over her environment, and 2) it implements flexibility -- if there are things we haven't thought of, such as Sarek's boss-tracking-you scenario above (which hadn't occurred to me), the user isn't stymied. Herostratus (talk) 19:56, 4 April 2014 (UTC)
7. Support At least have the ability to opt-out but otherwise it should be enabled by default since the information is available through other means anyway. -- GreenC 15:21, 5 April 2014 (UTC)
8. Support I generally favor opt-in policies. This seems like a good addition. Capitalismojo (talk) 16:10, 5 April 2014 (UTC)
9. Support As others have pointed out, this data is public anyway. As Jackmcbarn poined out, anyone could write a tool of their own which doesn't even bother to ask (it's even possible someone has already done so). On the other hand, people may still have their reasons for opting out. Also, SarekOfVulcan's comment hadn't occurred to me. Interesting. Why not just let people opt in or out whenever they choose? Mburdis (talk) 02:43, 6 April 2014 (UTC)
10. Support this information should be made available without a complicated opt-in process smatrese (talk) 09:54, 7 April 2014 (UTC)
11. Support It's useful to have statistical information about other users, but many users will simply not know this feature and not opt in at all. Making the availability of the information the default, but allowing informed users to withhold it for privacy reasons seems a fair possibility. (Thus an "optout OPTION", not requirement. Or did I get something totally wrong here?) G Purevdorj (talk) 15:28, 7 April 2014 (UTC)
12. Support The edits are public, as is the data about them, however if a user wishes to make it more difficult to aggregate that data for whatever reason that should be granted as a courtesy. Prefer no-opt as a second choice. Tazerdadog (talk) 20:22, 8 April 2014 (UTC)
13. Support Who thinks that it will protect them should be able to opt-out these kind of aggregation tools. Opt-out should however be stored on a non-public place to prevent "let's look at people who have opted out". -- Rillke (talk) 11:01, 10 April 2014 (UTC)
14. Support --S Philbrick(Talk) 17:44, 11 April 2014 (UTC)
15. Support I personally have no problem with being opted in, but I see no downside in letting others opt out, as long as it's made clear that the information can be found in other ways. I am ideologically against removing options that some people want and don't hurt anything. — trlkly 23:22, 14 April 2014 (UTC)
16. Support I would prefer opt-out to no opt, but would be willing to accept no opt since it appears the majority are leaning that direction at this point. Opt-in makes the edit counter effectively useless. --Shawn K. Quinn (talk) 17:58, 15 April 2014 (UTC)

Remove all opt requirements completely

1. Support You're not really hiding anything by keeping these tools from working. It's security through obscurity. Anyone could easily write a tool of their own that doesn't honor it at all. Jackmcbarn (talk) 23:56, 3 April 2014 (UTC)
2. Support even though I'm globally opted-in. There is no reason to add a choice here, it's not like anyone can't access this data regardless of settings. Telling people it is opt-in implies that if they don't opt-in the data is secure and no-one can access it, which would be blatantly false. — {{U|Technical 13}} ^{(t • e • c)} 00:13, 4 April 2014 (UTC)
3. Support Even though I never bothered to opt in. Otherwise agree with above comments. PaleAqua (talk) 00:22, 4 April 2014 (UTC)
4. Support → Call me Hahc21 00:24, 4 April 2014 (UTC)
5. Support per Technical 13. I'm opted-in and I respect the desire of others for privacy but if there is no actual privacy we shouldn't pretend there is. Chris Troutman (talk) 00:54, 4 April 2014 (UTC)
6. Support - This is a mechanism for the examination of tendentious editing and abuse of multiple accounts. Transparency is good. Carrite (talk) 00:55, 4 April 2014 (UTC)
7. Support - This is basic information which should be available to every editor for every other editor. Hiding it makes little sense. BMK (talk) 01:02, 4 April 2014 (UTC)
8. Support - Anonymous ticker, the data obfuscated at the public level. No reason to have anyone opt out. --MASEM (t) 01:04, 4 April 2014 (UTC)
9. Support, begrudgingly. I admit there's no way around it but I just don't like it, to be quite frank. Nonetheless, I suppose I've got nothing to hide, I'm just a tad leary about people being able to browse my editing history THAT easily. I'd rather make 'em work for it but I suppose that's not going to happen, so might as well just bite the bullet and get it over with. LazyBastardGuy 01:06, 4 April 2014 (UTC)
10. Support - I genuinely see no benefits to being opt out since anyone anywhere can view your contributions, There's no privacy involved as you're only revealing what you're editing really.. -→Davey2010→→Talk to me!→ 01:06, 4 April 2014 (UTC)
11. Support Since edit histories are public, any information derived from them is likewise available to the world. DavidLeighEllis (talk) 01:09, 4 April 2014 (UTC)
12. Support per above. GenQuest ^{"Talk to Me"} 03:18, 4 April 2014 (UTC)
13. Support - If you don't want people to know what you're doing, don't do it on a website that publicly logs almost every action. Mr.Z-man 03:20, 4 April 2014 (UTC)
14. Support. No one should have (or be encouraged to think they have) an expectation their edit history is private here on Wikipedia. Msnicki (talk) 03:39, 4 April 2014 (UTC)
15. Support – The info is not private in the slightest, and there's no reason we should be treating it as such. TCN7JM 04:10, 4 April 2014 (UTC)
16. It's public information, and anyone can make a tool on labs to generate the graphs, anyway... --Rschen7754 04:14, 4 April 2014 (UTC)
17. Support per Technical 13 above. —Bruce1ee^talk 06:31, 4 April 2014 (UTC)
18. Support -- John of Reading (talk) 07:16, 4 April 2014 (UTC)
19. Support. It's all public information. It could be argued that an opt-in system makes it harder to track one's contributions, since there's no existing tool available, but that's not true - anyone could put together some code for a crawler, upload it to Github, and nobody could do anything about that. -- King of ♥ ♦ ♣ ♠ 08:02, 4 April 2014 (UTC)
20. Support – I see no privacy issue, it's simply an aggregation of someone's editing history which is public information. Also if the German privacy law was the reason for having the optin then that no longer applies.--Wolbo (talk) 08:04, 4 April 2014 (UTC)
21. Support It's available via other means, you're not "protecting" anything by providing an illusion of privacy. —Locke Cole • t • c 09:29, 4 April 2014 (UTC)
22. Support. This data is public already. — Keφr 09:43, 4 April 2014 (UTC)
23. Support. This data is public in every conceivable sense. — Scott • talk 10:55, 4 April 2014 (UTC)
24. Support per Technical 13 and Mr. Z-man above. Elizabeth Linden Rahway (talk) 11:29, 4 April 2014 (UTC)
25. Support per all the opinions above, especially Mr. Z-man's. --Checco (talk) 11:32, 4 April 2014 (UTC)
26. Support – Technical 13 does make a good point – the data isn't going to not exist if you don't opt in. It's still there. By the way, it's about time that usage data became available for IP users, too. Epicgenius (talk) 12:53, 4 April 2014 (UTC)
27. Support per Mr.Z-man; that we should be obscuring publicly available data so that some editors can edit when they shouldn't be seems counter intuitive. Sam Walton (talk) 12:57, 4 April 2014 (UTC)
28. Support When talking about privacy, we need to distinguish between the account and the person controlling the account. That we protect the person's privacy is a given. But it makes no sense to protect the account, Wikipedia is a public untertaking. Also, as has been stated before, opting is ineffective. Finally, opting would make getting potentially useful statistics more cumbersome. Paradoctor (talk) 13:53, 4 April 2014 (UTC)
29. Support Edits to wikimedia sites are public. All this does is make a piechart out of the existing stats that ANYONE can see by clicking on the contributions of any given user. There is no privacy issue. If one imagines that there is such an issue then they should not use wikis--Cailil ^talk 14:05, 4 April 2014 (UTC)
30. Support per Technical 13. --AmaryllisGardener ^talk 14:32, 4 April 2014 (UTC)
31. Support. The information is occasionally useful against sockpuppets and agenda-driven editors, and does no harm to any other editors. Seanwal111111 (talk) 15:42, 4 April 2014 (UTC)
32. Support per others: this data is all public. Michael Barera (talk) 17:02, 4 April 2014 (UTC)
33. Support: To me, having an opt-in requirement only creates confusion without any security or privacy benefits – the stats data is public and other utilities can display them, such as the WikiChecker which even shows daily edit stats and overall daily/hourly breakdowns. Thus, currently there's no "security through obscurity", privacy improvement or whatever achieved by the opt-in requirement. — Dsimic (talk | contribs) 17:06, 4 April 2014 (UTC)
34. Support Per Dsimic right above. Regards SoWhy 19:32, 4 April 2014 (UTC)
35. Support As an opt-in, it's all publicly available data anyway. Whisternefet 19:36, 4 April 2014 (UTC)
36. Support Per others; no privacy issue present. APerson (talk!) 20:27, 4 April 2014 (UTC)
37. Support Not a privacy issue, this data is readily available elsewhere and there is nothing sensitive about the data anyway.Blethering Scot 20:41, 4 April 2014 (UTC)
38. Support -- privacy concerns are bogus, transparency is good. Nomoskedasticity (talk) 21:18, 4 April 2014 (UTC)
39. Support - (a) anybody can already see anybody else's contributions in their entirety as part of the technical and social foundation of Wikipedia; (b) anybody can download everything, including contribution histories which can be analyzed in much greater detail than this tool provides; (c -- least convincing but still relevant) everybody has the choice to edit anonymously if he or she does not want a persistent contrib history. --— Rhododendrites ^talk |  21:42, 4 April 2014 (UTC)
40. Support - Per above, specifically supports 2, 5, 13, and similar sentiments. None of this is secret, and an opt-in/out system only makes it more tedious for people to find the information. Sven Manguard Wha? 22:22, 4 April 2014 (UTC)
41. Sven has it. NW (Talk) 23:07, 4 April 2014 (UTC)
42. Support per Sven. Royalbroil 00:29, 5 April 2014 (UTC)
43. Support let it all hang out. Privacy is the opposite of editing Wikipedia. Jim.henderson (talk) 00:42, 5 April 2014 (UTC)
44. Support All the information is contained inside your contribution page, so preventing this to run is uneeded as it is already show elsewhere TheMesquito (talk) 04:01, 5 April 2014 (UTC)
45. Support There really is no reason to continue hiding this, as the information has been available for as long as we have kept contribution history. Kevin Rutherford (talk) 04:18, 5 April 2014 (UTC)
46. Support There is no privacy issue here since users have already agreed, by editing Wikipedia, that their edits belong to the public domain. All that is happening is that useful and pertinent summary information about editors is being made unnecessarily difficult to access. --Epipelagic (talk) 08:29, 5 April 2014 (UTC)
47. Support Transparency is important. SilkTork ^{✔Tea time} 09:25, 5 April 2014 (UTC)
48. Support I the opt-in redundant. Even opt-out would be better than that. No requirement of opt-in should be ideal. Diptanshu^Talk 10:50, 5 April 2014 (UTC)
49. Support Theres no reason why this should not be here. Its all recorded in the "contributions" anyway.--JOJ ^Hutton 10:59, 5 April 2014 (UTC)
50. Support As with others here, I see the opt-in/opt-out choices as somewhat redundant, given that the data are available anyway. Opting out is only really giving an illusion of privacy, and transparency on a collaborative project like Wikipedia is a Good Thing™. -- Scjessey (talk) 12:51, 5 April 2014 (UTC)
51. Support The opt-in requirement is only there because of Germany's very strange privacy laws, which make no sense at all. —Tom Morris (talk) 13:27, 5 April 2014 (UTC)
52. Support Opt-in requirement serves no useful purpose. Coretheapple (talk) 13:54, 5 April 2014 (UTC)
53. Support Opt-in implies that if they don't opt-in, no one can access their edit activities, which just isn't true. Also, Wikipedia is a public endeavor (at account level), by definition.--FeralOink (talk) 14:53, 5 April 2014 (UTC)
54. Support Transparency in relation to edit stats is hardly too much to ask when we are all anonymous contributors. Sarah777 (talk) 15:59, 5 April 2014 (UTC)
55. Support It's available information, I see no point in making edits less transparent/harder to view sensibly. Dougweller (talk) 16:03, 5 April 2014 (UTC)
56. Support It's available in any event, there's an implicit agreement to it when creating an account. --Richhoncho (talk) 18:22, 5 April 2014 (UTC)
57. Support The information is useful, and is available elsewhere anyway, so it might as well be easily accessible to everyone. MichiHenning (talk) 20:25, 5 April 2014 (UTC)
58. Support - all this information is publicly available. I mean, seriously, look at WikiChecker, which records when you edit down to the hour (note: I'm not sure if that's opt-in or not, actually, since I was opted in before I found that). Compared to that, the information that was opt-in in X!'s editor seems much less "dangerous", eh? ansh666 21:16, 5 April 2014 (UTC)
59. Support Roberticus talk 22:37, 5 April 2014 (UTC)
60. Support per Technical 13 AIRcorn (talk) 01:08, 6 April 2014 (UTC)
61. Support, albeit reluctantly. I opted-in (I have a bit of an obsession with monitoring my edits), but I can understand why some people want to opt-out. Nevertheless, there really isn't anything to hide, and even without the tool, it's still possible (albeit more difficult) to get the needed data. It'd be much easier if the opt-in was just removed entirely. Narutolovehinata5 ^tccsdnew 01:23, 6 April 2014 (UTC)
62. Support I'm not sure how this would cause any privacy issues. Northern Antarctica (₵) 02:21, 6 April 2014 (UTC)
63. Support already by using these wikis you have agreed that what you do is made public. There is nothing really to hide anymore. Graeme Bartlett (talk) 03:23, 6 April 2014 (UTC)
64. Support per Technical 13. There is no expectation of privacy on Wikis, and there shouldn't be. If you attach edits to your real name, you can't have that simply undone. You can use an alias if you'd like, and I imagine that's what most people do. There are contribution pages, watchlists, etc. There is not only the capabilities to aggregate this information outside of Wikipedia, but directly inside it as well. We shouldn't pretend that users should have any expectation that these simple statistics are "private", because they aren't. Those "rights" are already non-existent, so making it opt-out is rather silly. --Nicereddy (talk) 03:45, 6 April 2014 (UTC)
65. Support per Technical 13 and Mr.Z-Man. This information isn't being hidden when you're preventing just one tool from running, when there are other (less convenient) methods of getting this information already. Having an opt-in policy for privacy reasons is the equivalent of locking the front door to a building for security purposes when the building has no back wall. You're not providing security, you're just making it more of a pain by making people walk around. -- Atama頭 04:29, 6 April 2014 (UTC)
66. Support per all of the above. Aggregate public information is still public. Xaxafrad (talk) 08:43, 6 April 2014 (UTC)
67. Support Everyone should be able to see everything from the edit counter when they click on it. By having a "have to opt in" message, people are confused and wonder why they need it. With no opt-in, everyone gets access to everything on the edit counter and no questions would be raised.Springyboy (talk) 10:49, 6 April 2014 (UTC)
68. Support Per multiple of the above statements. Having the ability to opt-out, or requiring opt-in, implies that the data will remain private if the person has opted-out or not opted-in. That provides a false impression to people as to the privacy status of the data. — Makyen (talk) 10:54, 6 April 2014 (UTC)
69. Support For transparency of already public data. Fredlyfish4 (talk) 15:21, 6 April 2014 (UTC)
70. Support Agreed with just about everyone. We shouldn't illude uninformed users that their editing history can be secure and hidden from view. The wiki is by nature open and transparent, and I find it somewhat counterintuitive to imply that isn't the case — MusikAnimal ^talk 15:33, 6 April 2014 (UTC)
71. Support Harsh (talk) 16:43, 6 April 2014 (UTC)
72. Support Int21h (talk) 17:19, 6 April 2014 (UTC)
73. Support The problem with the opt-in or opt-out system is that it favors more technically capable users that can easily get the data and do similar analyses with the data anyways. By making this tool available for everyone to use, this would level the playing field in the edit count analysis process. – FenixFeather ^{(talk)(Contribs)} 20:05, 6 April 2014 (UTC)
74. Support The opt-in / opt-out suggests that there is some sort of privacy option, where we all know that the data is publicly available, should one wish to look for it. Therefore I see no sense in it.  Ronhjones  ^(Talk) 00:15, 7 April 2014 (UTC)
75. Support This is public info, so no need for opting. 2Flows (talk) 01:21, 7 April 2014 (UTC)
76. Support Providing opting options creates the false implication that there are privacy controls. To create such a misleading impression is problematic; let's avoid implied misrepresentation. —Quondum 02:51, 7 April 2014 (UTC)
77. Support. I'd prefer an opt-out option if that option really worked, but since it can't, we shouldn't pretend this level of editor privacy can be maintained. Hullaballoo Wolfowitz (talk) 03:27, 7 April 2014 (UTC)
78. Support Attribution of edits is a feature, not a bug. —Justin (koavf)❤T☮C☺M☯ 04:28, 7 April 2014 (UTC)
79. Support per all the above Sprinkler21 (talk) 04:44, 7 April 2014 (UTC)Sprinkler21
80. Support - I see no reason to add extra hurdles for access to otherwise publicly available information. I don't see this as an issue of privacy, but convenience. Inks.LWC (talk) 04:53, 7 April 2014 (UTC)
81. Support per all above. The data is public anyway, can be looked up without the counter. Zhaofeng Li [talk... contribs...] 05:31, 7 April 2014 (UTC)
82. Support Edit counters do little else then aggregate contribution data that is already available to the general public. There are several off-wiki edit counters that can easily summarize the same data and provide statistics such as by-hour editing breakdowns, most edited pages and about everything else. And as other people mentioned - creating such a tool using the API is quite doable. Excirial ^{(Contact me,Contribs)} 06:19, 7 April 2014 (UTC)
83. Support I would strongly oppose keeping the opt-in. Anasuya.D (talk) 10:05, 7 April 2014 (UTC)
84. Support More transparency makes it easier for the "good guys" and harder for bad actors.Jacona (talk) 11:46, 7 April 2014 (UTC)
85. Support per Technical 13. – Smyth\^talk 12:45, 7 April 2014 (UTC)
86. Support I agree with all the arguments for getting rid of opt-in. If you don't want your edits to be "tracked", you probably shouldn't be contributing to the wiki. — Frεcklεfσσt | Talk 15:31, 7 April 2014 (UTC)
87. Support I agree with Technical 13. I am One of Many (talk) 18:54, 7 April 2014 (UTC)
88. Support as it's simply an aggregator. Why bother? It only creates an illusion that this information somehow remains nonpublic. DeistCosmos (talk) 19:38, 7 April 2014 (UTC)
89. Support Everyone is here voluntarily. If you want privacy, don't post in an open site. Sammy D III (talk) 21:46, 7 April 2014 (UTC)
90. Support - My arguments (I have arrived at without reading all this) are already covered. Staszek Lem (talk) 01:21, 8 April 2014 (UTC)
91. Support. There is no real way to completely hide publicly available information. Also, I've seen an experienced editor try to indict another editor on the basis of the accused's (opted-in) top-edited pages, while the accuser kept his own edit counter opted out, indicating in my mind that the accuser himself had something to hide. I'd rather remove all doubt and all inequality by having everyone and everything out in the open. Softlavender (talk) 05:07, 8 April 2014 (UTC)
92. Support It helps us build up a picture of who the user is. Another good reason is transparency, one of the great things about Wikipedia. What is a good reason against? Privacy? Anna Frodesiak (talk) 10:55, 8 April 2014 (UTC)
93. Support I really can't see the reason why this is an issue. I have opted in to make my edits transparent, I can remember when it was the default. Wee Curry Monster talk 11:37, 8 April 2014 (UTC)
94. Support per all above. Graham87 12:49, 8 April 2014 (UTC)
95. Support—I'm already opted in, but I support the NoOpt idea simply to avoid giving the false impression that opting out does something different or special with one's Wikipedia usage data. It does not. And the data can be easily located other ways. N2e (talk) 14:17, 8 April 2014 (UTC)
96. Support - It isn't impossible for someone to write a script that circumvents the need for xtools and does the exact same thing, which makes an opt-in/out feature useless. With this in mind, we may as well get rid of the opt-in/out and save everyone the hassle of wasting their energy trying to write such third-party tools, so that their productive energy can be placed elsewhere. Nothing is ever kept secret, no matter what means are taken to ensure privacy, which means that we're better off letting everyone have equal capability of accessing this information, as opposed to only allowing an elite few capable of writing tools to hoard the information all to themselves. Furthermore, this project is intended to be open and transparent to begin with; people with something to hide really should be thinking twice about how they edit Wikipedia. --benlisquare_T•C•E 15:08, 8 April 2014 (UTC)
97. Support - There is nothing else that I can add that hasn't been added above already. Tony the Marine (talk) 19:58, 8 April 2014 (UTC)
98. Support - Yes, please remove all opt requirements completely. I've opted-in, but I do not see a reason to give one a choice to opt-in or opt-out, privacy is a hoax here! Anupmehra -Let's talk! 21:56, 8 April 2014 (UTC)
99. Support - Please remove all opt requirements. The information is useful in Wikipedia historical research. →StaniStani  23:26, 8 April 2014 (UTC)
100. Support - WP:100, and more importantly, I've never felt that avoiding the counter provided much true privacy in practice. --j⚛e decker^talk 00:45, 9 April 2014 (UTC)
101. Support: Making the edit counter opt-whatever provides the illusion of privacy, while hiding the fact that there's no real privacy. This is a bad thing. --Carnildo (talk) 00:55, 9 April 2014 (UTC)
102. Support per Graham87...:-)..i.e. I agree with all 101 comments The Herald 10:14, 9 April 2014 (UTC)
103. Support - People have access to the data anyway, seems uncontroversial really. Just makes it easier for all concerned, removes yet another hurdle to greater editor interactions. Acather96 (click here to contact me) 15:45, 9 April 2014 (UTC)
104. Support public data anyway, no reason for us not to be able to access it through multiple tools, Sadads (talk) 15:58, 9 April 2014 (UTC)
105. Support - Since there s no privacy anyway, I see no reason to support experienced users and leave all the others out in the rain Gott (talk) 21:28, 9 April 2014 (UTC)
106. Support Der Wohltemperierte Fuchs^(talk) 22:05, 10 April 2014 (UTC)
107. Support Matt Deres (talk) 23:11, 10 April 2014 (UTC)
108. Support --Ralf Roletschek (talk) 11:55, 11 April 2014 (UTC)
109. Support. Opt-in only provides an illusion of privacy. older ≠ wiser 12:06, 11 April 2014 (UTC)
110. Support - this is public data, there is no privacy. -- KTC (talk) 12:59, 11 April 2014 (UTC)
111. Support after all, it's all public information--anyone can go around checking people's edits manually, but this way is easier for everyone concerned. ;-) —₡lockery ₣airfeld ₰ 09:08, 12 April 2014 (UTC)
112. Support Wikipedia is live publishing after all. Doc James (talk · contribs · email) (if I write on your page reply on mine) 15:28, 12 April 2014 (UTC)
113. Support. I care – a lot! – about user privacy, so I thought about this issue very carefully. What I care about, specifically, is allowing users who so desire to protect our real-life identities while editing – as opposed to, for example, protecting users from accountability for adhering to policies and guidelines while editing. This proposal has no effect on privacy of editor identity. What it does is make it easier to track down information that is already public for those who wish to seek it out, about where a given editor makes edits. Making it easier can be helpful in dispute resolution and in evaluating candidates for additional permissions, but it doesn't make it easier to figure out who an editor is in real life. Someone who never reveals anything about their identity is at no further risk of employer scrutiny as a result of this proposal; the risk only comes if the editor chooses to make it possible for the employer to identify their user name. I always thought that the opposition to the edit counter information in some nations' laws was rather peculiar, and I don't see any harm in making this particular information more accessible. --Tryptofish (talk) 17:12, 12 April 2014 (UTC)
114.    FDMS  4    17:15, 12 April 2014 (UTC): Such tools could be a great replacement for other tools providing less information about the user, and any opting would drastically reduce their usability as either most people would not care about it (opt-in) or there would be unpredictable gaps (opt-out).
115. Support The most likely reason to want to opt out is to protect privacy, but as the information is already available elsewhere, this tool does nothing to impinge on any editor's privacy. Regards, Lynbarn (talk) 19:13, 12 April 2014 (UTC)
116. Support – As per Mr.Z-man. –Tommy Kronkvist (talk) 20:08, 12 April 2014 (UTC)
117. Support – I agree with Tryptofish and I care a lot about data privacy. This is public data and it's about time the opt requirements are completely removed. - tucoxn\^talk 05:54, 13 April 2014 (UTC)
118. Support – If information is public, it is public. The rest all comes down to the failure of Legal "Mind" to understand mathematics and logic. But as pointed out above, giving a false sense of "privacy" is certainly bad. Imaginatorium (talk) 06:50, 13 April 2014 (UTC)
119. Support – This is not private data, and ways of making sense of it will only get more convenient and numerous over time. No use in overly-restricting it. If people are concerned about privacy, then the conversation should be about what information people can *not* share, or what information that is currently public might instead be private.--ragesoss (talk) 11:41, 13 April 2014 (UTC)
120. Support - This information is not private and the aggregation of the information is similarly not private, as has been stated multiple times. If opting in or out is allowed, it should be stated explicitly in the tool that the information is still easily accessible elsewhere. Gamma Metroid (talk) 16:21, 13 April 2014 (UTC)
121. Support - Either the information is public, and you can do what you want with it, or the information is private. In this case, the information is public; all the tool does is makes it easy to look it. Bilorv (talk) 19:35, 13 April 2014 (UTC)
122. Support. the wub "?!" 22:26, 13 April 2014 (UTC)
123. Support. Sensible. Chase me ladies, I'm the Cavalry (Message me) 23:20, 13 April 2014 (UTC)
124. Support.--Bbb23 (talk) 00:42, 14 April 2014 (UTC)
125. Support. Benny White (talk) 23:18, 14 April 2014 (UTC)
126. Support There is already too much anonymity here, and it's what allows the shocking POV bias that makes WP the laughingstock of academia. Gangs with admin friends own articles like IRL gangs own neighborhoods. If editors had to show positive ID, this would turn into a "real" (i.e., authoritative) encyclopedia in a week. As it is now, WP is good for looking up TV show characters and bird species, and useless for any topic that people have political opinions about. Verdana♥Bøld 01:16, 15 April 2014 (UTC)
127. Support All information that should be made open to the public should be made public. We can't hide all information from everyone, and we shouldn't force editors to opt-in without their consent. Disclosing information to the public makes the tool more unbiased and allows anyone to see what he/she should know. Japanese Rail Fan (talk) 14:59, 15 April 2014 (UTC)
128. Support What's there to hide? --Rsrikanth05 (talk) 16:51, 15 April 2014 (UTC)
129. Support A user's edit history is public, and this tool makes it easier to look at. Opt requirements imply a user controls a level of privacy where none actually exists. --hmich176 18:50, 15 April 2014 (UTC)
130. Support - per Technical 13 et. al. - if there is no actual privacy (and there isn't since all editors' editing histories are public), there's no reason to give the false impression that there is. Parsecboy (talk) 19:37, 15 April 2014 (UTC)
131. Support [1] already displays this information for the English Wikipedia. I suppose there could be different rules on the different Wikimedia projects, e.g., if the German Wikipedians would like to have the optin option. Having a WMFlabs tool may yield better privacy because the server logs are under the control of WMF. — fnielsen (talk) 22:50, 15 April 2014 (UTC)
132. Support Gloss • talk 23:04, 15 April 2014 (UTC)
133. Tentative support The argument that this is public already makes a lot of sense, but choosing this option requires some ongoing attention that the tool doesn't retain information that would otherwise be made relatively inaccessible. For example, usernames that have undergone "right to vanish", or deleted contributions. Wnt (talk) 02:31, 16 April 2014 (UTC)
134. Support --Liberaler Humanist (talk) 21:40, 16 April 2014 (UTC)
135. Support per Technical 13 above. Dontreader (talk) 04:43, 19 April 2014 (UTC)
136. Support because it most naturally fits the actual situation. Opt-in or opt-out gives undue weight to the idea that there is an expectation of privacy or obscurity. —EncMstr (talk) 06:07, 19 April 2014 (UTC)
137. Support because it implies you do have privacy, when none such exists. Rilech (talk) 06:35, 19 April 2014 (UTC)

Discussion for edit counter optin

• Still thinking about this. Will look into other votes. ///EuroCarGT 00:02, 4 April 2014 (UTC)
• I believe the reason that this kind of tool had an opt-in requirement to start with was because it was originally hosted on the tools server which was based in Germany, and there was a German privacy law that required an opt-in for this sort of aggregated information (the monthly breakdown in particular). Now that it runs on WMF Labs, in the US - the German law no longer applies. --Versageek 03:31, 4 April 2014 (UTC)

  But abruptly removing the opt-in requirement isn't the right solution. It should be determined through consensus, and global consensus still wishes to keep the optin requirement, so it shall be kept. But this new tool is designed to allow me to easily flip the switch on a per wiki basis.—cyberpower ^Chat_Online 03:37, 4 April 2014 (UTC)

  Yes the law in Germany has had an effect due to the location of the tool server. But the German community wanted that law to be in effect and as a result is very much miffed with the move to WMLabs. Agathoclea (talk) 08:43, 4 April 2014 (UTC)

  German law applies in Germany. If the information is protected, the server could be in orbit, and it would still be prohibited to download the data in Germany. Fiddling with the tool might solve the problem for this particular tool. But if you want to split hairs, you could make a point that user log and edit history present aggregate data. Even WP:POPUPS would require opt-in. If all this really became an issue, the better solution would be to have contributors agree to having their edit history processed in any which way by whoever cares to. Paradoctor (talk) 15:23, 4 April 2014 (UTC)

  It is not just German law but also EU legislation. --AFBorchert (talk) 13:15, 9 April 2014 (UTC)

  We should leave assessing that kind of stuff to actual lawyers, not people on the Village Pump. — Scott • talk 14:24, 9 April 2014 (UTC)

  All activities at Wikimedia projects can easily conflict with the law. We have copyright violations, cases of libel, personality right violations, and also issues of privacy. It is not helpful to attempt to decide these things by majority vote and then, if a pointer is given to related legislation, to claim that this is better left to lawyers. --AFBorchert (talk) 20:29, 9 April 2014 (UTC)

  This is not a clear-cut area like libel or copyright violations. The only people related to this project who are in a position to offer knowledgeable opinions on legal issues of any kind that relate to it are, unsurprisingly, Legal and Community Advocacy at the WMF. If you think there are legal issues here, they are the people to get involved. Presenting links to bits of international legislation to a crowd of non-lawyers is pointless; nobody here can make an informed decision based on that. — Scott • talk 21:47, 9 April 2014 (UTC)

  This is not my problem but the problem of those who are going to remove the opt-in requirement and those who provide the infrastructure for this. It is their responsibility to investigate and evaluate the legal implications of this, not mine. I just gave the pointer to EU legislation at this subthread as the discussion above was talking about German law only. I think it is interesting to know that this protection of privacy covers the whole EU and not just Germany. --AFBorchert (talk) 09:15, 10 April 2014 (UTC)

• Since a notice about this has appeared at the top of my watchlist (and therefore presumably everyone else's), you should provide some links and fuller information for those who don't already know what this is about. At the very least a link to the thing should be provided! You're not going to get many opinions from the wider community without providing this basic level of detail because people just aren't going to bother.  —SMALLJIM  08:56, 4 April 2014 (UTC)
  • It is this tool (here's my count), accesssed by a link at the bottom of your contributions page and enabled as described in the FAQ accessible from here (to opt in create a file User:Smalljim/EditCounterOptIn.js with any content). Thincat (talk) 09:49, 4 April 2014 (UTC)
    • Thanks Thincat. My point is that since this issue is being brought to the attention of all editors, many of whom won't have heard of the Edit Counter before, that detail should be provided as part of the introduction to the discussion. Links to previous discussions would be useful too, as well as some re-wording for clarity. If I'd recently registered an account and tried to understand what this apparently important message was about, I wouldn't get far.  —SMALLJIM  10:27, 4 April 2014 (UTC)
      • I realised you were making a point on behalf of editors generally (and one I agree with). Lack of context increasingly makes it difficult for non-insiders to take part. Not just genuinely technical matters but things like deletion discussions and so on. Thincat (talk) 16:24, 4 April 2014 (UTC)
      • Feel free to modify the explanation to make it more understandable, without changing the context or the question of what this RfC is trying to address.—cyberpower ^Chat_Online 17:06, 4 April 2014 (UTC)
• Comment - One of the points raised in the "keep the opt-in" section is that it is the expected behavior, and making it opt-out or removing the opt completely would conflict with that expectation. Is it technically possible to make "opt-out" the default arrangement for just new users, thus satisfying this concern? -- Scjessey (talk) 15:30, 4 April 2014 (UTC)

  Why new users? If anything it would be the opted out old users.—cyberpower ^Chat_Online 16:20, 4 April 2014 (UTC)

  Perhaps I am not making myself understood. What I mean is that new users should already be opted-in by default, so they can choose to opt out if they wish. I would imagine that people concerned about privacy would prefer this to simply switching the entire user base over. This is only a suggestion, as I myself prefer the transparency of having the full data available for all users. -- Scjessey (talk) 12:48, 5 April 2014 (UTC)

• Change only for new users

This seems fairer to me. Not everyone is a Wikifanatic. I’m sure there are people who have good reasons for not wanting this information easily available, but if they haven’t been active here for a while they won’t even know the change is happening. At the very least, any change should have a long lead time. Personally, I don’t really care, but I think this idea combined with making it simple to opt in would be much more popular. ☸ Moilleadóir ☎ 03:11, 7 April 2014 (UTC)

• The structure of this is defective and prone to mis-use / misinterpretation. The "vote" for optional use is split between the first two choices, thus stacking the deck in favor of option #3. — Preceding unsigned comment added by North8000 (talk • contribs) 18:52, 5 April 2014‎ (UTC)
  • Not really. Besides, even opt-in + opt-out together would fail 20 vs. 56 against no-opt. Jackmcbarn (talk) 19:20, 5 April 2014 (UTC)
  • All 3 options are mutually exclusive. Combining the first 2 wouldn't make any sense, because if it succeeded, then we'd still have to choose between them. And in terms of the effect it would have and people's reasons for their !votes, opt-out is closer to no-opt than it is to opt-in. Mr.Z-man 19:35, 5 April 2014 (UTC)
  • People could be replying with "First choice" and "Second choice" if they wanted. WhatamIdoing (talk) 22:59, 5 April 2014 (UTC)
  • I structured it this way intentionally. So I can see exactly what people want. I will weigh the outcome various ways and come to a decision that hopefully serves everyone.—cyberpower ^Chat_Online 00:37, 6 April 2014 (UTC)
    • This being an RfC, as proposer, how can you expect to close it? - Neonorange (talk) 06:10, 6 April 2014 (UTC)
      • Cyberpower is the one who is in charge of the tool - he will implement the changes (if any) that the consensus dictates. ansh666 07:24, 6 April 2014 (UTC)
      • Additionally, WP:RFC and WP:ANRFC say that anyone can close an RFC when the consensus is clear, assuming that a formal closure is even necessary. RFC isn't supposed to be some heavy-weight bureaucratic process. It's supposed to be a simple request for other people to provide comments. ANRFC wouldn't have such an enormous backlog if people stopped requesting unnecessary closures there. WhatamIdoing (talk) 15:29, 7 April 2014 (UTC)
• @SarekOfVulcan, Herostratus, and Mburdis: I don't think that the HR department theory is an issue, because X!'s counter (and by extension the Cyberpower's new one, since it's the same) only shows monthly counts, not hourly ones - you can't determine exactly when someone was editing from it. ansh666 07:24, 6 April 2014 (UTC)
  • Ah, I was thinking of a different version of the edit counter. Thanks for the clarification. --SarekOfVulcan (talk) 10:22, 6 April 2014 (UTC)
    • Also, @SlimVirgin: see my above comment - people editing at work aren't affected by this specific counter. I do understand the rest of your reasoning, though, just wanted to note that single point. ansh666 19:42, 6 April 2014 (UTC)
      • Hi Ansh, the edit counter shows at a glance, going back years, if someone has been editing a lot and gives a monthly breakdown. It would be an easy matter for HR to find particular months of interest to study more closely. SlimVirgin ^(talk) 19:49, 6 April 2014 (UTC)
• And, related to the above, I've added what exactly the opt-in data consists of in the explanation section at the head of the RfC, so those who don't know now do. ansh666 07:27, 6 April 2014 (UTC)

• The issue is not so much privacy as it is data collection and processing. The raw data is already available; understood. But the tool is value-added, or it would not be useful. It gives fast access to collections of data for rapid analysis. Access to that analysis is what is under review. That's probably why it's an issue under German law. Editors should have a say in how visible these analyses of their work are. It is not only worth their consideration, but not every editor's situation is the same. No-opt is one size fits all, which I think is quite inappropriate in these circumstances. I've opted-in myself, but I appreciate being asked. It's polite, considerate, and non-demanding, which is exactly what opt-out is not. In real life, I have actually chosen not to do business any longer with certain corporations who choose to force issues on their customers. I see no reason why we cannot continue to do better here. Evensteven (talk) 07:33, 6 April 2014 (UTC)
  • I think there's some confusion as to how difficult this data is to compile without the tool. Besides Wikichecker, which gives all the same data and more with no opt-in/out, one can simply download usercontribs data from the API in the XML format, and load it into Excel or LibreOffice, where you can sort by date/title/namespace and get the same results. It requires knowing about the API, and would take a while to do manually for people with more than a couple thousand edits, but otherwise requires no special technical skills or any programming whatsoever. The tool is not doing any sort of complex analysis. I'm sure if you gave the data to some big data analytics people, they could come up with some revelations that probably would be seen as a privacy violation. But this tool isn't that. I disagree that giving people nothing more than the illusion of privacy is actually in their best interest. Mr.Z-man 13:38, 6 April 2014 (UTC)
    • Again, the issue isn't privacy. Your method of producing an analysis sounds easy conceptually, but it takes time and effort to accomplish manually - actually, a fair amount of fiddling around - for each and every query. It would also be a great deal easier for some than for others, depending on technical fluency. But the issue is not difficulty either. The tool is still value-added, and its usefulness is a measure of how much easier and faster it is to let it produce its results than to take alternative approaches. Evensteven (talk) 20:16, 6 April 2014 (UTC)
      • Also I doubt that there are very many users who are even aware that the tool exists. When I did, I immediately opted in. Why not? I don't understand the position that employers will be able to seize on this data. I think that's far-fetched. If an employee wishes to conceal his Wikipedia editing from his employer, he just simply has to not disclose it. What people do in their spare time is their business. If an editor has disclosed his user ID to his employer for some reason, it is a simple matter for the employer to go back through the contribution history to determine what articles he has edited and when those edits took place, on company time or not. So overall the opposition to automatic opt-in is puzzling to me. Coretheapple (talk) 21:09, 6 April 2014 (UTC)
        • It's not entirely transparent to me either. But count me as willing to give people the benefit of the doubt when describing their own situations. If someone says they have a problem, they have one, whether or not they've analyzed it logically. And who says all problems have to be logical? Evensteven (talk) 21:31, 6 April 2014 (UTC) In addition, why the rush to make a change in options here? I say give those who have doubts some time to satisfy themselves about the matter. The whole thing could resolve itself in time, just given a chance to evolve. Push tends to come to shove, and then people's positions harden past reason. Evensteven (talk) 21:36, 6 April 2014 (UTC)
        • Coretheapple, your "users" must mean "the couple thousand editors who have made thousands of edits, just like me". Just during the last month, 130,472 made at least one edit. In the entire history of this counter, only 4,648 editors have opted-in. That means that at least 96.5% of people who edited during the last 30 days did not opt-in. WhatamIdoing (talk) 15:39, 7 April 2014 (UTC)
          • If I made just one edit, I wouldn't opt in either. Hell, for the vast majority of casual users whose work can be observed on one screen of their contribution history, opting in would be pretty superfluous anyway. Coretheapple (talk) 15:58, 7 April 2014 (UTC)
          • You are forgetting the 5,383 editors who have opted in globally.—cyberpower ^Chat_Online 00:59, 8 April 2014 (UTC)
            • True, but I'm also "forgetting" to include couple hundred thousand people who edited at the 800+ other projects in the count of people who made an edit here during the last 30 days, so I suspect that it evens out. WhatamIdoing (talk) 02:09, 9 April 2014 (UTC)
• Given the Future Plans tab showing "What's to be added to the tool"—things that have yet to be implemented—perhaps this RfC is premature. You are asking editors to give blanket approval to possibly more revealing reports, which have yet to be developed. Wbm1058 (talk) 18:37, 8 April 2014 (UTC)
  • Agreed. And make no mistake that the reports are revealing. It's easy for some to produce tools like this, doable but inconvenient for others, not easy for yet others; that is not a level playing field. The raw data is public, but the tools make the reports just as public; that's why they're useful. But there are bad actors in the world, and some editors may be more subject to intrusions or harassments than others. It ought to be up to them to make these decisions about their own conditions. Lack of options lock in one rule for all, and can only influence some negatively. Locking in decisions like opt/no-opt in advance of future implementations can only make later tool expansions more controversial and difficult. It benefits us to be as light as possible with mandates. Evensteven (talk) 19:11, 8 April 2014 (UTC)
    • A vote was asked for. Remove got almost three times the total of Retain and Replace together. Most of voters voiced their opinion. So the discussion continues, possibly ignoring the vote entirely. Sammy D III (talk) 11:57, 9 April 2014 (UTC)
      • Consensus is much more than—and absolutely not limited to—just vote counting. Backers of all three "options" have made valid points worthy of consideration, and possibly changing of opinions. I myself am on the fence between options 1 and 3. Lets let it continue, as there are no emergencies on Wikipedia. GenQuest ^{"Talk to Me"} 13:43, 9 April 2014 (UTC)
        • I understand, and agree, this is all talk. I felt that the process was being discounted after it occurred, possibly because of the outcome. The today guys on top aren't mentioning it, but it's not really a factor there. Option 1 is clearly operationally right, but I've seen a lot of "old boy" stuff, so 3 for me. Thank you for your time. Sammy D III (talk) 14:19, 9 April 2014 (UTC)
          • The meaning of this comment is not clear. Sorry if I'm missing your point, but I can't really tell what it is. But if it's meant to dismiss talk as irrelevant, I would ask, what are other good options? What process and outcome are you referring to? This discussion is still open. And talk converts to action. I'm not just referring to discussion outcomes and official actions that result. People still decide how they are going to react, and what actions they will take in consequence. Internal WP process outcomes do not have the effect of law, but they can alienate. What is the use of anyone trying to force an issue? The whole idea of that is counterproductive. Evensteven (talk) 19:04, 10 April 2014 (UTC)
            • My poor communication skills? I didn't mean to pick a fight, I thought that was the end. There is no direct outcome here, we are talking, correct? The vote was not binding, it was a talking point? I came here to voice an opinion, just as the top of the page asked me to. I thought "perhaps this RfC is premature" and "Agreed" discounted a talk that had been going on, and a vote which did not support their views. Option one would help control this place, but I have seen old editors who know each other supporting each other, so my feeling is to support option 3 as sort of freedom of information. Enough? Sammy D III (talk) 04:20, 11 April 2014 (UTC)
              • Ah, ok, got it. I didn't mean to fight either. Just trying to make sense come out of confusion. Didn't understand the mutual supports here, or mean to discount a discussion (rather the opposite); I don't know anyone here. Evensteven (talk) 04:39, 11 April 2014 (UTC)
                • Thank you, I appreciate your post. "My poor communication skills" is a real ongoing problem, I think I was explaining myself to someone else when you noticed me. I'm clearest when I'm quiet, but have little self-control. And I'm impaired, so if you want to make sense out of confusion, you are so in the wrong place. Also, I didn't mean support here specifically, I'm sure it's happening, but I meant in general. Again, thank you, now please stop wasting your time, find a rational discussion, and enjoy. Sammy D III (talk) 11:56, 11 April 2014 (UTC)
                  • My turn, perhaps, to be clearer. One of my points has always been that it's not a waste of time to talk, even if others are not always being rational, and even to someone who has poor communication skills. All the more so in discussions like this, where one goal is to try to find the sense (hopefully shared in some form of consensus) that arises out of initial confusion. Poor communication skills are just that: a lack of skill. They can be worked on, and improved - and it can be really tough work, so keep trying. Those who are most impaired in communications are not those who do not know how to express themselves well, but those who do not know how to increase their understanding by listening to others. That doesn't necessarily mean coming to agree with the others, but it does mean learning just where they're coming from. From where I sit, I'd say you have a better skill there than some I've seen who can express themselves most precisely. (But I'm not referring to participants in this present discussion.) Communication requires talk (at least in this medium), but talk can also exist without communication. While that kind can end up being a "waste of time", the attempt to talk is not. Communication requires foremost the willingness to listen, to respect the speaker enough to let him or her be heard. That's one requisite of WP's "assume good faith" policy. Communication breaks down when that is absent, such as when one person tries to force an agenda on another (no willingness to listen). Mutual support among those who know each other is generally a good thing, but that support becomes unsupportable when it creates a gang. Usually, there are solid, reasonable points of view on all sides of a question. It's the shutting down of one side through power play that is offensive, and a waste of time, for the reasonable viewpoints don't go away through application of power. That's why discussion is not particularly resolvable through a mere counting of votes. It's so seldom about majorities, either here or in real life (and what's not real about here either?), which is the great underlying problem in the theory of democracy. It's about all those reasonable viewpoints. Resolution comes from weighing them all and trying to come to the best possible way of making or allowing reasons to work in practice. Votes are never enough to tell you that. Part of why I am immediately so suspicious of the efficacy of policies based on "no option" is that they tend to short-circuit reasonable viewpoints. I've listened to reasons here, and understand some more than others, and am willing to respect some of the others I don't understand so well. So I vote not to exercise more power than I have to: meaning opt-in. Your vote is your own, and I can respect that too. But when it comes to communication skills, I recommend staying engaged. Continue to participate. Things are not so bad on your end, and practice makes perfect. Evensteven (talk) 18:17, 11 April 2014 (UTC)
                    • I don't know where this goes, the talks seems to have broken into segments. I had the numbers wrong, but I had the idea. 1: What, other than a moral judgment, is the incentive to offering more information than your neighbor? Is there an actual advantage? Many post their interests, counts, etc., on their user page. If you want to do that, it’s pretty local, but you can get your actions out there, sort of. If you didn’t have this counter option to start with, would you miss it? 2: If you choose to conceal info, even if it’s available elsewhere, it sort of sounds like secret. What are you hiding? Even if nothing, it just looks bad. 3: Why not just give everyone as much privacy as possible? The same info available to all? Maybe some kind of “grandfather” deal is called for, but we are only talking contribs, not IPs or anything, correct? Why not just make the option disappear? Thank you. Sammy D III (talk) 17:25, 12 April 2014 (UTC)

• Discussion from after opt-in #44 (user --Leuchtschnabelbeutelschabe) moved here at request of user SlimVirgin. Evensteven (talk) 21:17, 12 April 2014 (UTC)

1. Two total edits, one on their personal userpage and the other one here. Should I be suspecting that off-wiki canvassing is going on? --benlisquare_T•C•E 05:34, 11 April 2014 (UTC)

   I would have to say yes, there is meatpuppetry or canvassing going on, considering supports 28, 37, 44, 45, and 48 in this section. Sven Manguard Wha? 07:53, 11 April 2014 (UTC)

   @Benlisquare: Special:CentralAuth/Leuchtschnabelbeutelschabe indicates almost 1,000 edits to Wikimedia projects, though... Vogone (talk) 15:12, 11 April 2014 (UTC)

   Vogone: Yes, but how did two German Wikipedia users with very few total and no recent edits to this project, along with three other users that I couldn't find any substantial edit history from, all happen to find this one discussion in such a small window of time? Sven Manguard Wha? 16:25, 11 April 2014 (UTC)

   Ed wrote under "For reference" near the start: "Noting that this has been picked up by the German Wikipedia's Kurier". PrimeHunter (talk) 16:48, 11 April 2014 (UTC)

   dewiki or no dewiki, this is still off-wiki canvassing, and therefore a problem. dewiki is a separate project to enwiki, which means that users are being canvassed from off-site to vote here. --benlisquare_T•C•E 17:28, 11 April 2014 (UTC)

   The page you linked says: "However, canvassing which is done with the intention of influencing the outcome of a discussion in a particular way is considered inappropriate." I cannot see this "intention of influencing the outcome" in this case as the notice was directed to the whole dewiki community (not only a part of it) and obviously, thanks to SUL, every dewiki user who has ever edited this wiki, no matter how often, is in the same way affected by this proposal as all remaining users of enwiki's community. Vogone (talk) 18:17, 11 April 2014 (UTC)

   Also some who have never edited here. –xeno^talk 18:27, 11 April 2014 (UTC)

   From the guideline: "Campaigning: Posting a notification of discussion that presents the topic in a non-neutral manner." - As I wrote in the section above, the message was not neutral. And while anyone who has any edits on enwiki is technically affected, there is little practical effect for anyone with less than a few hundred edits, as their contribution history can easily be browsed manually. Mr.Z-man 18:41, 11 April 2014 (UTC)

   I say count the votes, and pursue meat puppetry (if any), but weigh the discussion properly. WP discussions have more than ballots to go on when deciding issues. And let's not take an attitude that dewiki members are unwelcome here. Cross-wiki editing is perfectly acceptable, even if pursued lightly; only meat puppetry is not. enwiki members need always to be aware of how international the "English" language has become - much more so than any other language in history, even Latin or Greek. What is done here does have wide impact, beyond our own borders. That doesn't preempt us from decision, but it does give reason for some level of influence to come from those who might be considered normally "outside". Let's also be frank that laws and lawyers do not have good answers for the problems presented by an international project like this. "Jurisdiction" is just not something that can reasonably be applied in the older senses of the word. And if laws (US, German, or any other) can't become reasonable in practice, they'll just create problems themselves. But we can still attempt to be reasonable, about all these things. Evensteven (talk) 18:59, 11 April 2014 (UTC)

   (edit conflict)It does not matter how "easy" it is to browse their contribs history, and furthermore this is completely subjective. Also users with only a few edits to this wiki and their feeling of privacy should be respected, regardless how they got informed about this discussion. And that other communities weren't informed about the possible impact this discussion has to their privacy (I know, this point is disputed) is rather the problem of this proposal's initiators than dewiki's (or any other wiki's). Vogone (talk) 19:10, 11 April 2014 (UTC)

   It's not subjective at all. Someone with only 500 edits can have their entire history displayed on a single page of Special:Contributions or downloaded in a single API query. For someone with 10000 edits, it is objectively harder to review their editing history without the help of automated tools simply because it is beyond the technical limits of being able to easily browse it. Mr.Z-man 20:55, 11 April 2014 (UTC)

   Obviously. That's hardly the issue. Evensteven (talk) 22:02, 11 April 2014 (UTC)

   Right, the real issue has nothing to do with practical matters and is mostly based on hypothetical situations. We wouldn't want to drag any logic into this debate. Mr.Z-man 22:29, 11 April 2014 (UTC)

   Issues (plural). Hypothetical? Oh, that's "situations", not "issues": as defined by whom? "Logic"? As in "reason"? And again, as defined by ... Yes, I get it. Temper, temper. Evensteven (talk) 07:14, 12 April 2014 (UTC)

   What a bother! What unreasonably narrow reasoning! What is called for is not more of such logic, but more understanding, and more breadth. Evensteven (talk) 07:54, 12 April 2014 (UTC)

   This "technical limit" seems to be at 5,000, so all users with less than 5,001 edits can have their edits monitored on a single Special:Contributions page. Vogone (talk) 16:06, 12 April 2014 (UTC)

   Anyone with access to the Tool Labs replica database can get everything in one query like select * from revision_userindex where rev_user_text="Vogone". πr² (t • c) 18:47, 17 April 2014 (UTC)

   Are you sure you're not the one who doesn't understand? I see at least 6 people supporting this section explicitly saying that it is about easy access to the data (2,6,20,37,45,49). There are 6 people using the hypothetical "it might be against EU law" argument (31,32,39,45,46,50). And there are at least 15 people explicitly saying it is about privacy (1,3,4,5,6,9,10,12,14,16,17,23,26,27,35). But according to you, none of those things are the issue. Should their opinions therefore be discarded by the closer? Mr.Z-man 13:55, 12 April 2014 (UTC)

   Do you mean me? I was only trying to state reasons why we should notify users mainly active in other communities and why we shouldn't discount their opinions/votes in any way and furthermore to disprove your ""practical effect" argument. I'm sorry if I failed with my attempt. Vogone (talk) 16:06, 12 April 2014 (UTC)

   No, I was replying to Evensteven, who is arguing that this isn't about privacy or anything to do with how hard the data is to access even though that's what half the people supporting it are saying. Mr.Z-man 16:31, 12 April 2014 (UTC)

   No, I'm not sure (that I understand). Why are you so sure that you do? I'm not arguing with your technical analyses. They're quite correct, and not difficult to understand. What's the problem you're having with the fact I don't agree with half the people supporting opt-in (about privacy, that is)? Is that required? I do agree with others that ease of access to the editing analyses matter. Yes, there are some also who are concerned about laws and how they can follow them. For some, there can be consequences for non-compliance there, agreed? Isn't that "legitimate" as a concern? Can't I say so too, even though it wouldn't affect me? The laws are bogus attempts to address social concerns in a medium they don't understand and can't control. But can't I recognize and appreciate the significance of the social concerns (for privacy) themselves? I have those myself, though I think they are of only limited (but important) application to opt-in. So, you mischaracterize what I'm saying; poor listening, or narrow reasoning, or something else, I challenge it. You're secure when dealing with technical specs and statistics. You neglect, however, to remember that you're dealing with people. The real issues are not technical; they are human. We're working on deciding how to manage the impact of technology in human life in just one more scenario. That's made more complicated by misapplied attempts to exercise power (such as certain laws). It's also a misapplication of power to discount the opinions of others. I challenge it. And it's narrow to try to pigeonhole people through misapplication of statistics. I challenge that too. Supporters of X or Y or whatever don't have to be homogeneous in opinion. There are plenty of votes for no-opt that agree with me about this. Nevertheless, I see no-opt, and even opt-out, as misapplications of power, simply because there is no pressing need for any application of power here. That power limits, unneccesarily, the flexibility that is due to free people to make their own choices. Take the flexibility away from people who are already confronted with problematic forcing, and you are certain to alienate some. It's about people. WP is about people. People are the single resource that make it go. English people, American people, German people; we're international here, even though we share a language. People can be frustrating at times, can't they? You're welcome; glad to oblige. But not to tweak you; only to insist that you're missing the point. Evensteven (talk) 19:29, 12 April 2014 (UTC)

   Hi, would you consider moving this to the discussion section? I tried collapsing it, but I messed up the count so I reverted. One or the other (move or collapse) would be appreciated. SlimVirgin ^(talk) 19:53, 12 April 2014 (UTC)

   One more clarification. Just because privacy is not an issue for me does not mean it cannot be for others. I cannot speak for others' situations, and neither can anyone else but them. Regardless how public the raw data is, the processed data is not, and "it's easy to write a program" is only true for those who know how - not nearly a universal. That may be my opinion, but not mine alone. Arguing against the opinion so as to dismiss what others say about their situations is also a power play. Unacceptable. This issue too is human, not technical. That is why no-opt is an inappropriate and unhelpful application of force or power. Evensteven (talk) 07:24, 14 April 2014 (UTC)

   I disagree about your characterization of "power" here. Setting aside the fact that a tool with no opt requirements already exists making this whole discussion really academic, as you say, access to the data is easy for those few who know how and hard to impossible for everyone else. So we currently have an imbalance of power. Allowing everyone equal access would put everyone on equal footing. Wikipedia works not just because of people, but because of it's openness and transparency. So decisions on things like this cannot be fully decoupled from the technical or human aspects. We need to balance what people might want with the principles of the project. Mr.Z-man 12:49, 14 April 2014 (UTC)

   There are power techniques to discussion, not desirable on WP. There are also power policies - those that make decisions for people. And there are laws, which exert power over all who are required to obey them. My argument is mostly about what level of power is appropriate to dealing with this technical matter - and I've been saying pretty much that the situation is stressed in this regard, from outside of WP. We need to balance not just what people want, but what people face when they want to edit on WP. We need to recognize that WP policy does not operate in a controlled environment, but out there in the world, internationally. It's not just laws either; consider work situations. Employers have legitimate concerns, but some of them also think they have the right to abuse the power they already have over employees, and surely some editors here face that situation. I think, for WP's benefit, we need to do what we can to encourage people to do editing, so if that means giving them a choice where possible, and where they may feel strongly about it, why should we instead produce a mandate that can only make them hesitate? I think allowing opt-in here is a very minor matter with regards to "the principles of the project". I've never heard of wikichecker myself, just as some here had never heard of this tool. The existence of a tool is not enough to make "this whole discussion academic"; that's overreach, because access to a tool begins with awareness of it. Though wikichecker may have no opt requirements, that's not equivalent to this tool, and different tools may do different things. Even here, we're deciding about opt-in to the new data collections of this tool, the ones that go beyond what X's did. There is no way to put "everyone on an equal footing", even with regards to the tools here, much less in people's life situations. I agree that openness and transparency are important WP principles, but WP also permits editors to hold back personal details and identifications, on user pages and elsewhere. There is respect for privacy on WP, even if it cannot be absolutely guaranteed. These two things can be at odds with each other sometimes, and need to be kept in balance themselves. This tool and others like it are useful for checking up on suspected miscreants. That's a legitimate balance point for allowing their existence and use. But they can certainly be used by miscreants for unacceptable activities like outing. I have sometimes used X's tool to explore other users' level of contributions here, to find out who's more experienced, and in what activities. And I've looked at editing histories of some whom I've edited articles with, looking for other points of shared interest (which has led me to other interesting areas, by the way). The point is that there are tool uses, and then there are tool uses of another kind, and tools don't care about kinds, and neither do policies or mandates. But as with personal data on a user page, I don't think we have a right to assume that all types of tool use are acceptable just because of underlying openness and transparency of editing records. Balance is tricky to achieve. For a place like WP, not even very bright legal minds have yet conceived how to do it in their field of expertise. For us, I would still argue for the lightest possible touch. First, do no harm. Evensteven (talk) 16:56, 14 April 2014 (UTC)

   You're correct that Wikichecker is not equivalent to this tool - it currently gives far more information than the UAT does or plans to do. The UAT gives monthly stats, Wikichecker breaks it down by hour and day of week.

   Now you're basically just setting an arbitrary line. Why does "do no harm" only apply to tools that aggregate the data? Why not go the logical step further and restrict access to the data itself? It just seems silly to say "We'll give you the data, but you're not allowed to do any analysis on it, because that's private." How do you turn public data into private information? And of course, it just works on the honor system. There is literally nothing stopping "miscreants" from doing their own analysis or using one of the unofficial tools like Wikichecker. It's like the gun control argument in the US: "If you make owning a gun criminal, only criminals will own guns." This will hamper good faith users trying to abide by the rules far more than it will deter anyone who is determined to out an editor.

   The difference between this and personal information on a userpage is that personal information can actually be kept reasonably private. Unless you use your real name or associate your real name with your username somewhere, there's nowhere someone can go to look that information up and they can't definitively derive it from the public data we do provide. With this tool, there are other places where one can look it up, and it's just an aggregation of data we provide. Mr.Z-man 19:09, 14 April 2014 (UTC)

   My line is not arbitrary; it's just mine. I have limited myself at this time to directing comments to this tool. I don't know what Wikichecker does; I can't be "right" about it, except to know it's a different tool and it therefore can do different things, or act in different ways. But the principles I speak of can still apply elsewhere. One is to let each editor set a line: opt-in.

   Don't be so binary. The trouble with black and white is that there's no color to it. I didn't say "you're not allowed to do any analysis", and certainly not "because it's private". To me, this sounds obtuse, but perhaps you're simply struggling to gain perspective. To do that, you have to look outside the box you keep trying to cram the discussion into. Of course I'm talking about an honor system; no there is nothing here to prevent miscreants. We are backed up, of course, by the degree of transparency already fully available. We work that way all the time; it's called editing. And we circumscribe the freedoms by jointly protecting the project when it comes to that. The US gun control argument is irrelevant, mostly because it's designed only to be argumentative, not to try to resolve anything (one of many such, on both "sides"). I am not interested in putting up barriers here to deter misdoings; that's already covered in policy. So, "it just works on the honor system"? What a great idea! And let's keep things that way on WP, doing only that policing that we have to, lest we be forced to live yet further behind the barricades. Lastly, "just an aggregation of data"? Do you really believe that, or is the repeated use of "just" a habitual way of dismissing something? Raw data is mostly useless. It's only when we go sifting it, tracing, aggregating, analyzing, noticing patterns, noticing predominances, and more, that it yields something useful - which is called information. Tools help do that work. Making the production of information easier is lifting stuff that can be used out of the dark corners where it hides. Everyone here has access to the dark corners; knock yourself out. But keep a rein on the tools. Don't ban them, but be watchful, lest miscreants foul up the honor system. And let people assess their own risks and opt to limit the candlepower (insofar as may be) that can shine into the dark corners. And you can apply that to all the tools, if you like. Think "permission" rather than "security". There's never any of either one when the jack boots arrive. Evensteven (talk) 00:27, 15 April 2014 (UTC)

   Yes, I think this is just a simple aggregation of data. This tool does not do any sort of complicated analysis. As I said elsewhere, it's no more than you could trivially do with a spreadsheet. I'm sure if you gave editing data to some Big Data researchers, they could come up with some things that might actually be concerning in terms of exploitability. But knowing that someone made 402 edits to the Wikipedia talk: namespace in July 2013? That's basically just trivia. Maybe useful for an RFA or something, but it certainly doesn't tell you anything about the person behind the account.

   I don't need "perspective," I need "reason." I just need to hear a logical explanation of what the actual benefit is. We seem to be in agreement that this doesn't really increase privacy, nor does it deter "bad people" from getting access to the data. And it can have some small impact in reducing transparency. So what then does it do? Is it just a feel-good thing? Should we do it just because people want to do it, and we should support the people? Mr.Z-man 01:37, 15 April 2014 (UTC)

   You need perspective before you can begin to reason. You're rehashing your opinions, which I have already addressed. If you don't want to understand what I'm saying, not listening is a good start, but that's your business. I'd say we can agree to disagree, except that would imply the end of a discussion. This however, has become just an argument. For others' benefit, I would repeat that opt-in is beneficial because it fails to force an issue that does not need forcing. Failing to do is what it does. Yes, that is supportive. But no, it's not about catering to what people want, as I said before. It's about respecting their different situations in a way that encourages participation here, even if they are in a minority, even if your concerns are not the same as theirs. It is collaborative. And it is congenial also. It is not harsh. Feeling good may result, or maybe not, but that's an aside. Logic is a tool that requires skill to use correctly, but even then it is not a panacea. People need and deserve consideration also. If that's no benefit to Z-man, I'm sorry to hear it. Even then it would still benefit Wikipedia. Evensteven (talk) 07:13, 15 April 2014 (UTC)

   It's not clear to me why you believe that "respecting their different situations in a way that encourages participation" requires opt-in rather than opt-out. WhatamIdoing (talk) 15:15, 15 April 2014 (UTC)

   Opt-in gives each editor a choice, a little piece of control, out of respect for the idea that each knows best his or her situation, and what the impact of that choice has in that one life. We, from a distance, are not in a position to judge (and why should we anyway?). About all we are capable of is examination of the technology. That does not therefore make us capable of assessing its impact. But no-opt says that we can, we know better, we know best what is good for you, even if you say otherwise, over the top of your strong concern. Now, there are times when an organization needs to make choices like that anyway, for the purpose of being able to organize itself. But this is not the situation here. Giving the editor the choice will do WP no harm, and it will do the editor no harm. If an editor can see a sufficient organizational reason for that policy, they might find a way to live with it; if they can't, they may consider themselves steamrolled, which is not encouraging. The problem with no-opt is that it does too much, assumes too much, and governs too much, all where it is not necessary. Opt-out is highly akin, in that it makes the initial choice for all users who have never had the opportunity to assess the impact for themselves. Few enough even know of these tools, and newbies certainly won't, and won't yet be very able. And it gives no time to think it over, either. Evensteven (talk) 17:08, 15 April 2014 (UTC)

No, opt-in gives each editor the illusion of a little piece of control over data they opted-out being ever being private by participating in a globally logged public system. It's also deceptive. People who genuinely believe that an opt-in feature makes their data "private" will be pretty upset when they discover the existence of something like WikiChecker. We shouldn't be putting them in that position. The answer is to ensure that all editors are aware from the get-go that there is no concept of private data involved in the normal course of Wikipedia editing. If you don't like that, don't edit. — Scott • talk 22:52, 18 April 2014 (UTC)

Well, I've said above that privacy is not the real concern, but that "public" data is "in a dark corner" until it is mined and made useful, and a mining operation (which this tool is part of) increases exposure. I think it's the representation that there is no change in publicity that is deceptive. Some element of control over the exposure is not illusory. And why is it the business of one (or more) editors to try to teach other editors their role or options here? This is a community of colleagues, not a classroom, so don't presume so much on your own perspective. I accept that you have your position with regards to tool options, not your attitude toward editors, and hence not your reasons. Evensteven (talk) 00:26, 19 April 2014 (UTC)

• Minority Report: It has become rather typical for most Wikipedia communities to disregard the concerns of minorities. If the opinions and feelings of minorities would play a role, opt-out would be indispensable, opt-in the sensible thing to do. But what is the only Wikipedia option? If you don't want it: right to leave. Even if it were only one single serious author who finds out about that tool and as a consequence leaves the Wikipedia, this silly useless gimmick wouldn't be worth it. -- HvW (talk) 00:41, 15 April 2014 (UTC)

  I rather hope you're wrong about how typical it is here to disregard the concerns of minorities, though I have had occasion to see it also. The right to leave is equivalent to "my way or the highway". A "silly useless gimmick" here? I don't know. It's not a big drop-dead issue, in my view. But I think it's always worth it to say that discussions are not battles, and votes are not about winning. Winning happens when people can get along with each other, and find a way to work together. Sometimes that means catering to a minority. Does it here? I can't know that for sure; I can only remind that it is a possibility. Isn't that undemocratic? Yes. It's not the way democracies work; it is the way republics work. Whatever the tool decision here, let's remember that WP needs balance in everything it does, especially in editing. Competition is so overrated. Evensteven (talk) 07:13, 15 April 2014 (UTC)

• I am in favour of openness on Wikipedia, but if people have made edits thinking that the statistics would not be shown, it's not fair to start showing them. Why not display all of the statistical data in the future, and provide an option to opt in to have data previous to the implementation date be included in the report as well? If everyone were informed of the change, they could edit accordingly. —Anne Delong (talk) 14:05, 15 April 2014 (UTC)
• I support keeping to the decision made on meta. Privacy matters. The arguments about "security through obscurity" / "anyone could get the data anyway" are irrelevant, because this tool makes trivial a non-trivial task. And you could justify almost any public spying and data aggregation that way. Germany has strong privacy laws around this sort of thing because they know firsthand just why it's so important. Opt-in is an important principle. As for the privacy violation in particular, the most revealing is the list of most-edited pages. Also I should think that to change from the decision made on meta should require consensus (as opposed to a decision made by vote, which is a terrible habit that we should eliminate). ··gracefool☺ 11:01, 16 April 2014 (UTC)
• This RfC is going nowhere, which was entirely predictable. Who's going to step up to the plate and produce a comparable tool that doesn't offer an imaginary option of privacy and thus demonstrate how pointless this is? — Scott • talk 22:59, 18 April 2014 (UTC)

  How many times have I heard this complaint, only to have it disproved? The discussion is "going nowhere" because there continues to be a difference of opinion? Maybe it's somewhat predictable that the differences will continue. If so, is that not something useful for a discussion to prove? And does that not also indicate that a cut-and-dried approach will not represent a solution? Differences of opinion are not the end of the world! It's important for people to cooperate and give each other some latitude when they do disagree. Otherwise it's "my way or the highway", it's anyone's guess which obtuse side will end up traveling, and the whole communications transport system becomes clogged with wrecks. Evensteven (talk) 00:26, 19 April 2014 (UTC)

Kurier report

• • • Noting that this has been picked up by the German Wikipedia's Kurier. Ed ^{[talk] [majestic titan]} 20:27, 9 April 2014 (UTC)
      • While it is acceptable to notify and inform editors of ongoing discussions, the closer of this RfC should take into account the possible effect of this particular notification on the outcome of the RfC in view of the guidelines on canvassing, particularly WP:Votestacking.--Wolbo (talk) 12:10, 10 April 2014 (UTC)
        • While I'm not a native German speaker, based on Google Translate, it doesn't look like a particularly neutral message: "The traditional privacy-friendly German-speaking community should participate, if necessary, to continue to make their voices heard." Mr.Z-man 12:46, 10 April 2014 (UTC)
          • For the record, the German Wikipedia's Kurier says of itself it's not necessarily neutral, not encyclopedic. It is a forum of expression free to every user. The notice in the Kurier was intended to urge users to take part in this vote which expressly draws on another vote that was held on Meta-Wiki about a year ago. Indeed, most of the German-speaking community have a strong feeling that privacy matters and that every move in Wikimedia projects that could touch privacy should be averted. So they should be informed about this development which matters to all Wikimedia users. Privacy is a civil rights issue, and it may well be that the American and the European stand are clashing here as they are, e.g., in the NSA/Snowden scandal and on the business big American companies such as Google or Facebook are doing with out personal data. Most of us are rather critical of this and want to hinder Wikimedia projects from becoming just another data-collecting project you cannot trust and you will, thus, not take part in. But English Wikipedia is there for all of us, it is not confined to one single language community, so we all have a say when it comes down to our personal data. This is no canvassing, or votestacking, as everyone is able to make his mind up and to decide for himself whether he takes part in the vote and which sides he takes. I have just made this clear in the discussion on dewiki.--Aschmidt (talk) 14:24, 10 April 2014 (UTC)
            • Germans are more in favor of privacy, but it doesn't mean that all Germans are like that. I'm German, and I'm impartial about it. I would also appreciate if this discussion was held in the discussion section below.—cyberpower ^Chat_Online 18:22, 10 April 2014 (UTC)
              • Unfortunately Aschmidt's comment above only confirms that the posting in the Kurier was a case of WP:Canvassing (votesstacking). Per the guidelines "Votestacking is an attempt to sway consensus by selectively notifying editors who have or are thought to have a predetermined point of view or opinion (..), and thus encouraging them to participate in the discussion.". That is exactly what has happened here. Aschmidt states that "everyone is able to make his mind up and to decide for himself whether he takes part in the vote and which sides he takes". That is of course completely correct but it is not relevant in determining if votestacking has occurred. One only has to look at the actual voting between the moment the post was made in the Kurier and my post above drawing attention to it to see that the votestacking had its intended effect. --Wolbo (talk) 14:00, 15 April 2014 (UTC)
        • Make their voice heard does not equate to vote-stacking. It is important for those of us who have experience and expertise, as well as strongly held, well informed beliefs, to "make their voice heard". Inviting contributions of German editors, or editors from the EFF, or the ACLU, should be applauded, if these people have something to add to the discussion. All the best, Rich Farmbrough, 22:24, 18 April 2014 (UTC).
          

Closing the RfC

I'm wondering if we should discuss how to find a neutral admin to close the RfC when the 30 days is up, and perhaps three. Perhaps people here could suggest admins, or we could ask someone to volunteer? SlimVirgin ^(talk) 22:01, 11 April 2014 (UTC)

I asked WJBscribe, a bureaucrat, if he'd be willing to close it, and he has agreed (permalink). He can probably decide himself nearer the time whether he wants to involve others to help him. I hope this is okay with everyone. SlimVirgin ^(talk) 23:06, 12 April 2014 (UTC)

I'm OK with it. I will simply implement consensus.—cyberpower ^Chat_Online 19:25, 14 April 2014 (UTC)

Just noting that Cyberpower and I have had an exchange on his talk page about WJBscribe closing it. SlimVirgin ^(talk) 22:11, 14 April 2014 (UTC)

Like

Proposing the addition of a "like" button as in the social media world. In that regards, one should be able to "like" a post (or edit), especially in back page discussions.Lihaas (talk) 06:26, 14 April 2014 (UTC)

• Please read Wikipedia:Perennial proposals#Share pages on Facebook, Twitter etc.
• How does this differ from the "thank" button on page histories and diffs that you've been using? WhatamIdoing (talk) 19:53, 14 April 2014 (UTC)

Well its like a discussion for deletion, etc that one lends suipport to instead of writing "per X"Lihaas (talk) 13:50, 15 April 2014 (UTC)

"Per X" isn't bad if used correctly. Let's say I'm in an AfD for some article and I want to !vote Delete. If User:Example has listed the six policies and guidelines I want to cite, it's not really a big deal to put "per Example" rather than "per WP:GNG, WP:NBAND, WP:SOAP,...". The problem's with people who don't think and just go "Okay, Example's argument sounds good, let's just go with that", but condemning all "per" arguments because of that isn't the way to go. Supernerd11 :D Firemind ^_^ Pokedex 14:06, 15 April 2014 (UTC)

Lihaas, it sounds like what you want is for everyone else to know that you {{like}} the post, rather than just the person who wrote it. I don't really like this idea myself, but even if I did, I'm not sure how it could be displayed usefully. WhatamIdoing (talk) 14:48, 15 April 2014 (UTC)

I think it could be highly relevant when determining a consensus via otherwise silent parties. There are plenty of people who read discussions but don't contribute. There have been times I've not bothered entering a discussion because it appears the result will be favourable to my desired outcome. On that basis, I would say it should be proposed as a "Support"/"Oppose" function. SFB 20:07, 17 April 2014 (UTC)

Workflows involving Support/Oppose !votes should become much easier to contribute to once Flow has grown up. I think we should wait with designing any new features in that area until the new framework is done. — HHHIPPO 20:31, 17 April 2014 (UTC)

• Strongly oppose. Please, please, don't turn Wikipedia into Facebook. It is not appropriate to have automated edits for weighing in on proposals. These are not votes; each person who supports or opposes a proposal is supposed to give the reasons for his or her opinion, and the result is not counted, but rather the arguments are weighed. If an editor doesn't care enough to type one sentence, or hasn't thought out the reasons behind his or her opinion, then silence is the best policy. This idea, however, is not as objectionable as the "thank" button, because at least it is a public affirmation, unlike "thank", a behind-the-back one, through which editors can privately encourage behaviour which they wouldn't publicly endorse. —Anne Delong (talk) 02:51, 18 April 2014 (UTC)
• Strongly oppose, per Anne Delong's "These are not votes; each person who supports or opposes a proposal is supposed to give the reasons for his or her opinion, and the result is not counted, but rather the arguments are weighed". It's bad enough when some editors think that issue decisions are made by election (vote-counting). It would be even worse if they devolved into a popularity contest. Sounds anti-social to me, a contrivance to diminish thoughtfulness in discussions. Evensteven (talk) 03:07, 18 April 2014 (UTC)

Do you not see the irony in that your response is merely a support of what Anne Delong said without developing the argument further? By the same logic, "per editor X" statements do not have value. It is obvious that discussions do take into account the volume of support for one user's argument. I've never seen a discussion resolved in favour of one user's well-argued point if there is a mass of less-well-argued opposition. SFB 12:49, 18 April 2014 (UTC)

I see nothing wrong myself in the "per" arguments if another person has the same reason(s) for supporting or opposing a proposal that you do. I would not like to see lot of people clicking a button that just adds "Support" or "Oppose" without reasons, and if they have to make another edit to add reasons there is no time savings. Also, by restating an argument in your words you not only show that you understood it, but you may help make it clear to someone else. I also don't think "like" should have anything to do with proposals. There are many proposals and arguments that I like, but they don't follow Wikipedia's policies, so I can't support them. —Anne Delong (talk) 00:10, 19 April 2014 (UTC)

Including edit summaries in a view of a multiple edit diff

This proposal has to do with the visibility of edit summaries in a diff. As far as I know, it is not possible to view all edit summaries when viewing multiple consecutive edits. Only the first and last summaries are included at the top of each column. That is sometimes inconvenient, since many times an edit summary has significant content. If it was possible to include the summaries, perhaps in the body of the right-hand column (inconvenient in many cases) or in its own column (as an option that replaces the left-side column?) or appearing over a selection by moving the mouse over that part of the text (best but hardest to implement), I think it would be very useful in understanding other editors' changes. --Ring Cinema (talk) 14:54, 15 April 2014 (UTC)

RfC: Change of images in Location map Israel and related templates

Please comment at Template talk:Location map Israel#RfC: Change of images in Location map Israel and related templates. Jackmcbarn (talk) 18:40, 15 April 2014 (UTC)

Completing works in progress for User:Cindamuse

Dear friends,

Like many editors, User:Cindamuse had a collection of drafts, works in progress in userspace or draft space that she wished to eventually get in shape to move into the encyclopedia. These are listed at User:Cindamuse/Workshop. I am sure that any one of us would hope that our untimely passing would not result in such work going to waste, so let's get these drafts finished and moved into our encyclopedia.

Cheers! bd2412 T 00:46, 17 April 2014 (UTC)

Keeping additional information helpful for extracting data (e.g. from list) within Wiki articles

Note, I fished this out of the archive. It was removed after only 5 hours by a bot: https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_%28proposals%29&offset=20140402201928&limit=500&action=history SebastianHellmann (talk) 08:30, 17 April 2014 (UTC)

Hi all, we are currently thinking about parsing lists and tables within Wikipedia to extract the information. Well it turns out that this is a really difficult task. The only feasible solution seems to be to keep some extra information, e.g. in List_of_Nazi_concentration_camps column one is the "name as article URL", 5th column is a date range, 6th column is a number signifying "estimated total number of prisoners during the complete in use time (5th column)". What do you think is the best place to keep such information? Maybe a subpage List_of_Nazi_concentration_camps/data ? or an invisible template/comment? What do you think? This could be a GSoC project for DBpedia [2] SebastianHellmann (talk) 15:08, 4 March 2014 (UTC)

ah yes, before I forget. this is the current state. Here is the query that gets geocordinates of all concentration camps [3] . Auschwitz is missing. With the additional information we could improve the results of the DBpedia database a lot in terms of precision and coverage SebastianHellmann (talk) 15:14, 4 March 2014 (UTC)

Nope; the previous discussion was up for eight days. Graham87 08:43, 18 April 2014 (UTC)

Create a MediaWiki:DebugInfo.js

This javascript interface could be very useful for submitting a debug info to gadgets developer pages. Some scripts like wikEd have this thing already bundled, but for others this would be very necessary, instead of implementing it directly to script. Developer could create a button/link for easy debug info by using the &withJS param (example: en.wikipedia.org/wiki/Article&withJS=MediaWiki:DebugInfo.js) It should print the following things:

Sample debug info

• Date: 2014-03-13 21:23:17 UTC
• Browser: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Win32)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.23wmf17
• Gadgets: Gadget-UTCLiveClock.js
• MediaWiki scripts: Common.js/edit.js, Common.js/secure_new.js, RefToolbarBase.js, RefToolbar.js, RefToolbarMessages-en.js, RefToolbarConfig.js
• Scripts: https://bits.wikimedia.org/static-1.23wmf17/extensions/CentralAuth/modules/ext.centralauth.centralautologin.clearcookie.js, https://bits.wikimedia.org/static-1.23wmf17/resources/jquery/jquery.byteLength.js, https://bits.wikimedia.org/static-1.23wmf17/resources/jquery/jquery.client.js, https://bits.wikimedia.org/static-1.23wmf17/resources/jquery/jquery.cookie.js, https://bits.wikimedia.org/static-1.23wmf17/extensions/CentralNotice/modules/ext.centralNotice.bannerController/bannerController.js, https://bits.wikimedia.org/static-1.23wmf17/resources/jquery/jquery.json.js, https://bits.wikimedia.org/static-1.23wmf17/resources/jquery/jquery.mwExtension.js, https://bits.wikimedia.org/static-1.23wmf17/resources/jquery/jquery.ba-throttle-debounce.js, https://bits.wikimedia.org/static-1.23wmf17/resources/jquery.tipsy/jquery.tipsy.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki/mediawiki.Uri.js, https://bits.wikimedia.org/static-1.23wmf17/extensions/UniversalLanguageSelector/resources/js/ext.uls.init.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki/mediawiki.notify.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki/mediawiki.toc.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki/mediawiki.util.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki.api/mediawiki.api.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki/mediawiki.Title.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki/mediawiki.user.js, https://bits.wikimedia.org/static-1.23wmf17/extensions/UniversalLanguageSelector/resources/js/ext.uls.preferences.js, https://bits.wikimedia.org/static-1.23wmf17/extensions/UniversalLanguageSelector/resources/js/ext.uls.webfonts.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki.language/mediawiki.language.init.js, https://bits.wikimedia.org/static-1.23wmf17/skins/common/wikibits.js, https://bits.wikimedia.org/static-1.23wmf17/skins/common/ajax.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki.libs/CLDRPluralRuleParser.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki.language/mediawiki.cldr.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki.language/mediawiki.language.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki.language/mediawiki.language.numbers.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki/mediawiki.jqueryMsg.js, https://bits.wikimedia.org/static-1.23wmf17/extensions/UniversalLanguageSelector/resources/js/ext.uls.interface.js, https://bits.wikimedia.org/static-1.23wmf17/resources/mediawiki.page/mediawiki.page.startup.js, https://bits.wikimedia.org/static-1.23wmf17/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js, https://bits.wikimedia.org/static-1.23wmf17/skins/vector/collapsibleTabs.js, https://bits.wikimedia.org/static-1.23wmf17/skins/vector/vector.js, https://bits.wikimedia.org/geoiplookup, User:Dr_pda/prosesize.js, User:AzaToth/twinkle.js, User:Mr.Z-man/closeAFD.js, User:King_of_Hearts/closexfd.js, User:Phantomsteve/xfdrelist.js, Wikipedia:WikiProject_User_scripts/Scripts/Force_edit_summary, User:Svick/SectionInput.js, User:PleaseStand/userScriptSandbox.js, User:Haza-w/cactions.js, User:Timotheus_Canens/displaymessage.js, User:Doug/closetfd.js, User:King_of_Hearts/closeffd.js, User:King_of_Hearts/closecfd.js, User:King_of_Hearts/closerfd.js, User:Doug/closemfd.js, User:Haza-w/cactions-languages.js
• URL: https://en.wikipedia.org/enwiki/w/index.php?title=Template:Side_box&action=edit&debug=true
• User/skin.js: https://en.wikipedia.org/wiki/UserJcgoble3/vector.js
• User/common.js: https://en.wikipedia.org/wiki/UserJcgoble3/common.js
• Error console: Nothing related to wikEd

Thoughts? --Rezonansowy (talk | contribs) 10:40, 18 April 2014 (UTC)