Wikimedia Meta-Wiki

Community Wishlist Survey 2017/Reading

< Community Wishlist Survey 2017
Community Wishlist Survey 2017
Reading
13 proposals, 229 contributors



Download as eBook on WikiBooks

  • Problem: users want to read the WikiBooks in eBook format
  • Who would benefit: all users
  • More comments:
  • Phabricator tickets:

DiscussionEdit

VotingEdit

A new wiki skin developed specifically with readers in mind

  • Problem:
    • Many sites, like Wikiwand, and browsers, like Readable wikipedia exists to solve a "readability" problem of wikipeia.
    • They are apparently more readable than wikipedia interface according to their users, and thus some wikipedia readers switched away from wikipedia to those sites
    • As those sites does not have an edit button to lead people back to edit the page on wikipedia, if the situation continue with more and more reader using these alternative sites instead, there could be a reduction in wikipedia's source of editor in the future
  • Who would benefit: The entire wiki community
  • Proposed solution: Develop a skin for these wikipedia readers, and then after extensive trials and ask for feedback from all wikipedian and wikimedian communities, consider how to make the skin available to users especially unregistered anonymous readers.
  • More comments:
  • Phabricator tickets:
  • Proposer: I’m happy to own this. Doesn’t have to be a skin, per se; any solution that simplifies and improves our presentation and readability will do, up to and including dumping MediaWiki for everything but editing. —Anthonyhcole (talk) 03:05, 17 November 2017 (UTC)Reply[reply]

DiscussionEdit

  • Endorse. Readability of regular wiki is a pain. I had to tweak my user CSS manually to change font type, font size, text width,... A new skin is an interesting idea imho. Afernand74 (talk) 14:42, 18 November 2017 (UTC)Reply[reply]
  • This request is similar to the work that Isarra put in to the Timeless skin, as well as the split that the Reading team worked on to get Minerva into its own skin. mw:Skin:Timeless is the Mediawiki page and they are generally working on deploying right now. --Izno (talk) 03:29, 19 November 2017 (UTC)Reply[reply]
    • Some wiki like French Wikipedia have already enable the Timeless skin, see this page as an example. I have considered about the skin when writing about it but I don't think it addressed some of the main concern brought up by peoples who create other tools to replace wikipedia interfaceC933103 (talk) 23:29, 19 November 2017 (UTC)Reply[reply]
    • MinervaNeue is a reader-centric skin, although heavily optimized for mobile devices. (random example) --Tgr (WMF) (talk) 02:17, 20 November 2017 (UTC)Reply[reply]
  • The typography on Wikipedia (and Mediawiki in general) is terrible, and with such a vast selection of CSS/front-end frameworks to choose from that put an emphasis on typography, it really shouldn't be like that. See some of the "skins" here. François Robere (talk) 16:53, 9 December 2017 (UTC)Reply[reply]

VotingEdit

Simple diff

 
Normal diff - text and markup
 
Simple diff - text only, no markup
  • Problem: The normal diff displays article text and wiki markup. For readers only interested in changes to the article text, it's overly complicated and it's sometimes difficult to even find the article text changes among all the templates and other markup.
  • Who would benefit: I have a use in mind for this that is aimed at academic reviewers and the general reader but patrollers, editors and authors will benefit from this feature too.
  • Proposed solution: Offer both options: the normal diff containing article text and wiki markup, and a simple diff showing just the changes to article text.
  • More comments:
  • Phabricator tickets:

DiscussionEdit

  • I recommend flipping a few times between these two images in a media viewer. Compare the experiences. Anthonyhcole (talk) 14:37, 12 November 2017 (UTC)Reply[reply]
  • What about changes in files, references, tables and templates? --Vachovec1 (talk) 19:13, 12 November 2017 (UTC)Reply[reply]
    • Vachovec1: Sure. If it’s technically possible to display the original and replacement citation, image, category, table, etc., I’m all for it. (To be clear, I’m talking about a diff where the original image, citation, etc. itself, not its code, appears in the left column and the replacement image, citation, etc., not its code, appears in the right column.) The more that can be included in the simple diff, the better, provided it”s all simple and not code, but if the best that can be achieved initially is just a diff showing how the text of the article has changed, that’s OK, too. This isn’t going to replace the standard diff, and a diff showing just article word changes would be of benefit to editors. That said, maybe there should be a warning at the top pointing out the kinds of changes that the diff doesn’t highlight. —Anthonyhcole (talk) 06:47, 13 November 2017 (UTC)Reply[reply]
  • I really would like to see an API for this, but it might not for performance reasons. MER-C (talk) 04:16, 13 November 2017 (UTC)Reply[reply]
  • Is this basically mw:VisualEditor/Diffs? Anomie (talk) 17:42, 13 November 2017 (UTC)Reply[reply]
    Anomie, can I link to a visual diff comparing versions in a page’s history? Do I need to do something in my preferences? —Anthonyhcole (talk) 03:11, 14 November 2017 (UTC) I’ve just been told to add &visualdiff to a standard diff url and select “visual (beta)”, like this: https://en.wikipedia.org/w/index.php?diff=749832945&oldid=749832814&title=User:Anthonyhcole/Sandbox&visualdiff which achieves nothing like what I’m looking for, unfortunately. Compare that diff (after selecting “Visual (beta)”) with this. The latter is the same two pages in the standard diff with all the code and markup removed - just article text. Anthonyhcole (talk) 10:29, 14 November 2017 (UTC)Reply[reply]
    It looks like the current beta isn't very good with a complex edit like that. Anomie (talk) 14:39, 14 November 2017 (UTC)Reply[reply]
    • I would say so. Then this task would be about to make it available for "normal" diff screen, not for VE only (e.g. like Two Column Conflict). --Vachovec1 (talk) 18:52, 13 November 2017 (UTC)Reply[reply]
  • Could be added as a button to the dif view. When clicked on it switches between one view and the other. I would definitely use it. Doc James (talk · contribs · email) 22:14, 13 November 2017 (UTC)Reply[reply]

A notice: there is a very similar proposal in the section Editing, namely Community Wishlist Survey 2017/Editing#Support_multiple_diff_variants Support multiple diff variants. --Vachovec1 (talk) 14:45, 15 November 2017 (UTC)Reply[reply]

VotingEdit

Make Wikimedia accessible via Tor and/or I2P

  • Problem: Some countries aren't familiar with spreading free and open knowledge. The proofs of censoring Wikipedia and the Internet in China People's Republic is already known. Turkey has blocked the whole Wikipedia this year. Such a tries there will be also in the future.
  • Who would benefit: Theoretically any Wikipedia-reader concerned about their privacy while reading. More practically for readers from countries with strong censorship of the Internet and especially from those directly blocking Wikimedia projects.
  • Proposed solution: To make Wikipedia and maybe some other Wikimedia projects available read-only as Hidden Service of Tor, I2P eepsite or using any other convenient technology.
  • More comments: Wikimedia projects are of course accessible via Tor network already today, but as being on the normal Internet, the users have to use exit nodes which can theoretically (and some of them practically) attack them as well as the countries which they're trying to avoid. As Tor Hidden Sevices and I2P eepsites (which is technically the same only on different networks) are end-to-end encrypted, it's harder to attack the users from the middle. As these protocols don't support subdomains, it could be possible to use similar thing as was used on secure.wikimedia.org before introducing of TLS on the main domains.

DiscussionEdit

  • And hosting on en:IPFS?--YFdyh000 (talk) 16:18, 28 November 2017 (UTC)Reply[reply]
  • "the users have to use exit nodes which can theoretically (and some of them practically) attack them as well as the countries which they're trying to avoid." - This is not true. Exit nodes cannot maliciously modify Wikipedia content due to us using HTTPS and HSTS. Concerns about malicious exit nodes really only apply to plain HTTP sites. Quite frankly, in my opinion, creating an exit node is more of a political statement than anything else. The effect hidden tor nodes have on privacy, security or censorship resitence is minimal to non-existent. At most, an exit node could determine which domain traffic is going to (due to SNI), but they cannot link that information to the originator of the request. (That said, I like tor, and support creating an exit node for political reasons) BWolff (WMF) (talk) 23:15, 28 November 2017 (UTC)Reply[reply]
    • CNNIC has issued root TLS certificates and this organization is under the influence of the government of People's Republic of China. Having this root certificate in computers, they can technically issue a certificate for any domain, or am I mistaken? I haven't find on HTTPS Everywhere site if it checks the certificates (like I think did the Observatory). --Venca24 (talk) 21:16, 29 November 2017 (UTC)Reply[reply]
      • you're correct that a mitm via a misissued certificate or malicious/incompetent CA is an attack that a tor hidden service can prevent. (Of course a tor hidden service introduces a risk of a mitm by tricking users into viewing the wrong onion url because onion urls arent human readable. Id consider that a much easier to pull off attack than malicious CA attack). CNNIC is probably not the CA id worry about - afaik they are already untrusted by apple and google chrome and firefox only trusts certificates from them prior to 2015 (which is kind of meaningless as they could backdate but i digress). However your point still stands with other CAs. That said I think it would be very difficult to pull off this type of attack without being discovered - the moment the attacker is detected their root gets immediately distrusted and they go out of bussiness, so there is a strong economic incentive not to be involved. And it would be difficult to participate in the attack secretly because a tor exit node doesnt know where the traffic is coming from so the attacker cannot target the attack. Thus there is a high likelyhood that anyone doing such an attack for any length of time would be discovered. Once expect-CT header becomes available in browsers (hopefully soon) the risk of this attack goes down quite a bit. (expect-CT: tells browsers to only accept certificates that are in the public certificate transparency lists. This ensures that anyone can figure out all the valid certificates for a domain, preventing a malicious CA from secretly issuing a cert for a domain they are not supposed to). BWolff (WMF) (talk) 03:21, 1 December 2017 (UTC)Reply[reply]
  • Additionally - "As these protocols don't support subdomains, it could be possible to use similar thing as was used on secure.wikimedia.org before introducing of TLS on the main domains". I can't speak as to I2P, but for tor this statement is untrue. Subdomains work like virtual hosts when using tor with HTTP(S). BWolff (WMF) (talk) 23:18, 28 November 2017 (UTC)Reply[reply]

VotingEdit

Night-mode for read articles?

  • Problem: when we're at night, the white skin of Wikipedia dazzles us and it's very umcorfortable. I suggest a Night mode switch for users or at least a darker color, like YouTube. Also available for the mobile version.
  • Who would benefit: Everyone in general.
  • Proposed solution:
  • More comments:
  • Phabricator tickets:

DiscussionEdit

The three options are good.--VictorPines (talk) 21:03, 29 November 2017 (UTC)Reply[reply]
  • What will happen if a reader's terminal device provides night mode? Will it be too dark or yellowish to read?--Tigerzeng (talk) 15:58, 1 December 2017 (UTC)Reply[reply]
  • I rehabilitated the Green on black skin, but stopped as any fixes took weeks to integrate. Along with unmerged changes, I have prototype color for finding template/pages that break, and was planning on making the crowd pleaser gray-on-gray scheme. Dispenser (talk) 04:11, 11 December 2017 (UTC)Reply[reply]

VotingEdit

Further develop the Timeless skin

  • Problem: The Timeless skin has already been deployed to several WMF wikis, but has a lot of bugs that need to be fixed, and it needs to be improved if it is to be used as a base from which to rewrite or replace Vector, which has a number of problems outlined by Isarra at this Project Grant request (which was unfortunately not accepted). Because of these issues, readers have been turning to websites with better and more modern reader-facing styling such as Wikiwand. Bugs are not currently being fixed, presumably because Isarra is busy in real life and no other devs have volunteered to fix them.
  • Who would benefit: Readers (so basically everyone, I guess)
  • Proposed solution: Finish the design review, fix the bugs, replace the colour scheme, etc.
  • More comments: This is similar to this proposal, but regardless of whether Timeless or another skin is used as "reader-facing", Timeless would probably end up being used as a base anyway because apparently the other skins' code is a mess (see the grant request).
See also: Grants:Project/Isarra/Post-deployment support (pending)
  • Phabricator tickets:

DiscussionEdit

VotingEdit

Make language conversion work in the Electron Pdfs Service

  • Problem: Afaics it's still impossible to unify the variant of downloaded PDF files of pages, this could be a nightmare e.g. for a Taiwan user who does not have zh-hans knowledge (does "维基百科，自由的百科全書" fair for you rather than "维基百科，自由的百科全书" or "維基百科，自由的百科全書"?). PS: I was requesting Google Code In mentors to handle the task below, but no one replied me that's OK or not.
  • Proposed solution: post "variant" parameter from printable mode?
  • More comments:

DiscussionEdit

I think this will just happen once the underlying APIs become variant-aware (T43716, T159985) which is probably too specialized for Community Tech, and planned anyway. --Tgr (talk) 08:06, 28 November 2017 (UTC)Reply[reply]

VotingEdit

Visually indicate if a page has been edited since loaded

  • Problem: When viewing a wiki page (article or talk) and the page is edited, people currently reading the page must manually refresh the page or check the page history to see if it has been updated. People may read incorrect information (in the case of vandalism or breaking news) or miss important updates.
  • Who would benefit: This would be particularly useful:
    • For readers who are reading a vandalized page, to be informed that it has been corrected
    • For readers who are reading a topic of breaking news, to be informed that information is rapidly changing
    • For users who are on a talk page, to be informed when a topic is actively being discussed.
  • Proposed solution: For this proposal I suggest a simple visual indicator, similar to how many email or task management websites (e.g. Gmail, Phabricator) display small growl notifications in the bottom corner. "This page has been edited since you opened it. Refresh to see changes."
A long-term solution could be to visually show the edits as they are made, like visual diffs or Google Docs/Etherpad.
  • More comments:
    • I'm not sure if there's already a gadget for this? Even if there is, I think this could benefit logged-out readers.
    • There should be some logic for circumstances of when the indicator should not appear (e.g. if ORES think the edit is probably vandalism, when an edit is marked as minor and is not a revert, etc.)
  • Phabricator tickets: couldn't find any.

DiscussionEdit

  • There are semi-related tasks, but mostly concerned with edit-conflicts, at phab:T120882, phab:T136815, and phab:T94918. I don't believe there's an existing task for this idea (which I think would be a great feature!). Quiddity (WMF) (talk) 21:38, 16 November 2017 (UTC)Reply[reply]
  • For vandalism it would make more sense to not show probably-vandalized revisions in the first place (Community Wishlist Survey 2017/Miscellaneous/Implement deferred changes is one way to achieve that). For talk pages this would be quite nice. (A similar suggestion for StructuredDiscussions: T98047) --Tgr (WMF) (talk) 01:24, 20 November 2017 (UTC)Reply[reply]
    • Personally, I wouldn't like this for talk pages. It seems likely that I'd miss when someone made a reply in a part of the page I had already read, because I'd be reading a later part of the page by then. Anomie (talk) 14:34, 20 November 2017 (UTC)Reply[reply]
  • No... This is completely the opposite of an encyclopedia. That's a news site... Plus auto-reloading pages is a horrible idea in general. I want to know what I am readin, I do not want a machine to tell me what to read, or guess when to "turn the page" for me. No... This is deal breaker...- Nabla (talk) 22:09, 2 December 2017 (UTC)Reply[reply]
  • Wouldn't the constant popups from when an editor is overhauling a page with hundreds of edits be annoying? How about along with not popping up for likely vandal edits it also wouldn't pop up for when several edits are being made(except for when one of those several edits is a revert which would suggest removal of a vandal that edited several times). -glove- (talk) 06:23, 8 December 2017 (UTC)Reply[reply]

VotingEdit

Open wiki links in new tab automatically

  • Problem: (French) Ce serait bien que les wikiliens entraînent pour le visiteur l'ouverture d'un nouvel onglet dans son navigateur lorsqu'il clique dessus. Cela lui éviterai de perdre la page courante et d'utiliser le bouton de retour du navigateur. Autant faciliter la vie des internautes !
    (English) It would be nice if wikilinks would open in a new tab in the browser. This will save us from losing the current page and using the browser's return button. Might as well make life easier for Internet users!
  • Who would benefit: Les utilisateurs de Wikipédia et des autres projets de la Wikimedia.
  • Proposed solution: Il faudrait concevoir une adaptation au langage Wiki de la balise HTML suivante : <a href="http://www.exemple.xx" target="_blank">Intitulé textuel</a>
  • More comments:
  • Phabricator tickets:

DiscussionEdit

  • David89: (French) Il est toujours possible pour le lecteur d'ouvrir un lien dans un nouvel onglet en utilisant Clic droit> Ouvrir dans un nouvel onglet. Si chaque lien avait cette propriété html, tout le monde aurait des dizaines d'onglets à fermer.... Peut être que tu peut demander la création d'un gadget, que les lecteurs pourraient activer si ils veulent cette fonctionnalité, sans déranger tout le monde. --Framawiki (talk) 06:48, 11 November 2017 (UTC)Reply[reply]
    (English) it is always possible for the reader to open a link in a new tab by using Right Click > Open in a new tab. If each link had this html property, everyone would have dozens of tabs to close... maybe you can ask for the creation of a gadget, that readers could activate if they want this feature, without disturbing everyone.
    I agree. We definitely cannot make all links open in new tabs, for everyone, always. We could introduce a preference, but we have enough of those already. I also believe a gadget or user script would be the best solution, and this would not be hard to implement. MusikAnimal (WMF) (talk) 23:11, 11 November 2017 (UTC)Reply[reply]
    On many projects, there is already a gadget for this. See "Open external links in a new tab or window" in w:en:Special:Preferences#mw-prefsection-gadgets, and the "exlinks" entry in Gadgets/wikipedia (plus variant gadgets with other names, in that list, such as "LiensExternes" - see w:fr:Spécial:Préférences#mw-prefsection-gadgets - "LiensExternes : ouvre les liens externes dans un nouvel onglet"). I don't think this needs any technical work, just local discussions on whether to make the gadget a default. Quiddity (WMF) (talk) 00:14, 21 November 2017 (UTC)Reply[reply]
  • This is bad for web accessibility. --Izno (talk) 04:25, 21 November 2017 (UTC)Reply[reply]
  • Just a comment on some of the suggestions below, that not everyone has a three-button mouse or one with a clickable wheel - Mac users, for example (though it's still easy to a open link in a new tab). Boing! said Zebedee (talk) 22:19, 2 December 2017 (UTC)Reply[reply]

VotingEdit

  •   Oppose. The middle click on your mouse can be configured to do exactly that (if it isn't the default already), if not just hold down Ctrl when clicking. Then there's the gadget solutions mentioned above... MER-C (talk) 01:43, 28 November 2017 (UTC)Reply[reply]
  •   Oppose. Just middle click.Gareth (talk) 11:26, 28 November 2017 (UTC)Reply[reply]
  •   Oppose per above, the mouse wheel is also clickable. --Liuxinyu970226 (talk) 13:22, 28 November 2017 (UTC)Reply[reply]
  •   Oppose 2004 called, it wants it's target="_blank" discussion back. --TMg 16:29, 28 November 2017 (UTC)Reply[reply]
  •   Strong oppose Let the user do whatever they want: in most browsers: left click for same tab, middle click for new tab. Also target="_blank" is a serious security issue that is not yet addressed by all browsers — Arkanosis ✉ 16:37, 28 November 2017 (UTC)Reply[reply]
  •   Support As a user preference - both for external links, and for internal links. Yes, I can right click and open in a new tab, but it is hard to do this when using a touchscreen rather than a mouse. AlasdairW (talk) 23:02, 28 November 2017 (UTC)Reply[reply]
  •   Support Thomas Obermair 4 (talk) 23:04, 28 November 2017 (UTC)Reply[reply]
  •   Oppose IKhitron (talk) 23:19, 28 November 2017 (UTC)Reply[reply]
  •   Oppose If there is one (1) thing that crashes my system a lot it's the opening of new tabs, I already have to be careful and forced reloads often make me lose a lot of prepared editing (which causes me to make numerous small edits instead of one big one like on a desktop 💻), this idea 💡 largely would only make it worse. I would support it if it's optional and then disabled by default. --Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:15, 29 November 2017 (UTC)Reply[reply]
  •   Oppose --Vachovec1 (talk) 18:01, 30 November 2017 (UTC)Reply[reply]
  •   Support As a preference though I'm used to "Right click and hit T on keyboard"(Chrome) to open links in new tab. (Laptop users may not have a middle button) Tigerzeng (talk) 16:05, 1 December 2017 (UTC)Reply[reply]
  •   Oppose --ديفيد عادل وهبة خليل 2 (talk) 12:24, 2 December 2017 (UTC)Reply[reply]
  •   Oppose I'm using Ctrl + Left Click. --Termininja (talk) 16:19, 2 December 2017 (UTC)Reply[reply]
  •   Support I also support this as a preference / option, especially for folks who use an Apple mouse which does not have middle buttons FULBERT (talk) 19:11, 3 December 2017 (UTC)Reply[reply]
  •   Support Ciao • Bestoernesto • ✉ 03:02, 4 December 2017 (UTC)Reply[reply]
  •   Oppose Middle button click / Ctrl + left click exist! --Pau Colominas (talk) 16:31, 4 December 2017 (UTC)Reply[reply]
  •   Oppose Everyone who uses a web browser already knows how this works and can make their own choices.-Bryanrutherford0 (talk) 17:37, 5 December 2017 (UTC)Reply[reply]
  •   Oppose Most browsers let the user decide to open a link in a new tab if they want to. Almost no browser lets the user open a link in the current tab if the website wants it to open in a new tab. Don't make things easy for a few people at the cost of making them hard for most people. --Carnildo (talk) 23:26, 6 December 2017 (UTC)Reply[reply]

Pop-up showing authorship info

  • Problem: It is often difficult to assess Wikipedia articles. Some are the result of multiple authors collaborating, others are the efforts of one PR agent, an editor and an Arb joining forces to validate an essay on a CEO's activism, still others are the Herculean efforts of single accounts. Readers should be able to find this information quickly. Responsible scholarship gains authority (at least in the humanities) due to the reputation of its authors, and yet the history pages on Wikipedia do not give a global overview of the "table of authors" who wrote the article whose history they record typo by typo. Recently, questions have been raised about the WMF's compliance with a court decision requiring that covert advertising be clearly identified as such.
  • Who would benefit: Critical readers, the WMF
  • Proposed solution:
  1. Add a pop-up version of the "Article Info" page at xtools to all visible pages on the project (or at least to all articles in mainspace). This tool is several clicks away from the reader at the moment. (view history > revision history statistics)
  2. Improve the "Article Info" algorithm so that it discounts reverted text and reversions from the edit totals. (Cf. the graph for Donald Trump or Hillary Clinton to see more clearly why the resulting pie charts are skewed... basically, the top editors are those who revert page blankings).
  3. develop color codes for degrees of collaboration that appear in the article itself.

This would probably not be enough to address the serious concerns raised about compliance with European Fair Trade Laws in OLG München · Urteil vom 10. Mai 2012 · Az. 29 U 515/12, but I believe it's a small step in the right direction.

  • More comments: I just learned that User:Doc James tried to get this done years ago and failed due to technical problems and a lack of coders able to make it work. How about we make it happen this time?
  • Phabricator tickets:

DiscussionEdit

  • It could definitely be rolled out as a gadget people can turn on. Here is the mockup from 2014[1]. Added the term "contributors" to the "byline" which when clicked on brings one to a break down of editors of an article. Doc James (talk · contribs · email) 05:39, 11 November 2017 (UTC)Reply[reply]
    • This sounds great. It would be wonderful if under the "Tools" left hand menu it was called "Who wrote this article?" and there was the percentage breakdown and optional authorial biographies. No Swan So Fine (talk) 13:04, 12 November 2017 (UTC)Reply[reply]
  • See also the "WikiHistory" item from the 2017 WMDE Technical Wishes project. [2] As a similar request it was #4 in the survey. CKoerner (WMF) (talk) 22:02, 13 November 2017 (UTC)Reply[reply]
Yes, two requests with over 60 supports each, it does look like German Wikipedia is leading the way on the question. Thanks for the info. SashiRolls (talk) 21:30, 15 November 2017 (UTC)Reply[reply]
  • Re: "This tool is several clicks away from the reader at the moment. (view history > revision history statistics)". It's not quite what you're asking for, but just thought I'd mention that the XTools gadget makes the articleinfo page available with one click (a link under every page title). And perhaps it wouldn't be too hard to add the author list directly there. Sam Wilson 06:58, 15 November 2017 (UTC)Reply[reply]
Aha! Thanks for pointing this out. So the technology exists that allows any reader to do the first step of what I'm asking, and using the author line for statistics and a link to authorship seems like a reasonable first step. Why isn't this standard? That's so much better! Failing that, a link on the sidebar to a (just the facts no promo) "reader's guide to wikipedia" would be useful so that first time visitors could learn about how to find author info, COI info, how to install the author-info gadget (not obvious for someone who hasn't been here for a while), where the disclaimers are, why they're important, etc. SashiRolls (talk) 21:18, 15 November 2017 (UTC)Reply[reply]
Upon reflection, you can only install/activate a gadget if you create an account, so really none of this has any effect on the general reader who does not have an account (and the non-member reader ("client" of "knowledge as a service") is the target for the suggested improvement). SashiRolls (talk) 00:16, 21 November 2017 (UTC)Reply[reply]
  • Improve the "Article Info" algorithm so that it discounts reverted text and reversions from the edit totals – It is doing this to some extent, but we're working to improve the logic, see phab:T179996. As Sam said above, there is a gadget that will give you some high-level information at the top of each page, with a link to the full statistics. This makes it one click away instead of two. Is that sufficient?
    With T176912 we looked into reviving the WikiHistory gadget, which would give you "text shares" (authorship percentages) in real-time. However getting this information requires parsing every single revision within the article. It is not feasible to do this on every page you view, in real time. WikiHistory was able to do this because there was a bot that precomputed the data. In addition to significant maintenance burden, the downside to the bot was it had to be enabled for each wiki individually, and that was assuming that community would actually make use of it (it wouldn't make sense to run a bot no one is using). It requires considerable resources to precompute and maintain this data. In my opinion this is not a good system. We can get you improved data that will help with the issues you are facing, but it should remain an on-demand service, and not an automatic service.
    The other thought is to build these stats directly into MediaWiki. For that I suppose we'd keep running totals as each revision is made, that way we can serve it to you very quickly. This would be a huge effort, and perhaps not worth the while given the size of the audience it would benefit versus development time. It would also most likely be bound by the upcoming revision refactor. In other words, I don't think implementing something like this in MediaWiki could happen in the short term.
    I have never heard of the European ruling you speak of, but I will let the legal team know about it. MusikAnimal (WMF) (talk) 16:36, 15 November 2017 (UTC)Reply[reply]
Yes I've thought about the problem and realize that it's pretty tricky. I was assuming the bot to establish authorial "share" (color coded collaboration as of ##date##) would run on the periodic dumps not on the live database. I recognize too that it's not very environmental of me to ask for calculated author info to be made readable & accurate. Just to be clear: RickinBaltimore really is not the primary author of the Donald Trump article. He just reverted a page blanking. Glad to see you've already caught this and are working on it. Thanks!
I notice volunteers get BY credit for text they copy from paid editors who cannot edit pages directly. The average reader will still not find accurate authorial info even with the gadget unless they also look at the talk page (on en-wiki). Another example: Kosmos Energy (talk page) Unlike with Krzanich, full page protection wasn't deemed necessary to keep mad vandals from messing up / reverting the PR agency's prose. Making that gadget standard would be a good thing to push for. I realize this problem of misattributed edits is due to the en.wiki policy of embedding the COI template among all the other templates on the talk page rather than being on the article page. When policy gives you bad data, there's not much the developers can do. Thanks very much for your response. You've made some great tools. SashiRolls (talk) 21:14, 15 November 2017 (UTC)Reply[reply]

There is an old research project called WikiCredit on this topic. As you can see there, meaningfully quantifying authorship is not an easy problem. --Tgr (WMF) (talk) 01:53, 20 November 2017 (UTC)Reply[reply]

Okay we know have something working on EN WP using a script thanks to user User:Wurgl.


 
Example

The database is currently being build over the next few weeks. So for pages with lots of edits it can take up to 30 min to generate results. For short pages it works in seconds.

Copy and paste the following to here
mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Wurgl/WikiHistory.js&action=raw&ctype=text/javascript'); Doc James (talk · contribs · email) 01:21, 27 November 2017 (UTC)Reply[reply]

  • If the project is feasible, maybe a color aid could be implemented to show which text was added by which editors, such as Google Docs currently does, although I don't know the implications of this or how difficult it could be to apply in real time. --Jamez42 (talk) 13:06, 28 November 2017 (UTC)Reply[reply]
  • To respond to TheDJ's oppose: while I understand that it may well be a technical challenge to generate accurate information, I do not believe that this suggestion caters first and foremost either to Wikipedians or to Sceptics, but to serious consumers of a collaborative reference work. It is entirely possible that it will become necessary in order for the projects to be legally compliant in some jurisdictions in the future, and would certainly be a significant help to anyone wishing both to assess trustworthiness & (possibly) to read other well-written articles by specific contributors. The point of suggesting a scroll-over pop-up in 1 & 2 was that it doesn't add anything more than the word "authors" to the screen. The idea of having "authors" on the lefthand sidebar is also more discrete than the line at the top of the page which has currently been proposed. The color coding I suggested for degrees of collaboration in 3 could be the background for the <span> containing the words "authors". Much less cluttery than an infobox for example (not that I have anything against infoboxes) SashiRolls (talk) 00:26, 30 November 2017 (UTC)Reply[reply]
    • For those interested in this problem, here is an interesting bot action that certainly seems to be obscuring editing history. For those who do not understand how a bot can author such prose, cf. this edit and the surrounding discussion at en.WIKITALK:COI. In a related discussion on that talk page, this 2017 Wishlist is mentioned (but not linked to). SashiRolls (talk) 22:39, 30 November 2017 (UTC)Reply[reply]
  •   Comment I share misgivings of User:SMcCandlish that this might lead to some non-healthy competition and WP:OWN-oriented approach to articles. I also do not like added clutter. On the other hand, I like the idea of some indicator of article trustworthiness and I trust more articles with a lot of authors, so seeing hat 90% of an article come from a single contributor, could be a warning about lack of vetting. However I would prefer that as an opt-in gadget. --Jarekt (talk) 13:49, 4 December 2017 (UTC)Reply[reply]
    • Yes, this is a relevant concern. The idea behind the color-coding was to mark primarily single voice articles as such (as potentially needing to be read with a grain of salt). This just makes visible outside what is already visible inside (COI editors may well already send their potential clients pages of links to the xtool profiles of their greatest hits). SashiRolls (talk) 02:35, 5 December 2017 (UTC)Reply[reply]
  • Very neat that the WikiHistory gadget was revived! I doubt this proposal will make it to the top 10, but just so it's clear, I don't think WMF will build any kind of gadget like the WikiHistory one. We can however improve XTools authorship detection, and/or build another tool for this, as explained at Special:Diff/17426787. I'm sorry we didn't interject and ask the proposal be reworded, because I suspect people would have less concerns about WP:OWN if the authorship statistics were one at least click away, and not shown automatically atop every page. MusikAnimal (WMF) (talk) 18:10, 8 December 2017 (UTC)Reply[reply]
    • Was proposed as opt in. Do not think it is ready for widespread roll out. Other concern is that it may slow down page loading. Doc James (talk · contribs · email) 18:15, 8 December 2017 (UTC)Reply[reply]

VotingEdit

  •   Support MichaelSchoenitzer (talk) 22:43, 27 November 2017 (UTC)Reply[reply]
  •   Support Jcornelius (talk) 10:00, 28 November 2017 (UTC)Reply[reply]
  •   Support HHill (talk) 11:39, 28 November 2017 (UTC)Reply[reply]
  •   Support Oscar_. (talk) · @ 11:48, 28 November 2017 (UTC)Reply[reply]
  •   Support Jamez42 (talk) 13:05, 28 November 2017 (UTC)Reply[reply]
  •   Support --Liuxinyu970226 (talk) 13:22, 28 November 2017 (UTC)Reply[reply]
  •   Support Ynhockey (talk) 20:33, 28 November 2017 (UTC)Reply[reply]
  •   Support Gripweed (talk) 21:31, 28 November 2017 (UTC)Reply[reply]
  •   Support Thomas Obermair 4 (talk) 23:05, 28 November 2017 (UTC)Reply[reply]
  •   Support Shizhao (talk) 03:26, 29 November 2017 (UTC)Reply[reply]
  •   Support bspf   (talk) 07:53, 29 November 2017 (UTC)Reply[reply]
  •   Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:12, 29 November 2017 (UTC)Reply[reply]
  •   Oppose As proposed, I think this adds clutter that only wikipedians and sceptics will care about (at most) and that will interfere with the usability of the wiki. While the goal is lofty, the implementation idea does not seem scalable and practical to me. This seems to attempt to tackle a "Youtube adpocolypse" style problem, by throwing more information into people's face. The problem is not the lack of information (or in Youtube's case the usage of AI), it's the lack of verification before presenting things to users. Which is a fundamental part of Wikipedia and the Internet. Idea needs severe refinement in my opinion. —TheDJ (talk • contribs) 16:50, 29 November 2017 (UTC)Reply[reply]
  •   Support Joshualouie711 (talk) 19:31, 29 November 2017 (UTC)Reply[reply]
  •   Support Nocowardsoulismine (talk) 02:38, 30 November 2017 (UTC)Reply[reply]
  •   Strong support Credit matters. I am a commons contributor, and it is honestly a big part of why I continue to contribute. If I want to know who created an image that information is right in front of me. And websites that reuse my pictures can easily say "this is who created it". Wikipedia articles are far more collaborative in nature, so the site has always struggled with the question of crediting people. But something needs to be implemented; when I am reading an article, I want to know who the authors are. For inspiration one could look to GitHub's interface for displaying user contributions. And I like the gadget screenshot above; that's the kind of thing that would solve the problem. -- Thennicke (talk) 04:17, 30 November 2017 (UTC)Reply[reply]
  •   Support - yona B. (D) 08:34, 30 November 2017 (UTC)Reply[reply]
  •   Support Dromedar61 (talk) 21:40, 30 November 2017 (UTC)Reply[reply]
  •   Support Jith12 (talk) 22:49, 30 November 2017 (UTC)Reply[reply]
  •   Support This might be helpful for non-Wikipedian readers who want to get in touch with the putative authors of articles but don't know talk pages even exist. Daniel Case (talk) 03:24, 1 December 2017 (UTC)Reply[reply]
  •   Support However I wouldn't want it to turn into ownership of a page. SEMMENDINGER (talk) 23:52, 1 December 2017 (UTC)Reply[reply]
  •   Support Waldir (talk) 10:59, 3 December 2017 (UTC)Reply[reply]
  •   Oppose Panders to the egos of the worst element among real (i.e. non-vandal) editors: the WP:OWN-oriented, WP:VESTED-contributor crowd who are already way too much of a problem, frequently editwarring over trivia, blockading article improvements they don't personally agree with, and otherwise being massive pains to the rest of the project. If someone wants to build a gadget like this for their own amusement, have at it, but precisely 0 WMF cycles should be spent on this.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:10, 4 December 2017 (UTC)Reply[reply]
  •   Support Fixer88 (talk) 21:24, 4 December 2017 (UTC)Reply[reply]
  •   Support as an opt in gadget. Researchers request this on a regular bases. The user script might be sufficient but would be nice to make it easier to turn on. Doc James (talk · contribs · email) 03:20, 5 December 2017 (UTC)Reply[reply]
  •   Support NessieVL (talk) 19:55, 5 December 2017 (UTC)Reply[reply]
  •   Support Essential. Why has it never been a standard feature? Kudpung (talk) 21:17, 6 December 2017 (UTC)Reply[reply]
  •   Support Klaas `Z4␟` V:  22:44, 6 December 2017 (UTC)Reply[reply]
  •   Support PamD (talk) 10:22, 7 December 2017 (UTC)Reply[reply]
  •   Oppose Personaly, vandals could see these users and troll or even attack them. There's no necesity to show that specs. It could be dangeours.--VictorPines (talk) 19:28, 7 December 2017 (UTC)Reply[reply]
  •   Oppose the switching on of this functionality for all per TheDJ. Jack who built the house (talk) 22:34, 10 December 2017 (UTC)Reply[reply]
  •   Support Jnanaranjan sahu (talk) 06:44, 11 December 2017 (UTC)Reply[reply]

Find a solution for the conflict between bulleted/numbered list and floating object

  • Problem: A known CSS problem. If an image (or another floating object) is inserted left from the bulleted/numbered list, the indentation is screwed. The bullets/numbers are pushed out before the text block, too close to the image (floating object).
  • Who would benefit: Every reader.
  • Proposed solution: At least find a better workaround than the below mentioned template.
  • More comments: The English Wikipedia created en:Template:Flowlist which can be used to circumvent the problem, but the solution is far from ideal, because it has unwanted side effects, especially for the longer lists.