Community Wishlist Survey 2015/Miscellaneous: Difference between revisions

From Meta, a Wikimedia project coordination wiki
Content deleted Content added
moving endorsed proposals from 2015 Community Wishlist Survey
(No difference)

Revision as of 19:18, 29 November 2015

Identify the most burdened Wikimedians

Tracked in Phabricator:
Task T105943

This is a Community Tech team task. Perhaps contributors could comment here or at the Phabricator page with suggestions for the most burdened classes of Wikimedians. What technical tools would be helpful? Rogol Domedonfors (talk) 06:35, 26 July 2015 (UTC)[reply]

Page-view Stats tool

Wikipedia uses the old stats.grok.se that should be patched to be used corretly from the other wikis. Several bug have been highlighted long time ago, but no one took them in charge.

On the other hand recently has been developed wikiviewstats that is a more complete and flexible, graphic tool. Unfortunately, it has been stop, and no one was able to take it back on track.

I suppose that should be quicker to fix the above issues instead of writing from scratch a brand new stats tool able to monitor the accesses of any articles (fundamental to understand the visitor's insterests), however any of the two choices would be a good improvement. --Andyrom75 (talk) 22:01, 11 November 2015 (UTC)[reply]

Noting that a new page view API (phab:T112956 and phab:T44259) has been recently released which will help with this. [1] (demo) and [2] are some of the tools that has been written for now. Several developers have expressed interest in the API so we will likely be seeing more stable tools in this area in the future. --Glaisher (talk) 16:34, 22 November 2015 (UTC)[reply]

Create a bot to show changes in articles for each WikiProject

  • Problem: I'm working on articles about gastropods (= snails), We already have more than 30,000 articles in the Wikipedia:WikiProject Gastropods. There is already a bot for new articles (en:User:AlexNewArtBot/GastropodsSearchResult), but not for changes made in existing articles. This makes it quasi impossible to track those changes and remove any possible vandalism. And this goes for all other WikiProjects.
  • This would benefit all users.
  • Proposed solution: creation of a bot for each WikiProject, tracking changes in each WikiProject. Articles in each WikiProject are easy to identify since they have a dedicated template on their talk page. JoJan (talk) 14:54, 8 November 2015 (UTC)[reply]
@JoJan: Would you be satisfied with a solution like the one described in task T117122 (a special page rather than a bot)? Ryan Kaldari (WMF) (talk) 02:56, 13 November 2015 (UTC)[reply]
This would be a big step forward. All I want to do is check the changes in articles in all the categories (and these could be many), included within a particular WikiProject. JoJan (talk) 08:07, 15 November 2015 (UTC)[reply]

Collaborative way to generate SVG/PNG graphs using Lua modules

Extension:EasyTimeline lacks some features and doesn't support complex text rendering features needed for scripts other than Latin. Wikipedia community also created hand crafted family tree graphs, e.g. en:Template:Inglis family tree, using HTML tables hack. Now that we have a proper programming language support on Wikipedia wikis, it would be nice if SVG/PNG graphs could be generated using Lua script or wikicode by community, something like mw:Extension:Inline SVG extension but updated and ready to use, or adopting one of Lua bindings of Cairo graphic library. --ebrahimtalk 23:16, 9 November 2015 (UTC)[reply]

Make SecurePoll feature-rich

SecurePoll extension is now used for ArbCom elections at English and Persian Wikipedias and WMF Board elections at Meta, all of which are multi-winner elections (i.e. multiple seats to be filled) but all the options that SecurePoll currently offers are single-winner voting systems. Approval voting, Schulze method, Range voting, and Plurality are all used to elect a single winner and using them to elect multiple winners is an abysmal choice. The conventional Support/Neutral/Oppose system widely used on Wikipedia is unprecedented in the real world — you cannot find any academic book or journal article on it so its possible disadvantages are unknown to us.

There is another problem: The English Wikipedia's ArbCom Elections and The WMF Board Elections usually end up with high turnout whereas elections on smaller communities, such as Persian Wikipedia, suffer from low turnout (about 50 voters). Low turnout requires a robust voting system to produce reasonable outcome. The Persian Wikipedia community is considering using alternative voting systems such as Meek STV which are not available in SecurePoll right now. I also propose to include various other methods available in voting software. I have also found an open source software which can be used to implement a proportional Condorcet method. You may want to see its algorithm. There is another software which covers various voting systems but is not free, namely OpenSTV. 4nn1l2 (talk) 23:40, 9 November 2015 (UTC)[reply]

Enabling EPUB conversion on Wikipedia

There used to be a tool that enabled the conversion of Wikipedia articles into EPUB files. This functionality has been disrupted because the partnership between Wikimedia and PediaPress ended up. I wish the TechTeam could work on a new EPUB converting tool.--Kimdime (talk) 10:53, 10 November 2015 (UTC)[reply]

Reported on phab:T97672. Helder 11:32, 10 November 2015 (UTC)[reply]
There is a current Outreachy project to add OpenZIM export. Both ZIM and EPUB are standalone HTML variants, so in theory EPUB support will be easier once the ZIM support lands. Cscott (talk) 19:01, 11 November 2015 (UTC)[reply]
  • Endorsed Endorsed Rather easy one and there are already community tools for this, namely WSexport. Fixing regressions in existing tools is one of the main purposes of the Community tech team, AFAIK. Nemo 10:33, 22 November 2015 (UTC)[reply]

Preliminary Interwiki linking and Second language preferences

My idea is to allow users to create Preliminary interwiki linking on Wiki-data by linking existed article with non-existing article from another language. What are the benefits from this change? It will help our editors and visitors by giving them chance to read/translate articles from another language especially if they are bilingual/multilingual. Anyone can change his/her preferences and add "Second language" then the system automatically will connect any red links with blue link from his/her second language.

  • Examples:
    • If french is my first language and English is my second:

conjonctivite allergique [En anglais]

  • Spanish:

La conjuntivitis alérgica [en Inglés]

  • English and set Arabic as second language:

Almashad mosque bombing [In Arabic]

I wish that you get my idea and if anyone wanna make any clarification he/she more than welcome :) --Ziad (talk) 13:19, 10 November 2015 (UTC)[reply]

Endorsed Endorsed This would also be nice to integrate with mw:Extension:ContentTranslation, so that bilingual users could easily start new articles from redlinks in their 'first language'. Cscott (talk) 19:05, 11 November 2015 (UTC)[reply]
Comment: Take a look at en:Template:Interlanguage link multi, which has much of the functionality. Finnusertop (talk) 18:09, 12 November 2015 (UTC)[reply]
wdsearch.js already offers this feature when visiting red links, try and open w:it:Terri Attwood. Content translation already offers to create an article by translation when clicking a red link, too. Nemo 18:14, 12 November 2015 (UTC)[reply]
We can't link articles preliminarily on Wikidata. Among other things we have not way to tell later if the article that was created at that place is actually about the topic it was linked with in Wikidata. --Lydia Pintscher (WMDE) (talk) 14:16, 13 November 2015 (UTC)[reply]
comment: That's why I suggested this idea to change wikidata and allow such thing. linking articles through wikidata will be manual task after that the system will automatically link articles on any Wikipedia page. --Ziad (talk) 16:19, 13 November 2015 (UTC)[reply]
It is not a matter of changing Wikidata. It is a fundamental issue with how article creation can be done independent of Wikidata. --Lydia Pintscher (WMDE) (talk) 12:52, 15 November 2015 (UTC)[reply]

Error categorization by #ifexist bug

Pseudolinks #ifexist by using the parser. On Special:WhatLinksHere also pages are disturbing enough, lists that contain templates that use #ifexist. Known since 2007. --Atamari (talk) 19:24, 10 November 2015 (UTC)[reply]

WikiProject Wizard

Creating good WikiProject portals is extremely tedious and time consuming. It requires deep knowledge of WikiText template syntax and how to interface with the numerous tools and bots that exist for WikiProject portal use. Using FormWizard (or a new custom script), a wizard interface could be created for building WikiProject portals which would dramatically simplify the process.

As part of WikiProject X I wrote a requirements document for a Project Builder. I hope to work on it sometime in the next couple of months. harej (talk) 19:16, 11 May 2015 (UTC)[reply]
Endorsed Endorsed--Shizhao (talk) 07:53, 12 November 2015 (UTC)[reply]
Endorsed Endorsed -- :JarrahTree (talk) 00:10, 18 November 2015 (UTC)[reply]

Support for version branching for pages

Add ability to create own branch of page and ability to merge that version into main history (main branch). This would help to avoid most of edit wars and make comparing of different versions easier. --AS (talk) 10:13, 27 May 2015 (UTC)[reply]

I am not sure if I am understanding User:AS what you mean? Doc James (talk · contribs · email) 11:11, 27 May 2015 (UTC)[reply]
See w:Revision control. Branches need to be policed for garbage, and I'm not too sure giving everyone an easy means of making w:WP:STALEDRAFTs is a good idea. MER-C (talk) 13:21, 27 May 2015 (UTC)[reply]
I mean ability for a user to create a version (something like non-stabilized version in FlaggedRevs, but with few parallel versions, because there could be conflicts in non-stabilized version). For example a non-admin user can suggest a change for Main page, and if the change is ok, an admin just merges the version, without forking a page, copy-pasting etc.
It would be nice to have at least next abilities (which don't need core changes):
ability to fork page. Create a copy of page in personal namespace with one click and some magick to not include the page into categories. Why: for experiments and for users forbidden to edit particular pages.
ability to see diff of different pages. As I understand, there is currently no fast way to see diff of a fork and original page.
ability to partial reverting. During editing, when I see last diff, would be nice if I could just click some "revert" buttons next to particular chunks in diff so it would revert corresponding text in textarea. So I don't need to jump between diff and text to revert some changes on a page. --AS (talk) 14:02, 27 May 2015 (UTC)[reply]
This would greatly complicate the process of article editing, steepening the learning curve, at a benefit only in very specific cases. It looks like an attempt to solve with technology a problem that should be solved socially. As for copying a page to personal namespace, just copying and pasting the wikicode will do: it's not a hard task that urgently needs simplifying. I share User:MER-C's concern that making it easier to create user drafts will lead to many mor stale drafts. MartinPoulter (talk) 14:30, 27 May 2015 (UTC)[reply]
„This would greatly complicate the process of article editing, steepening the learning curve“ — this way of editing would be optional. „It looks like an attempt to solve with technology a problem that should be solved socially“ — imho, for now we are solving with social conventions a problem that could be solved with both technology and conventions (and we should delegate as much problems to technology as possible). „making it easier to create user drafts will lead to many mor stale drafts“ — why stale drafts could be a problem (how many is too many)? --AS (talk) 16:25, 27 May 2015 (UTC)[reply]
We already have sandboxes for articles that are locked such as this one. How does this differ to that? Doc James (talk · contribs · email) 00:55, 28 May 2015 (UTC)[reply]
1) no fast way to compare (to preview diff of) sandbox with original page and with other sandboxes. 2) no ability for other person to merge my changes with saving of authority, so I'll be mentioned as author of the version (smth. similar to stabilizing version in FlaggedRevs). --AS (talk) 11:20, 28 May 2015 (UTC)[reply]
One just copies the current article into the sandbox hits save and than uses history to view the dif. One can state who the author is in the edit summary. I do this all the time when I edit in other languages and add content written by other people. Doc James (talk · contribs · email) 11:31, 28 May 2015 (UTC)[reply]
„uses history to view the diff“ - with original version, not with current version of original page (if I understand correctly). „One can state who the author is in the edit summary“ — that should be avoided if possible. --AS (talk) 08:57, 30 May 2015 (UTC)[reply]
Other problem: one can't see list of all sandboxes and can't see list of all proposed diffs --AS (talk) 19:29, 5 June 2015 (UTC)[reply]
phab:T40795? Helder 18:28, 10 June 2015 (UTC)[reply]
Endorsed Endorsed phab:T113004 is the proposal for the 2016 Wikimedia Developer Summit, and lists a large number of related tasks. It's probably the best place to put current discussion. cscott (talk) 18:13, 11 November 2015 (UTC)[reply]
en:Wikipedia:Content forking explains why this is a bad idea. The Quixotic Potato (talk) 14:46, 12 November 2015 (UTC)[reply]
Oppose Oppose per my comments above and en:Wikipedia:Content forking. MER-C (talk) 16:35, 14 November 2015 (UTC)[reply]
I don't think that en:Wikipedia:Content forking actually is relevant at all. We already have "draft" namespaces, for instance. This could simply enable a better implementation of en:Wikipedia:Drafts, which is already consensus on enwiki. Further, English Wikipedia is not all of the wikimedia project; you'll notice that some of the requests about this feature come from wikisource or wikibooks. So citing policy on enwiki should not be considered determinative; once implemented each projects can determine whether to enable this on a namespace-by-namespace basis. Cscott (talk) 22:04, 18 November 2015 (UTC)[reply]

Ability to enable code editor separately from "enhanced editing toolbar"

For me "enhanced editing toolbar" is useful only because of code editor, so I'd like it to be enabled for me only in case I'm editing lua/javascript/css page --AS (talk) 09:31, 30 May 2015 (UTC)[reply]

A code editor appears whenever you want to edit a Lua / JavaScript / CSS page regardless of your "enhanced editing toolbar" preferences, isn't it? I believe this is true at least in mediawiki.org.--Qgil-WMF (talk) 08:34, 9 June 2015 (UTC)[reply]
No, the code editor is part of the enhanced toolbar (integrated into the WikiEditor extension). Disabling it will disable the code editor. Bawolff (talk) 04:12, 10 June 2015 (UTC)[reply]
Understood, thank you. I could not find a task corresponding to this request in Phabricator. If it is created, it should go under phab:tag/wikieditor/.--Qgil-WMF (talk) 07:55, 10 June 2015 (UTC)[reply]
phab:T47850? Helder 18:24, 10 June 2015 (UTC)[reply]

Technical user right to edit summaries

The user right to edit summaries. For example, I've made an edit in some Lua-module but forgot to leave an explanation of the change for other developers. --AS (talk) 11:42, 18 September 2015 (UTC)[reply]

See phab:T15937 and phab:T12105. Helder 12:16, 10 November 2015 (UTC)[reply]
  • Endorsed Endorsed --Edgars2007 (talk) 11:40, 12 November 2015 (UTC)[reply]
  • Endorsed Endorsed but only if the change-history of the summary itself is available to at least those who hold this user-right if not to the general public. Davidwr/talk 06:14, 16 November 2015 (UTC) Clarification: This condition that the history be available to everyone who has the ability to change an edit summary (or better yet, the general public) is for "normal" edit-summary changes. I am not demanding that changes to hide or suppress edit summaries for good reason (similar to what is currently done with revision-deletion and revision-suppression tools) be visible to everyone who has the ability to change an edit summary (far from it - the code should allow for non-current edit summaries should be oversightable (suppressable) and "revision-deletable" even if the page-revision is not oversighted or revision-deleted, with "enabling" this option done on a per-project basis according to that project's consensus). Davidwr/talk 23:44, 16 November 2015 (UTC)[reply]
  • Endorsed Endorsed I would support the addition of the right of every user to ADD to their own edit summaries information they forgot to include, and to EDIT their own edit summaries if there have been no subsequent revisions. This is not contradictory. If I edit a page and forget to put in an edit summary, I could go back and do so. If I misspell something and realize it right after posting the edit, I could fix it. However, once someone else edits the underlying page, I could only ADD info to the end of my previous edit summary. This would still allow me to add a forgotten edit summary, but not remove what was already there when someone else made an edit after I did. There may need to be a time limit on either action to prevent abuse, and it should always be apparent to the reader when they are reading an edit summary that was added after the fact. Etamni (talk) 07:46, 17 November 2015 (UTC)[reply]
  • Endorsed Endorsed Edit summaries are an important way to communicate. In edit wars they are the number one communication way. Molarus (talk) 21:41, 20 November 2015 (UTC)[reply]
  • Endorsed Endorsed per Etamni. IJBall (talk) 21:47, 20 November 2015 (UTC)[reply]
  • Endorsed Endorsed WereSpielChequers (talk) 15:25, 25 November 2015 (UTC)[reply]
  • Endorsed Endorsed yes please! That's a sound practical judgment. Time limit or set up for specific group of users, such as autoconfirmed or autopratolled are always possible, depending on the platform "sensitivity", but those are just details.--Alexmar983 (talk) 16:34, 25 November 2015 (UTC)[reply]

Editor Stats API/GUI

Create an API and/or GUI that can display information like:

  • How many page views have the non-redirect articles User X has created received in their lifetime?
  • How many bytes of text has User X added to all Wikipedia articles?
  • User X has actively edited Wikipedia on how many days since they created their account? And what is their activity level in the past 6 months...
  • What are the top 5 wikiproject categories of articles User X has edited in their lifetime? In the last 6 months?

I think these, and other similar queries could be used to create a Contributor's Dashboard (along with other statistics) which would demonstrate a lot of aggregate information about who does what and how much of it. The goal would be to create snapshots of what people work on that would make it easier to know whom to contact and whom you're dealing with when you interact. It'd also serve as a potential 'gamifying' motivator by letting editors see the growth in their stats over time. Ocaasi (talk) 17:48, 21 May 2015 (UTC)[reply]

Agree these are excellent ideas. Some of this data is already available on an article by article basis such as here for gout [3].
And the rest of the data could be added to here [4]
Clarifying who writes Wikipedia would improve transparency. Doc James (talk · contribs · email) 04:06, 22 May 2015 (UTC)[reply]
I love this proposal. We worked on making pageview stats publicly available, and that will be announced literally within a day or so. It's not queryable in the exact way requested here, but it wouldn't be hard to add another endpoint. Look out on the Analytics mailing list for an announcement and comment exactly how you'd like it improved. And we're focusing on edit data for the next 6 months at least (making it publicly queryable from a stable API). So the data for this is really close, now we just need some sort of user profile to dump it into, and various teams at the foundation have worked on that. Milimetric (WMF) (talk) 13:34, 11 November 2015 (UTC)[reply]
Endorsed Endorsed This might be related to mw:Extension:SocialProfile, which already has some of these features? Perhaps this task could investigate deploying that extension more widely. cscott (talk) 18:24, 11 November 2015 (UTC)[reply]
Unlikely, the requests are more similar to mw:Extension:Contribution Scores and mw:Extension:UserDailyContribs. Nemo 09:58, 13 November 2015 (UTC)[reply]
Oppose Oppose. Contributing to Wikimedia projects is not a game, and should not be presented as such. Points two and three are enough to reject this -- we want quality contributions, and yes, that includes removing content that does not belong. Quality cannot be measured by the number of bytes added or edits made. MER-C (talk) 16:10, 14 November 2015 (UTC)[reply]
Endorsed Endorsed wikidata game is very successful, micro-contributions may be a way forward for mobile. it is unclear that the powerusers want quality, or power. Slowking4 (talk) 04:57, 15 November 2015 (UTC)[reply]
Endorsed Endorsed Gamification is a good way to get new contributors. --Piotrus (talk) 06:47, 16 November 2015 (UTC)[reply]
Endorsed Endorsed Any and all ways to get more information about colleague editors than browsing their recent edits is welcome. --Jane023 (talk) 10:00, 20 November 2015 (UTC)[reply]
  • Comment Comment I would endorse filling in any missing API elements so that this is possible to do in an efficient way that doesn't tax the servers, but rather than spending time an energy working on this, leave it up to third party coders to write the user interface. Why? Because I don't see this as being heavily used AND it's not the kind of thing that really needs to be part of the Wikimedia software to be useful - it's just as useful as an external tool. Davidwr/talk 18:49, 20 November 2015 (UTC)[reply]

Education Program interface changes

As an educator who uses the Education Program page, I'd like the following changes to happen:

  1. Special:Students is pretty useless ([5]). It should be made sortable, but even more important, filterable: I want to use it to see only MY students. And all of them, not a batch of 50 or whatever is the locked in length of table on that page.
  2. Special:MyCourses needs an archive, an option to auto-collapse student entries and to select the length of days one wants to display on the front page. For now it is sadly a page me and my students always skip, with a sigh as it is pretty useless. It is particularly problematic if one has several courses; I currently have four, and this is a mess, as some students show in 2+ course listings, the one I want is not usually at the top, etc. Also, the student activity should show their edits outside English Wikipedia (I have my students edit Korean Wikipedia, for example).
  3. Student's list of articles (ex. at [6]) should support articles outside English Wikipedia; I have students edit articles on Korean Wikipedia and Wikivoyage, but we cannot create hyperlinks there.
  4. I'd like to be able to sort students on that page into teams, probably with colors and names.
  5. I'd like that page to be sortable (by article, student's name, team)
  6. I'd like that page to have a place where you can add student's real name/student number. It's a pain when students register with nicknames, and I have to keep a separate list of who they are.
  7. I'd like to have some sort of progress track for each article/student/group. Ex. students are required to submit an outline on the article's talk page, or make an edit, or ask for a review, or whatever. I'd like to be able to define those, with deadlines, for each course, and have checkboxes display next to each student/group/article entry.
  8. That list should have a collapsed by expandable box for their recent edits (like on Special:MyCourses), and I'd like it to display the number of each student edits in the last week or so. --Piotrus (talk) 04:49, 12 November 2015 (UTC)[reply]
  • Endorsed Endorsed LeoRomero (talk)
  • Oppose Oppose. Insufficient benefit for the core community, WMF specific. MER-C (talk) 16:06, 14 November 2015 (UTC)[reply]
  • Endorsed Endorsed and Comment Comment this is the kind of thing that should be coded by college students themselves. The outreach and education teams can work with educators to seek out interested students who have the computer skills to "jump on board" and get this coded. Doing so would at least partially address the issue of "insufficient benefit" as it would tie up fewer resources than if the foundation were to code it (I would still expect the foundation to provide parameters and some oversight of the project, so it would tie up some resources). Davidwr/talk 18:53, 20 November 2015 (UTC)[reply]

SUL account merging

According to SUL § I have two or more accounts with different names. Can they be merged into one account?, SUL account merging is yet to be implemented. But I didn't find any truly helpful information regarding the actual progress of the implementation of such feature. I have five legacy (those with a tilde that are listed in my user page over ptwiki) and wonder when will the merging be finally available. Before the placing of tildes, I felt harassed in my home project. When arguing with a not-really-friendly sysop, he noticed the screen-name similarities and inquired me whether I was puppeteering and suggested to go to the "Newbie Café" (a page in our Community portal dedicated to novices). That given that I'm one of the (if not the) oldest editor (since 2004) still-active in my project. Fortunately, I was never harassed in votings about my then low edition count, but I had to place a disclaimer in my user-page on the issue. The disclaimer stills there, and I can't wait to erase it... --Usien6 (talk) 15:43, 13 November 2015 (UTC)[reply]

AFAIK there is already a tool for account merging which has several “bugs”, which means that more often than desired it makes the accounts to be merged totally unusable. They therefore hesitate to continue, and probably even consider to not use it at all. IIRC the reason for this problem is that the database of 15 years is too complex to safely merge accounts. You might want to get in contact with @DerHexer:, who has insight into SUL related issues and is probably willing to give a short update. —MisterSynergy (talk) 16:52, 13 November 2015 (UTC)[reply]
The tool cannot be used, a re-write is required. But Usien6 can confirm with each of these accounts on their userpages that all accounts are his own. Then I could manually rename them to Usien6 where he can merge them on his own. Cheers, —DerHexer (Talk) 17:18, 15 November 2015 (UTC)[reply]
Dear @MisterSynergy: Thank you for the update! Dear @DerHexer: Thank you for your stance, I'll be contacting you in your talk page soon... --Usien6 (talk) 16:21, 17 November 2015 (UTC)[reply]
  • Endorsed Endorsed, although I suppose this may be outside the expertise of Community Tech. This, that and the other (talk) 08:21, 17 November 2015 (UTC)[reply]
  • Comment Comment before rewriting/re-coding this into a usable tool, we should survey the need and determine if the affected users' needs can be met without writing the code. If, hypothetically, all affected users will be fine with a partial solution that exists today (such as whatever solution Usien6 winds up using, then there is no need to do anything (that's not to say we shouldn't do it at all, only that it should be a very low priority). On the other hand, if thousands of editors are affected by this and there is no solution acceptable to them, then it should be higher on the priority list. Davidwr/talk 18:59, 20 November 2015 (UTC)[reply]
    • I still haven't contacted DerHexer as I am morally hesitant to ask a procedure only to benefit myself. I'm rather wait for a solution for everybody – be they few or many – being that the original purpose of my entry. Finally, I endorse the approach proposed by Davidwr and enlist myself as a volunteer to help such --Usien6 (talk) 11:49, 24 November 2015 (UTC)[reply]
  • Endorsed Endorsed Helder 12:36, 22 November 2015 (UTC)[reply]
  • Endorsed Endorsed it is not just a problem for old pre-SUL accounts, newbies sometimes create two accounts by mistake and use both. I would like to provide them a solution before a "feisty" patroller accuses them of sockpuppeting. Also, it is a minor occurrence but some users have created a new accounts for a fresh start (nothing bad, just a psychological thing) but at certain point they want "come to terms" to their past. there are even user who forgot their password and create a new account, but we all know that they are telling the truth. Sometimes they have to make thousands of edits to become again AP, with a huge waste of time for patroller. So... it is not urgent, I agree, but if we can do something, why not?--Alexmar983 (talk) 00:32, 27 November 2015 (UTC)[reply]

Major overhaul to Special reports

For a variety of reasons many of the special reports have become useless and some projects have been forced to create their own custom reports such as database reports or through means of the WMFLabs/Toolserver. I recommend a complete overhaul be done to the way these reports are generated that would allow some role within a user community (like Admin or template editor) to be able to modify the code that drives these special pages. Some functionality I think would be useful to do should include:

  1. The ability to hide reports from the list of those displayed if they aren't relevant to the project
  2. Add new reports under some type of custom section
  3. Be able to modify the criteria that is used to generate the reports.
  4. Have more flexibility to expand the length of a report even if that is to break it into 1000-2500 article chunks across multiple pages.

Of course this is just a short list and more detailed requirements and analysis of the problem would be needed. Some things have already been suggested here as minor changes to individual reports or other utility changes but what is really needed is a complete overhaul of the way the Mediawiki system creates and handles reports. Reguyla (talk) 14:48, 26 August 2015 (UTC)[reply]

Most of the QueryPage special pages run very expensive queries on the database so it is not a good idea to let users on wiki modify them. But we should investigate ways to let the pages more flexible (i.e. options in the form). --Glaisher (talk) 17:16, 26 August 2015 (UTC)[reply]
Thanks that's good to know. I think I heard that about the queries and maybe as part of the investigation we could see if its possible to make some of them run with less resources. Its also possible some aren't needed at all and could just be eliminated completely or turned off. For example, Pages without language links is pretty irrelevant for Wikipedia now (although some Wiki's may use it) so maybe that could be an example of one we disable and don't run. Does anyone really use Dormant pages or Orphaned pages? My guess is probably not. Reguyla (talk) 17:33, 26 August 2015 (UTC)[reply]
  • Endorsed Endorsed at least for consideration. I think it is worth including this in stage 2. This, that and the other (talk) 08:24, 17 November 2015 (UTC)[reply]
  • Limited Endorsed Endorsed for consideration per This, that and the other. Given that these are "expensive" queries perhaps a special "Query editor" user-right that only those with demonstrated programming skills will hold. Proposed changes can be made by any editor on a test wiki, reviewed by the community similar to the way the English Wikipedia's bot approvals group approves bots, then given final technical approval by someone with the "query editor" user right and implemented by that same editor. I call this a limited endorsement because we should also seriously consider doing nothing because, as Reguyla pointed out, there is already a way to "get the job done" using external tools. Davidwr/talk 19:10, 20 November 2015 (UTC)[reply]

Cite : Share : Export

I propose to consolidate and replace a variety of items on the sidebar, notably the "print/export" section, which will help with the sharability/discoverability of articles and also help solve the emotive issue of 'social media' in Wikipedia: It could be called "Share | Cite | Export" tool. When the button is clicked, it would open a clean/simple dialogue box on top of the page that would provide 3 clear groups/tabs of options. The local community on each wiki could determine which elements they wished to have included in each group.

Group 1 would be Cite and this would have little dropdown boxes for any format desired - Harvard, BibTeX, MLA, Zotero... This would also have a clear link to a documentation page such as w:Wikipedia:The_Wikipedia_Library/Research_help

Group 2 would be Share. This would have:

  • stable link to current version
  • short URL
  • QR code (ideally QRpedia code)
  • Share-links for whatever common social media platforms are relevant. On English Wikipedia this would certainly include Twitter and Facebook, but on Chinese Wikipedia this would definitely include Weibo, etc.

Group 3 would be Export and would include the options currently in the 'print/export' section of the sidebar:

  • Printable version
  • Download as PDF
  • Create book
  • The 'gather' tool might go here too [I'm not sure how it is supposed to interact with either 'watchlist' or 'create book' function to be honest...]

The visual design of this system, the order of the groups, and the order of items within the groups would all need to have some serious UX research because the point is both to be a 'one stop shop for sharing' but ALSO to be intuitive and not overwhelm the user with documentation. Wittylama (talk) 10:44, 21 November 2015 (UTC)[reply]