Jump to content

Community Wishlist Survey 2015/Archive

From Meta, a Wikimedia project coordination wiki

This page is an archive for proposals posted on the Community Wishlist Survey 2015 that were closed. Proposals were closed for several reasons: The proposal described a project that's already happening, the proposal directly conflicts with an existing product team's work, the proposal was a duplicate of another proposal, the proposal was withdrawn by the proposer, or the proposal failed to receive any endorsements in the proposals phase.

Bots and gadgets[edit]

Endorsed proposals can be seen at Community Wishlist Survey 2015/Bots and gadgets.

Automatic bot[edit]

Recommend to create automatic bot for those small wiki which may not have local expertise. They can submit a template and data file and a bot expert will create and run the bot (with permissions of local admin.). Yosri (talk) 02:34, 10 November 2015 (UTC)[reply]

@Yosri: I'm not sure I understand this proposal. What function would the bot be performing? Ryan Kaldari (WMF) (talk) 03:01, 13 November 2015 (UTC)[reply]
Comment: I believe the request is general, presumably functions comparable (or identical) to various existing bots. Alsee (talk) 14:43, 14 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF):Ditto, but without the need for the said user to have bot expertise. More like the local user only prepare a template and the data file. A standard bot will pick it up and generate the pages. That means, wiki in other languages need only to translate the template to generate complete pages in local languages, instead of manually translating those pages one by one. Yosri (talk) 16:00, 18 November 2015 (UTC)[reply]
@Yosri: OK, I think I understand better, but could still use some clarification. What types of bots did you have in mind? Are you thinking of bots that generate database reports (en:Wikipedia:Database reports)? Bots that edit articles? Bots that build reports for WikiProjects? Which ones would be your highest priority? Any specific examples would help. Ryan Kaldari (WMF) (talk) 23:30, 18 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF): A bot that create article, very much like mail merge. User supply template and data file, the bot run on batch (after local admin given green light.) If other language Wiki want to use the same data file, they just copy both to local Wiki & translate the template and some field in the data file (I imagine) and their local admin give green light / flag bot on for that template and off it go. After all, not all user is technical savvy enough to operate a bot, but can still manage mail merge like concept. Yosri (talk) 14:30, 19 November 2015 (UTC)[reply]
@Yosri: Thanks for the explanation. Does the ArticlePlaceholder extension mentioned below sound like something similar to what you have in mind? Ryan Kaldari (WMF) (talk) 21:43, 24 November 2015 (UTC)[reply]
I believe a lot of what you are trying to achieve will be solved with the ArticlePlaceholder we are working on at Wikidata. --Lydia Pintscher (WMDE) (talk) 10:14, 21 November 2015 (UTC)[reply]
Indeed. Helder 11:58, 22 November 2015 (UTC)[reply]
@Lydia Pintscher (WMDE): , @Ryan Kaldari (WMF): Close, but no cigar. Place holder still require individual article be created manually. This bot will supposed to auto create article with template and data files supplied by user. Yosri (talk) 16:45, 25 November 2015 (UTC)[reply]
@Yosri: I believe Placeholder is supposed to be completely automatic, but I don't know much about it. Maybe @Lydia Pintscher (WMDE): can provide more info. Ryan Kaldari (WMF) (talk) 22:44, 25 November 2015 (UTC)[reply]
Yes the whole point of the project is not to create the actual wikitext article unless an editor comes and takes the time to expand on the info Wikidata can already provide. The moment you make it a real article it becomes much more difficult to for example keep it updated automatically. --Lydia Pintscher (WMDE) (talk) 11:18, 26 November 2015 (UTC)[reply]


Endorsed proposals can be seen at Community Wishlist Survey 2015/Categories.


Endorsed proposals can be seen at Community Wishlist Survey 2015/Commons.

New Commons upload wizard without any text[edit]

Create a new-generation default upload wizard for Commons that is 100% icon-based, without using any text at all. I know it's a challenge, especially considering the incredible amount of text here. There must be a way to use the creative commons licensing logos and editing logos to indicate fields for input, and nation flags for local templates and so on. Behind the logos can be links to help pages, but it should theoretically be possible to upload a file without encountering any text at all. This improvement will greatly enhance repetitive upload experiences, while making it possible to fit many input fields on one screen (sometimes something basic such as the "Next button" drops off my screen in the lower right for example). Suggestions such as the current links in the default uploader for "Learn/Upload/Release rights/Describe/Use" can all be substituted by a question-mark token taking you to help pages. The term "Releasing rights" is useless and only acts as a deterrent for potential uploaders. This should be substituted with a drop-down selection for the proper creative commons license (or combination thereof) which may include a direct link to that license on creative commons, not to some page on Commons itself. The "Use" button doesn't belong in upload wizard at all, but should be part of the basic information template. This is a feature that should always be available, and not just on file creation. (I will create a separate wish for this). --Jane023 (talk) 11:38, 20 November 2015 (UTC)[reply]

Modify Commons Upload Wizard to move "Use" link[edit]

Screenshot of "Thanks" page as it currently is today

Currently, after uploading an image on Commons using the default uploader, the user is presented with a "Thanks" page that includes a use-link under the header "To use the file in a wiki, copy this text into a page:". The thankyou is fine and should appear at the top of the page and the rest of the page should be the default file page. The use-link should be part of the basic template to be used at any time, not just on file-upload. I suggest putting it under the image, so e.g. next to the current link under the image that states "Open in Media Viewer". --Jane023 (talk) 11:46, 20 November 2015 (UTC)[reply]

Added an illustration of the thankyou page with re-use options as it exists today. --Jane023 (talk) 09:21, 27 November 2015 (UTC)[reply]

Improve Transfer of files from Wikipedia to Commons[edit]

Current tools like tools.wmflabs.org/commonshelper often "loose" a lot of valuable information during transfer, they also often produce quite bad results that requires massive cleanup efforts on the Commons end. Requirement of the improved system would be:

  1. file and description edit history should be copied and accessible on Commons through "history" tab. First this seems to be the only way to satisfy the requirements of matadata CC-BY-SA-3.0 license, second the metadata after transfer often has confusing licenses, OTRS licenses or other important information and it is essential for regular users to be able to go back to the original file and look it up. Unfortunately at that point the original file is often deleted and can not be viewed without help of wikipedia administrator.
  2. there has to be community maintained mapping between templates and template parameters, so Wikipedia templates used on file pages can be replaced with equivalent Commons templates and all the parameters used by the templates are properly copied. For example sr:Шаблон:OTRS is equivalent to c:Template:PermissionOTRS, but parameter "1" does not match Commons parameter "1" and Serbian "{{OTRS|3396357}}" is equivalent to commons {{PermissionOTRS|ticket=https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom&TicketID=3396357}}.
  3. Wikidata should be used for matching categories and possibly templates.
  4. Transfer tool should work both ways so files which could be used on supporting wikipedias under "fair use" can be easily copied from Commons instead of just deleting them.

--Jarekt (talk) 05:03, 23 November 2015 (UTC)[reply]

I thought the community mapping happened on CommonsHelper2. Is the feature broken? Nemo 07:27, 23 November 2015 (UTC)[reply]


Endorsed proposals can be seen at Community Wishlist Survey 2015/Editing.

Semiautomatic generation of "references"[edit]

Today one of the most frequent omission in new aticles is the need to enter "references" when there exist "ref"s in the text. It ought to be posbile to "propose" to the edistoir these in the right place.Yger (talk) 10:49, 11 November 2015 (UTC)[reply]

Add Citoid support to RefToolbar[edit]

Tracked in Phabricator:
Task T114156

RefToolbar is a default gadget on the English Wikipedia. It adds a "cite" button to the WikiText editing toolbar for quick and easy addition of commonly used citation templates. It is probably the most common way that citations are added into Wikipedia. It also has an auto-fill feature that lets you create a full citation by just entering the ISBN, DOI, or PMID number. There is a new Citoid service that is being developed for the VisualEditor that will allow the same auto-fill capability based on raw URLs. Since Citoid is an API service, there is no reason it can't be added to the WikiText editor as well through RefToolbar.

Adding Citoid support to the wikitext editor is already planned. Whatamidoing (WMF) (talk) 00:18, 12 May 2015 (UTC)[reply]
@Whatamidoing (WMF): Do you know what team is going to be working on that? Collaboration? Kaldari (talk) 17:23, 12 May 2015 (UTC)[reply]
I believe it's the VisualEditor team, per mw:Editing#VisualEditor team and phab:T94223. Quiddity (WMF) (talk) 17:33, 12 May 2015 (UTC)[reply]
Looks like the bug is currently unclaimed, but is being considered as a possible GSOC project for August. Specifically, the bug is about adding Citoid + TemplateData support to WikiEditor (unclear if this would include a citation template editing interface), which sounds like a larger project. My idea above is a quick hack just to add a Citoid lookup to the existing URL field in RefToolbar. RefToolbar already does API look-ups and has mappings for all the en.wiki citation templates, so this would be a smaller, short-term project. Kaldari (talk) 18:44, 12 May 2015 (UTC)[reply]
Pre-re-organization, it was definitely the Editing team, whose main project was VisualEditor, but whose scope also included the wikitext editor and Cite.php.
If you just want a quick hack, then User:Salix alba had one a while ago (I don't know its status). Whatamidoing (WMF) (talk) 17:58, 14 May 2015 (UTC)[reply]
You can find it at en:User:Salix alba/Citoid. I updated a few days ago. The data produced by citoid has been known to change format which can sometimes break the gadget. I'm trying to keep it upto date.--Salix alba (talk) 15:44, 7 June 2015 (UTC)[reply]
The VisualEditor team is definitely planning on doing this as part of the modern wikitext editor project. However, it's not being actively worked on yet and probably won't be for another quarter or two. I leave it up to the Community Tech team whether to include it in their survey, but I don't think they want to take on things that other teams have fairly concrete plans to do :)—Neil P. Quinn-WMF (talk) 20:16, 11 November 2015 (UTC)[reply]
Just to clarify, the project is to build a new wikitext editor with all these features (to avoid suddenly breaking users' workflows and gadgets). This wouldn't help people who strongly want to stick with the existing editor.—Neil P. Quinn-WMF (talk) 20:40, 11 November 2015 (UTC)[reply]
You can now switch from WikiEditor to VisualEditor mid-edit so Citoid is only a click away if you are using WikiEditor. ESanders (WMF) (talk) 17:58, 12 November 2015 (UTC)[reply]

Automatic non-breaking spaces[edit]

The functionality for automatic non-breaking spaces should be improved. As far as I know, this already exists for "%" and "« »", but there are other places where it would be needed, such as "§". Also, VisualEditor does not support non-breaking spaces yet. Thanks, --Gnom (talk) 10:04, 12 November 2015 (UTC)[reply]

My understanding is that spaces before most punctuation marks are automatically converted into non-breaking spaces. § isn't really used as punctuation though (at least not in English), but to designate a section or paragraph in a work. I'm assuming that you would want the space after the § to be converted into a non-breaking space, correct? Are there any other specific examples of cases that would benefit from automatic conversion? Ryan Kaldari (WMF) (talk) 18:01, 12 November 2015 (UTC)[reply]
Please take a look at the use of "§" and "& nbsp;" in §_175, a law-related featured article on German Wikipedia. It currently contains 249(!) instances of "& nbsp;". I don't think I can come up with any good English examples, but maybe "Mr._Smith" is one. Thanks, --Gnom (talk) 21:26, 12 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF): Your understanding appears to be wrong. You can test it by creating a short test page with long words and slowly resizing the browser window. To see the difference, then replace with   the spaces before the punctuation (punctuation such as hyphens -). But it would be nice if this could be implemented. --V111P (talk) 03:50, 22 November 2015 (UTC)[reply]
@V111P: I created a test page at User:Ryan Kaldari (WMF)/Sandbox. It looks like automatic non-breaking spaces are being added for semicolons, question marks, and exclamation marks. Periods don't need them, since periods don't have spaces before them (even in French). I'm not sure what you mean by hyphens. When would a hyphen need a non-breaking space? Ryan Kaldari (WMF) (talk) 22:54, 23 November 2015 (UTC)[reply]
@Ryan Kaldari (WMF): Sorry, I wasn't familiar with French punctuation rules, that's why I didn't test ;, ? and !. I gave the hyphen as an example because it is often used instead of a dash, I am also interested in having non-breaking space in front of the en dash – the one that is sometimes used with spaces, including in German. And I don't think that it's acceptable for the dash to appear at the start of a line in these cases. It's not the most important problem in Wikipedia, but it would be nice if it can be fixed. --V111P (talk) 04:04, 24 November 2015 (UTC)[reply]
@V111P: Ah I see. That might make sense to put them in front of en dashes. It could be problematic for em dashes, though, since in some languages (like Russian apparently) you're supposed to use a "narrow non-breaking space" character in front of em dashes (or in English, no space at all). Hyphens would also be problematic since they are often used for negative signs (which don't need a non-breaking space in front of them). Kaldari (talk) 21:31, 24 November 2015 (UTC)[reply]
@Kaldari:, it should probably be an option in MediaWiki (if it's not already an option) – Spanish (Wikipedia) also uses special rules for the em dash —space before the first one— but after the second one. --V111P (talk) 03:13, 25 November 2015 (UTC)[reply]
@Gnom: I went ahead and created a Phabricator ticket for the section marker issue (phabricator:T119463). If you come up with other examples where this is needed, let me know. Ryan Kaldari (WMF) (talk) 00:00, 24 November 2015 (UTC)[reply]

Article sweeper / examine list for later checking[edit]

We have no way to do article quality checking, in series.
All users / all projects.
Currently addressed
Using hovercards over articles in categories, in Wikipedia (very limited).
By a tool that navigates an article list (on the left) and previews articles (on the right) using keyboard (left/right changes article, up/down (and mouse) scroll article). The list can be fed in a number of ways, i.e with a category and by selecting the level of deepening inside it.
  • An article with a poor lead section or table of contents is often a poor article.
  • Using hovercards is not enough and article message templates are not visible.
  • Sweeping an article category (+selectable depth) with preview is extreme help for thematic quality checking.
  • Scrolling the article preview helps examining the full article.
  • Putting articles to a personal examine list by using spacebar toogling (and similar button to watch list 's star click) helps later checking.
  • Make simple to directly put article message templates while previewing.

--ManosHacker (talk) 10:01, 16 November 2015 (UTC)[reply]

Table editing[edit]

Many people want row numbering, drag and drop rows and columns, etc.. There are various Phabricator threads, but no overall plan. --Timeshifter (talk) 00:17, 17 November 2015 (UTC)[reply]

Improved editor[edit]

  • Provide an editor that provides concurrent wikitext / WYSIWYG views. (Obviously there would be some unspecified view for construct in progress. e.g. If the user opens [[ to start a wikilink we wouldn't want to render that as an error.
  • Auto-completion similar to what the Eclipse IDE provides for writing Java. For example, user starts a template {{web cite| ... provide dropdown /autocomplete with available parameters.
  • Ability to provide url to commonly used sources and parse out common references field. e.g page title, author, date. NE Ent (talk) 01:27, 17 November 2015 (UTC)[reply]

User warning due to multiple edits without summary[edit]

Some years ago a user on itWiki (RicordiSamoa, I am not pinging him but you can ask him) developped a simple bot that could insert warnings in talk pages of users that had forgot to fill the summary line of their edits for more than 5 times in a row. The public discussion where the idea emerged showd no specific concern with it, but since the bot was activated "too early" (the discussion was still ongoing), it was stopped.

Now, as far as I recall, it looked a very simple feature to implement. Both as a warning in talk page or in the editing environment, you get the idea. Similar mechanisms are usd on some platforms. It can be tuned too: for example you can have it only working for registered users, or even only AP users, or using it with a higher edit threshold or focusing only on ns0 edits. I feel it could be useful, especially for retropatrolling, and that some wikiprojects will activate it without problems. It looks quite harmless: we have templates to ask for more attention, I don't see why I should waste my time to insert them when the operation can be "automatized" when needed.--Alexmar983 (talk) 17:58, 22 November 2015 (UTC)[reply]

There is already a user preference which warns you if you leave a blank edit summary here. I don't think we should force it on users. --Glaisher (talk) 15:23, 24 November 2015 (UTC)[reply]
On wiki stating a generic principle in a discussion in my experience "works" because the amount of people who agree is usually higher than those who would highlight that sometimes it does not show a great correlation with the discussion itself.
On itWiki we have a warning that informs users when they make a duplicate or a mistake introducing the cite book template. Is it forcing those users to avoid the insertion of such duplicate or mistake? Nope, it's just informing. We also have a template that politely asks editors to use more summaries. Is it forcing those users to actually use more their comment bars? Not that I recall. So we are stating a principle if we do these things but "not efficiently" or "not always"? Something does not sound right here, or is it just me? :D I am happy to know that a lot of time is wasted in retropatrolling because we have to state a principle but please next time, let's try to show an "overall perspective" otherwise I think the message is lost...--Alexmar983 (talk) 18:21, 24 November 2015 (UTC)[reply]
@Alexmar983 It might not force them directly, but unless the proposed user warning system only notifies someone once, the user who neglects the summary line will have their talk page flooded, thus making them feel somewhat forced to do it. I wholly agree that people (including me) need to use the summary line more, but I think an automatic system isn't a good idea considering that sometimes an empty edit summary is warranted, such as when you're correcting one little typo or syntax error. InsaneHacker (talk) 09:55, 26 November 2015 (UTC)[reply]
I write "typo" sometimes. BTW, if you mark "m" you don't need a summary. I use both, the second less than the first one but from the practical point of viw it is the same. It is a detail you can fix very easily--Alexmar983 (talk) 20:14, 26 November 2015 (UTC)[reply]
On EN Wiki edit summaries are optional, before you start warning people for not leaving a summary first you need consensus that Edit Summaries are compulsory. I find it useful to know that someone is likely to be a vandal or newbie so I would oppose making edit summaries compulsory. If someone could show a benefit from compulsory edit summaries that would be greater than the loss then I might reconsider. WereSpielChequers (talk) 15:46, 26 November 2015 (UTC)[reply]
why somone should show a benefit from compulsory edit summaries since they are not compulsory and they will never be? Why you should "need consensus that Edit Summaries are compulsory"? You are commenting something that is not my proposal, how can I reply on that? You just transformed it in something different.
The only users that insert less than 20% of edit (in ns0) are basically newbies. Actually, to get 50% probability to mak 5 edits in a row without any type information you need a filling efficiency of 13%... Or some distracted user once in a while. there won't be any flood of warning in talk pages and by the way you can skip the warnings in the talk and focus on the warning on the interface editing. A line informing you that the one you're saving is the n-th edit in a row without summary is not a shock (or similar/related concept) to your contribution history. In any case you can always start the warning after some hundrets of edits (I said in my proposal to focus on AP users for xample, or similar groups, depending on the platforms)
Even if this excessive picture you are describing were true (and it's not, if you crunch the numbers), still it would be a nice, useful tool that some platforms might need to adopt, whatever the backgruond behind that choice is. --Alexmar983 (talk) 19:26, 26 November 2015 (UTC)[reply]
If edit summaries remain optional then why warn people for not doing them? Warnings should be for when people do something wrong. WereSpielChequers (talk) 22:12, 26 November 2015 (UTC)[reply]
Just to be clear: I just showed with maths that this has statistically an effect basically on people who make less than 13% of edit with summary and therefore all the previous comments focusing on the "almost 100% philosphy" were in fact quite off-scale. Just wanted to point out.
The answer to your question is a simple no. You warn people to pay more attention, this has to do with "something wrong" but also with "something that can be improved". If your comment were correct, templates asking for more attention in user talks should me removed. They have been used for years on some platforms, aren't they?
There's even more. In it:Aiuto:Oggetto you can read Una linea guida importante da seguire è compilare sempre il campo Oggetto... it's even compulsory! Noone wants that but do you ralize how excessive your comments sound compared to what is actually written in guidelines? In en:Help:Edit summary you can read It is considered good practice to provide a summary for every edit. So I think that a warning to encourage a good practice is perfect good sense especially when it is actually so mild. 5 in a row without summary is at the limit of what is considered good practice, isn't it?--Alexmar983 (talk) 23:43, 26 November 2015 (UTC)[reply]

Search and replace functionality in the editor[edit]

As a posibility to speed up mass replacements (e.g.: abbreviation by full word, one typographical symbol by another, etc.) it would be really nice to have some search and replace (all) functionality within the editor. -- Lord van Tasm (talk) 14:57, 23 November 2015 (UTC)[reply]

VisualEditor allows mass replacing (use Ctrl + F). Probably there are gadgets as well which lets you do this with the wikitext editor. --Glaisher (talk) 15:21, 23 November 2015 (UTC)[reply]
WikiEditor (alias the "enhanced toolbar") has had this feature for many years. Nemo 15:39, 23 November 2015 (UTC)[reply]
I've also been editing for several years now but have never noticed this until now (Thanks Nemo!). Is there any reason why the feature is "hidden" at the other side? Why can't it be just next to the other icons in the toolbar? --Glaisher (talk) 15:32, 24 November 2015 (UTC)[reply]
@Glaisher: see phab:T25824 (Search & replace button is hard to find). Helder 18:35, 24 November 2015 (UTC)[reply]

Please see and support also my bug reports related to the Wiki Editor's Search & Replace: WikiEditor should remember previous Search & Relace strings and Wikieditor's search and replace window is unnecessarily large, covers parts of the textarea. --V111P (talk) 19:14, 24 November 2015 (UTC)[reply]

Moderation and admin tools[edit]

Endorsed proposals can be seen at Community Wishlist Survey 2015/Moderation and admin tools.

Flag SPA and new user accounts[edit]

I think it would be useful if Single Purpose Accounts and new user edits were flagged somehow in page histories and reports such as Recent Changes. These are often sources of problematic edits, so it would help in identifying such edits. Additionally this information is useful in deciding how to respond to problems and it would thus save having to check user contributions. Would have to decide how to define such accounts. Maybe a SPA is one with more than 80% or mainspace edits on one page, and new users are those with less than 20 mainspace edits, but maybe there are stats available that might give a better understanding of how to set this criteria. Derek Andrews (talk) 00:08, 9 November 2015 (UTC)[reply]

As regards new users, I believe this can be done by setting edit filters to tag edits by users with few edits. No comment with regard to SPAs. BethNaught (talk) 18:21, 9 November 2015 (UTC)[reply]
Oppose Oppose adding a scarlet letter so that people assume bad faith is a terrible idea. Beeblebrox (talk) 00:36, 10 November 2015 (UTC)[reply]
Oppose Oppose they're already filter tagging new edits this way, but where is the new editor curation and coaching? fixing problems is a particularly bad idea, try system improvement. Slowking4 (talk) 04:03, 14 November 2015 (UTC)[reply]
Comment Comment I am sensitive to the "scarlet letter" issue. Perhaps a better idea would be to have proven-sock account's edits made after a certain date [e.g. the date the original puppetmaster was blocked] retroactively tagged. Retractive tag changes would likely require a change to the MediaWiki software. Davidwr/talk 06:02, 16 November 2015 (UTC)[reply]
Oppose Oppose Not all SPA accounts are bad, nor are all -- or even a majority -- of new user accounts problematic. In my opinion, it is better to miss one sock puppet than to falsely accuse a new user of sock puppetry. Likewise, it is better to miss a problematic edit than bite a potentially productive future editor by failing to assume good faith. Etamni (talk) 06:42, 17 November 2015 (UTC)[reply]

IPv6 rangeblocks[edit]

In a very short time, it's become clear to me that many admins need help dealing with IPv6 rangeblocks. See this and [this for example. Can the WMF come up with better tools, scripts, or at least more understandable documentation to help out? I looked at the MW docs and there are no practical examples admins can follow. --NeilN (talk) 18:19, 11 June 2015 (UTC)[reply]

The closest I could find in Phabricator is T37542 Provide general means to map IP address spaces (IPv4 to IPv6 and back).--Qgil-WMF (talk) 19:21, 11 June 2015 (UTC)[reply]
NativeForeigner made a nice little range-block caluculator at http://nativeforeigner.com/calc/ that can deal with both IPv4 and IPv6 addresses, but it's not advertised very well. — Mr. Stradivarius ♪ talk ♪ 05:04, 17 July 2015 (UTC)[reply]

Tools for import[edit]

mw:Extension:Duplicator or mw:Extension:Multiplicator would be very useful and much easier that the importupload with xml-files. Kind regards, --Brackenheim (talk) 21:15, 19 November 2015 (UTC)[reply]

Better control of Conflict of Interest damage[edit]

What is the problem you want to solve?

The damage that COI offenders cause to our reliability and integrity as a community: On his WP Talk page, Jimbo Wales said: This story looks worthy of a discussion. I have long advocated that we should deal much more quickly and much more severely with COI editors. The usual objections (from some quarters - I think most people agree with me) have to do with it being hard to detect them, but in this case, the COI was called out, warnings were issued, and nothing was done. Now the editor has been called out by the media embarrassing him (he deserves it), his employer (who may not), and Wikipedia.--Jimbo Wales (talk) 17:08, 20 November 2015 (UTC)[reply]

Which users would benefit?

All but the COI.

How is this problem being handled now?

from WP:COI: "How to handle conflicts of interest": avoid outing, be civil; offenders "should be made aware of this guideline and warned not to continue their problematic editing. If the same pattern of editing continues after the warning, the account may be blocked." Then hand them a lollipop?

What are the proposed solutions?

  1. Research: Adapt existing tools, and control measures proposed in this Moderation section, to make it easier for Wikimedians to research and flag suspicious users
  2. Limit the damage: Suspend user ability to edit pages other than COIN/ANI, pending investigation
  3. Resolve: Unblock/ban user, depending on results of investigations

(If only it were all that easy, right?) Thanks; LeoRomero (talk) 02:45, 22 November 2015 (UTC)[reply]


Endorsed proposals can be seen at Community Wishlist Survey 2015/Multimedia.

New audio player with waveform display[edit]

Basically something like this. I think the improvement in usability compared to what we have now is quite obvious, at least for File: pages at Commons. Might be useful as an option in Wikipedia articles as well. --El Grafo (talk) 11:29, 21 September 2015 (UTC)[reply]

The Community Tech team is focused on curation and moderation tools for editors. This (interesting) proposal is clearly out of scope for this team. Maybe it is a good candidate for #possible-tech-projects? I have commented in the task.--Qgil-WMF (talk) 11:49, 21 September 2015 (UTC)[reply]
Out of scope. MER-C (talk) 16:28, 14 November 2015 (UTC)[reply]
MER-C closed this proposal for being out of scope for the Community Tech team. It is, but I think it's still worthwhile to gauge community interest for this idea. It doesn't duplicate or conflict with a product team's current roadmap, so this can stay open. -- DannyH (WMF) (talk) 23:33, 18 November 2015 (UTC)[reply]


Endorsed proposals can be seen at Community Wishlist Survey 2015/Notifications.

Echo notifications for anyone "listening" besides the page's creator[edit]

I think we should use create the possibility to anyone start "listening" a page through Echo notifications as if this user was the page's creator (I think it is the same as T106991 in Phabricator). And, of course, to "stop it" whenever it wants. José Luiz talk 00:04, 10 November 2015 (UTC)[reply]

Make Ping independent of signature[edit]

Currently Ping needs a signature to work. If someone forgets to sign while pinging, ping won't work. I've seen lots of users who forget to sign at the first step, but will sign a few moments later and still expect to send their ping, while it is not sent! I think the MediaWiki software should be able to identify the ping operator, independent of signature. 4nn1l2 (talk) 23:03, 18 November 2015 (UTC)[reply]

The main reason this has never been implemented is that it would potentially cause unwanted pings when people copied and pasted discussions from one place to another (for example, when archiving discussions). Ryan Kaldari (WMF) (talk) 04:04, 25 November 2015 (UTC)[reply]
Comment Comment this could be implemented by a special "save" button that auto-appended the editor's signature then immediately made a new edit which removed the signature. It would be a kludge and it would have to account for race conditions/edit conflicts but if done correctly it wouldn't break anything and copy-and-paste would still work as one would expect it to. Davidwr/talk 22:32, 25 November 2015 (UTC)[reply]


Endorsed proposals can be seen at Community Wishlist Survey 2015/Reading.

Wikipedia checkpoint edition[edit]

What is the problem you want to solve?
One problem facing users of Wikipedia is determining whether an article they are reading has been vandalized. While I think we do a good job of catching and reverting vandalism, there is inevitably a time interval between the act of vandalism and its removal. Given the large number of people who use Wikipedia, some readers may access the article during that time interval. There is currently no easy mechanism to help readers check whether an article they are reading is in a vandalized state.
Which users would benefit? (editors, admins, Commons users, Wikipedia users, etc.)
This proposal primarily benefits users of Wikipedia. Editors would also benefit by simplifying checking article changes for errors.
How is this problem being handled now?
A knowledgeable user can employ our diff mechanism to see what changes have recently been made to an article, however there is no obvious base point to check from and the procedure may be too complex for most readers.
What are the proposed solutions?
I would like to propose a ‘’Wikipedia check-point edition’’ as a way to address this problem. Here's how it would work:
As of a certain day and time, not publicized in advance (say 2359 GMT on November 15, 2015), the current version of all articles would be recorded as a list, indexed by article name, consisting of permalinks to the latest version the article as of that date and time. An automated scripts would then “apply” certain subsequent edits made by auto confirmed users over, say, the subsequent two weeks. Applying an edit would mean replacing the permalink in the checkpoint list with that of a later or former version. Edits that would be applied automatically might include:
  1. rollbacks or reversions that are marked as vandalism removal
  2. edits marked as removing copyright violations
  3. Any article deleted in the time window (deletion scripts might be updated to delete from the checkpoint list as well)
  4. Articles created less than, say, two weeks earlier might also be excluded from the list as too immature.
Articles that are the subject of active dispute resolution or in the midst of an edit war as of the date and time might also be excluded so as not to favor one side in a dispute. For articles that have recently undergone a review, such as featured articles or good articles, the last reviewed version of the article would be the check point version.
Manual changes to the list would only be made on an exception basis by an admin, with notice on the article talk page and, perhaps, a notice board. The only acceptable reasons would be for clearcut vandalism not caught by the automated scripts, copyright violations and BLP violations. Errors of fact, POV bias, poor sourcing and other disputed material would NOT be a basis for changing the checkpoint edition. Changes to the checkpoint would be limited to substituting a later or earlier revision of the article to replace the one listed. Admins could also simply remove the article from the checkpoint list, if there was no other clean option available.
The goal would be to create a list or articles that reflect a vandalism free version of Wikipedia as of the check point time, using minimum human intervention. New checkpoint editions might be created every year or two, perhaps at a randomized time so as not to create an opportunity for editors to get POV material into articles just before they are check-pointed. Note that nothing in this proposed process would change the current content of Wikipedia articles or our normal editing process.
A tool or button on the article display would then be provided to view the check point version and to compare the current version by diff with the check point version. A reader concerned about the status of the article could compare it with the check pointed version, and then check the sourcing of any changes that seemed material. There would also be a mechanism to report uncaught vandalism in the checkpoint edition.
This proposal is not foolproof. There will always be some vandalism that is missed, but I believe such a mechanism would be a useful tool for readers concerned about the trustworthiness of Wikipedia. -- — The preceding unsigned comment was added by ArnoldReinhold (talk) 20 Nov 2015
@ArnoldReinhold: You could try installing ScoredRevisions, which indicates which edits in the history of a page have a high probability of being reverted, or being damaging. It uses data from ORES server for that.
I also created a few tables of non-reverted edits which have high probability of being damaging/reverted. See e.g. the table for dewiki. Helder 11:55, 22 November 2015 (UTC)[reply]


Endorsed proposals can be seen at Community Wishlist Survey 2015/Search.

Show Reasonator-style manual+automatic descriptions in Wikidata searches[edit]

User-provided description fields on Wikidata are often empty, or minimal. Make Wikidata search-page results easier to interpret, as Reasonator does, by including auto-generated descriptions as well as the stored ones -- compare Reasonator search vs usual search for "John Arbuthnot". Jheald (talk) 13:07, 13 November 2015 (UTC)[reply]

Special pages[edit]

Endorsed proposals can be seen at Community Wishlist Survey 2015/Special pages.

Talk pages[edit]

Endorsed proposals can be seen at Community Wishlist Survey 2015/Talk pages.

Standard way to be able to enable archiving of sections marked closed[edit]

It would be good to be able to mark sections 'closed' and for them then to be transferred to an archive.

Yes, I know that on some wikis there are bots set up that may be able to do this automatically; but I am not sure whether that is true on all wikis, or smaller wikis where nobody may be running such a bot. (eg on Wikidata, it would be nice to be able to implement this for d:Wikidata:Classification noticeboard, ideally together with searchable archiving, but I have no idea how to set this up).

Yes, I also know that Flow can sort-of do this; but it would be nice to be able to do this in a conventional wiki talk page environment, with archiving to conventional editable wiki pages, without having to adopt everything else about Flow. Jheald (talk) 13:37, 13 November 2015 (UTC)[reply]

We just need a proper talk page tool like LQT/Flow for talk pages and most of these problems go away. Helder 12:25, 22 November 2015 (UTC)[reply]


Endorsed proposals can be seen at Community Wishlist Survey 2015/Templates.


Endorsed proposals can be seen at Community Wishlist Survey 2015/Watchlists.

Shared watchlists[edit]

It would be nice to be able to share a common watchlist between legitimate alternative accounts. Currently, watchlisted items must be manually copied between accounts. Any editor with an alternative account who uses watchlists would benefit. There is already a "key" that allows a watchlist to be exported via a feed, so adding the ability to input that key into a different account should be fairly simple. Example of how this might be used: I have my main account (Etamni) as well as a declared alternative account used for mobile edits and edits from shared computers or public WiFi (Etamni-m). This ability would allow me (or others in similar positions) to use a master watchlist for both accounts. If I add or remove a watchlist item from either account, the change would apply to both accounts automatically. This would be an opt-in feature and would not apply to editors who don't want to use it. Etamni (talk) 08:17, 17 November 2015 (UTC)[reply]

One could create a page X in your userspace that links the pages to be watched, then go to Special:Recentchangeslinked/X. MER-C (talk) 12:14, 17 November 2015 (UTC)[reply]
I'm not sure how that would work for editors who watch hundreds or thousands of pages. I welcome new users and warn vandals with Twinkle, and add their user pages to my watchlist automatically. I also add any page where I correct vandalism or fix other unhelpful edits. Throw in other users' talk pages, a few drama boards, and the pages I'm actually interested in, and maintaining a separate list to watch would quickly become unwieldy. Etamni (talk) 09:00, 20 November 2015 (UTC)[reply]


Endorsed proposals can be seen at Community Wishlist Survey 2015/Wikidata.

Gender-specific labels for Wikidata objects[edit]

Slovene and other Slavic languages (and perhaps some others too) use gender-specific words to describe occupation of a person, with male form being default. It would be useful to add a descriptor M/F to an object's description in a given language, and enable targeted transclusion of this data to Wikipedias. Then, infoboxes for women could be auto-filled with appropriate words. This would of course necessitate creating a second label for the variant for the other gender, so I don't know it it's really feasible, but it's something to think about.

This functionality is already being discussed at Wikidata (see d:Wikidata:Property proposal/Unsorted#Female form of label (string)), but maybe additional attention would help to find a solution. — Yerpo Eh? 12:05, 10 November 2015 (UTC)[reply]

Oppose Oppose. Recruitment companies in most of these countries are working at creating gender neutral labels for occupations and these are what we should be using for labels in all languages in Wikidata because the wikidata items are gender neutral so any label that isn't is a label that is wrong. This is just as the English words 'actor' and 'waiter' have, over the last twenty years, come to mean either a man or a woman. The solution to this problem is first to resolve a way to give these occupations gender neutral labels ('programador/a' or even 'programador or programadora'). That is not a technical problem the Community Tech can help with.
Once we have the gender neutral labels sorted then we can look at whether we also need properties for the male and female versions and a couple of lines of Lua code to find them or if we can just switch to using the gender neutral labels in wikipedia infoboxes in all languages. Filceolaire (talk) 06:47, 13 November 2015 (UTC)[reply]
@Filceolaire: gender-neutral labels are of course possible, but cumbersome if the purpose is to fill infoboxes. We aren't recruiting unknown people to fulfill some roles, we are describing existing men and women (in other words, Ada Lovelace is not a programador/a, she is a programadora). I don't understand why should we condition looking for solution with setting up an inelegant system. Instead, an inelegant system should be put in place if a better solution is not possible. — Yerpo Eh? 07:49, 13 November 2015 (UTC)[reply]
It is a failing of Wikidata that it does not support this. It is a deliberate choice and we suffer from its consequences. It is an obvious issue of cultural determinism. Thanks, GerardM (talk) 07:40, 20 November 2015 (UTC)[reply]

Reasonator as stub page handler[edit]

See also Filling red links with Wikidata

On a small wiki, visiting any missing page or searching for a page not on the wiki should load up Reasonator in the local wiki language. For example, the Johann Sebastian Bach info page can and should be shown on all 272 wikis that don't have a J.S. Bach page. Global south!


Browser widget to fill Wikinewses' source templates[edit]

Several Wikinews languages make use of templates to cite sources which metadata have to be copied and pasted from another browser tab, e.g. title, publisher, date, URL what requires several copy and pastes. The idea is to get a browser widget for Firefox which allows to copy all meta data and fill in within one edit.

Pityfully those templates differ slightly, e.g. n:en:Template:Source vs. n:de:Vorlage:Quelle, nevertheless I believe that it would require only a few lines of JS code, so me tech-iot thinks it could be easily done. --Matthiasb (talk) 16:31, 21 November 2015 (UTC)[reply]


Endorsed proposals can be seen at Community Wishlist Survey 2015/Wikisource.


Endorsed proposals can be seen at Community Wishlist Survey 2015/Wikiversity.


Endorsed proposals can be seen at Community Wishlist Survey 2015/Miscellaneous.

Identify the most burdened Wikimedians[edit]

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]

Text-to-speech for phonetically spelled words[edit]

I realize this may be a bit out of scope but I wanted to throw it out there...

It would be very useful to have some mechanism that would generate a sound file from phonetically spelled words, at least in English. Right now if one clicks on a phonetically spelled word (e.g. one tagged as a IPAc-en inline template), one is directed to a pronunciation key. It would be nice if wikimedia created some sort of function that would also sound out the word say in an .ogg file. Wikiliki (talk) 17:30, 9 November 2015 (UTC)[reply]

Or even just a tool that made it easy for anyone to record a sound file of the pronunciation and add it. Filceolaire (talk) 05:56, 10 November 2015 (UTC)[reply]

Virtual computer keyboard in search field[edit]

It would be good to introduce a virtual computer keyboard in search field (like in Google search field). There are moments when you can not use the keyboard. For example. I had two occasions when I broke my keyboard. Without a keyboard I could not type anything in the search field of Wikipedia. And this was very unpleasantly surprised me, because I was effectively denied access to Wikipedia. — Green Zero обг 10:19, 10 November 2015 (UTC)[reply]

@Green Zero: Your operating system already has a virtual keyboard. Windows users can find it at %SystemRoot%\system32\osk.exe and Macintosh users can follow these instructions. The Quixotic Potato (talk) 14:23, 12 November 2015 (UTC)[reply]
Oppose Oppose as unnecessary. MER-C (talk) 16:34, 14 November 2015 (UTC)[reply]
Oppose Oppose I broke my CPU, I was unpleasantly surprised to discover I was effectively denied access to Wikipedia (chuckle). I'm not opposed to this functionality per se, but I'm opposed to this taking the slot of more valuable Community Wishlist projects. Alsee (talk) 00:10, 15 November 2015 (UTC)[reply]
Yes, virtual keyboard is very complicated thing for programmers. — Green Zero обг 16:24, 15 November 2015 (UTC)[reply]

Mailman emails passwords in cleartext[edit]

Mailman, the GNU Mailing List Manager, emails passwords in plain text... This should be fixed ASAP. The Quixotic Potato (talk) 12:29, 14 November 2015 (UTC)[reply]

There's nothing here the Community Tech team can help with, unfortunately. MER-C (talk) 13:06, 16 November 2015 (UTC)[reply]

Multiple redirects in one time[edit]

See my idea. --Edgars2007 (talk) 07:19, 28 May 2015 (UTC)[reply]

FWIW, when I have to create many redirects on it.wiki, I just add a bunch of aliases on Wikidata and then wdsearch informs the users. --Nemo 18:39, 31 May 2015 (UTC)[reply]

Students Wiki knowledge tracking, for educators[edit]

Supervision of Wikipedia students' progress, in detail
Educators / instructors, Wikipedia education, Wikimedia movement through evaluation statistics
Curently addressed
Personal notes / databases unlinked to user accounts
Start developing evaluation tools

--ManosHacker (talk) 11:51, 16 November 2015 (UTC)[reply]

Older ideas[edit]

Turn HotArticlesBot into a publicly available service[edit]

HotArticlesBot is a ToolLabs bot that creates lists of articles that have been frequently edited within the past few days (typically as a subscription service for WikiProjects). The lists are based on the articles belonging to a particular category or including a particular template. It would be nice if there was a public interface that anyone could use to configure the lists that HotArticlesBot generates (via OAuth). It would also be nice if it supported projects besides English Wikipedia.

wikiproject.json is a publicly editable configuration file that will be used by my scripts for per-project configurations. HotArticlesBot and other bots are welcome to use it to store configuration data. harej (talk) 19:17, 11 May 2015 (UTC)[reply]

Expand on Magnus's ToolLabs tools[edit]

Magnus Manske has created dozens of useful community tools on Tool Labs. Many of these could be expanded, updated, or improved in various ways. Most of the code for his tools is publicly available on bitbucket.

Build better PHP API framework for MediaWiki[edit]

There are probably at least a dozen PHP API frameworks for MediaWiki. Most of them are old and with limited features. It would be nice to have one feature-rich well-maintained PHP framework that people could use for a wide variety of projects, similar to pywikibot for Python.

Build JavaScript API framework for MediaWiki[edit]

There is a small Node.js framework for MediaWiki as well as a fair bit of JavaScript API code within the MobileFrontend extension. These could be used as the basis for building a robust JavaScript API framework for MediaWiki.

Cool, but needs more details. Is this for use by external clients (the first link), external web pages, or on wiki pages (the Mobilefrontend link)? If the last one, how does it relate to the mediawiki.api module? -- SPage (WMF) (talk) 21:29, 15 May 2015 (UTC)[reply]

Timeline graphs of changes in article number and quality for WikiProjects[edit]

It would be nice to give WikiProjects a historical overview of the number and quality of their articles. This would require keeping a record of this data in a dedicated database on Tool Labs. Should investigate coordinating with WP 1.0 bot.

Admin dashboard (shows edit wars, blocks, etc)[edit]

Create a dashboard on Tool Labs or a Special page that shows information especially relevant to admins.

Based on data from were? Is this number of blocks admin has made or recent blocks that have occurred? Doc James (talk · contribs · email) 07:18, 28 May 2015 (UTC)[reply]
It would be based on log and revision data from the MediaWiki database (or a mirror of the database). It would show recent blocks that had occurred. Kaldari (talk) 18:33, 16 July 2015 (UTC)[reply]
phab:T91655?--Qgil-WMF (talk) 08:23, 2 June 2015 (UTC)[reply]
That bug is about a dashboard for editors, but also mentions the idea of a dashboard for admins. Kaldari (talk) 18:33, 16 July 2015 (UTC)[reply]

Add Template Editor into WikiText editor[edit]

You mean within visual editor? Doc James (talk · contribs · email) 07:15, 28 May 2015 (UTC)[reply]

Bot to generate list of worst lead sentences on Wikipedia[edit]

Not sure how this idea would work? Based on what criteria? And why would we need a bot to do it? Users can simple go through articles. Lead sentences are really hard to write. Doc James (talk · contribs · email) 07:14, 28 May 2015 (UTC)[reply]

A nice disambiguator[edit]

WikiProject auto-invites[edit]

The impending WikiProject directory on the English Wikipedia will generate lists of active contributors to both the project space (the WikiProject page, talk page, subpages) and the project scope (articles and talk pages tagged by the WikiProject). This presents an opportunity for a bot to use this information for invitations. harej (talk) 19:19, 11 May 2015 (UTC)[reply]

User:Harej do you mean such that if a users first edit is on a medical article they will get an invite to WP:MED? Or is this also for long term editors who begin editing in a new area? Doc James (talk · contribs · email) 11:40, 27 May 2015 (UTC)[reply]
It would be opt-in on a project-by-project basis; so WikiProject Medicine could decide to use or not use such a service. The exact criteria for receiving an invitation would have to be nailed down. In the meantime, my reports list editors on the basis of having at least five edits in a project area in a one-month period, regardless of how old that account is. harej (talk) 13:37, 27 May 2015 (UTC)[reply]
It sounds like something that would be good to study. It could be set up to send invites to half the people who made at least 5 edits and not to half (those who have been previously send invites would not get another)
One could than look at if this effects the number of edits to that WP made over the next month. Doc James (talk · contribs · email) 01:04, 28 May 2015 (UTC)[reply]
This idea was piloted a couple years ago on Portugese Wikipedia (botrequest). I'm not sure what the outcome was, but it might be useful to get in touch with Alchimista or one of the other editors who was involved. Jmorgan (WMF) (talk) 23:16, 3 June 2015 (UTC)[reply]
On Portuguese Wikipedia is was used in a pilot project, it invited newbies to the local medicine project. I can't find retention stats, but if anyone find them usefull, i can get them. Alchimista (talk) 21:02, 23 June 2015 (UTC)[reply]

Tools to support conference program development[edit]

There are now registration tools, but there are not necessarily tools to support conference development.

  • The Wikimania programme committee utilizes a matrix to assess the committee's opinion on entries, however that matrix might be more challenging for some to manage. Might be helpful to either adapt these things to better use VE, or develop gadgets to help.
  • Session evaluation tool - a method of collecting evaluations on sessions.

I suspect there are other tools that could be helpful for consistent conference tasks.

See phab:T99809.--Qgil-WMF (talk) 08:24, 2 June 2015 (UTC)[reply]

Report tools[edit]

Recent reports by things like OTRS have gone outside the traditional wikicode based report mold. Is that something that other entities should be encouraged to do? If so, should there be tools to help them do that to lower the technical skills needed and timeload on more tech savvy volunteers involved in those groups? Especially if the methods they are using are similar each time.

What sort of reports do you refer to? Doc James (talk · contribs · email) 11:42, 27 May 2015 (UTC)[reply]

ContactPage interface[edit]

To remove the burden of updating text and basic setup from operations. Allows for wider usage for groups like AffCom.

Hiding UI elements[edit]

A very common request is to hide some element of the UI, but everyone has their own little pet peeves. The problem summarizes basically as: "We have 10000 UI elements and you can probably for each of those elements find one or more users who would like to hide it. 10000 UI options don't scale". My idea would be to make a gadget that alla 'Adblock' would allow you to highlight an area. The area would show the CSS selector for that part of the page. It then asks you to confirm if you want to hide this part only for this page or for all pages. We would save the result to global.css. Then everyone can adapt their user experience to their hearts content on their own responsibility. Some libs that could help with this: https://vimeo.com/52055686 and https://selectorgadget-plus.appspot.comTheDJ (talkcontribs) 18:14, 19 May 2015 (UTC)[reply]

"Inventory pages" or nice "to-do" displays for each Wikiproject[edit]

Moved to 2015_Community_Wishlist_Survey#Work_queues

Start a project -- a real project with measurable goals and a schedule -- to reduce page weight[edit]

Background: Page Weight Matters, by Chris Zacharias

"Three years ago, while I was a web developer at YouTube, one of the senior engineers began a rant about the page weight of the video watch page being far too large. The page had ballooned to as high as 1.2MB and dozens of requests. This engineer openly vented that “if they can write an entire Quake clone in under 100KB, we have no excuse for this!” Given that I agreed with him and I was excited to find a new project, I decided to champion the cause of getting the YouTube watch page to weigh in under 100KB. On the shuttle home from San Bruno that night, I coded up a prototype. I decided to limit the functionality to just a basic masthead, the video player, five related videos, a sharing button, a flagging tool, and ten comments loaded in via AJAX. I code-named the project “Feather”.
"Even with such a limited set of features, the page was weighing in at 250KB. I dug into the code and realized that our optimization tools (i.e. Closure compilation) were unable to exclude code that was never actually used in the page itself (which would be an unfair expectation of any tool under the circumstances). The only way to reduce the code further was to optimize by hand the CSS, Javascript, and image sprites myself. After three painstaking days, I had arrived at a much leaner solution. It still was not under 100KB though. Having just finished writing the HTML5 video player, I decided to plug it in instead of the far heavier Flash player. Bam! 98KB and only 14 requests. I threaded the code with some basic monitoring and launched an opt-in to a fraction of our traffic.
"After a week of data collection, the numbers came back… and they were baffling. The average aggregate page latency under Feather had actually INCREASED. I had decreased the total page weight and number of requests to a tenth of what they were previously and somehow the numbers were showing that it was taking LONGER for videos to load on Feather. This could not be possible. Digging through the numbers more and after browser testing repeatedly, nothing made sense. I was just about to give up on the project, with my world view completely shattered, when my colleague discovered the answer: geography.
"When we plotted the data geographically and compared it to our total numbers broken out by region, there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia. Further investigation revealed that, in these places, the average page load time under Feather was over TWO MINUTES! This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load! This was the penalty incurred before the video stream even had a chance to show the first frame. Correspondingly, entire populations of people simply could not use YouTube because it took too long to see anything. Under Feather, despite it taking over two minutes to get to the first frame of video, watching a video actually became a real possibility. Over the week, word of Feather had spread in these areas and our numbers were completely skewed as a result. Large numbers of people who were previously unable to use YouTube before were suddenly able to.
"Through Feather, I learned a valuable lesson about the state of the Internet throughout the rest of the world. Many of us are fortunate to live in high bandwidth regions, but there are still large portions of the world that do not. By keeping your client side code small and lightweight, you can literally open your product up to new markets."

Source: [ http://blog.chriszacharias.com/page-weight-matters ]

(Emphasis added, capitalization in original.)

(Reproduced under fair use: "The first factor is regarding whether the use in question helps fulfill the intention of copyright law to stimulate creativity for the enrichment of the general public, or whether it aims to only 'supersede the objects' of the original for reasons of personal profit.")

Given the above, I think that we should start a project -- a real project with measurable goals and a schedule -- to reduce page weight. --Guy Macon (talk) 22:21, 21 May 2015 (UTC)[reply]

Yes agree. I am unable to write on some users talk pages when I am travelling because they are too big. Doc James (talk · contribs · email) 03:39, 22 May 2015 (UTC)[reply]
This goes absolutely to the core of our mission, so a project is a good idea but there is work done on it already. I'd be interested to hear from the WMF how much priority/work is given to decreasing page weight. Maybe it's already been set as a goal? As for talk pages, perhaps there isn't a technological solution: maybe users should be nudged/helped to archive more frequently? MartinPoulter (talk) 14:36, 27 May 2015 (UTC)[reply]
Yes with respect to talk pages the push likely needs to come from the community. Editors need to be informed that they do not own their talk page and that it is like all other pages to improve the encyclopedia. If people cannot post on yours as it is to long someone may archive it. Doc James (talk · contribs · email) 07:21, 28 May 2015 (UTC)[reply]
Are there any measures about page weight on Wikipedia. There is a load of one-time data about page structure and layout which is cached afterwards. Anything beyond is page content
A comparable project can be found under mw:ResourceLoader. Maybe it needs to be reevaluated.
-- Menner (talk) 16:14, 30 May 2015 (UTC)[reply]
@Guy Macon:: some of the subtlest and most crucial performance engineering is already being done by volunteers who optimize and refine Lua modules, so there is good precedent for editors making a positive contribution to site performance, and I'm happy to see this affirmed in your proposal. Could you elaborate a little on how you imagine this working out? What sort of things would you eliminate to reduce page weight? I suspect that the biggest impact could be made by conducting an audit of on-by-default gadgets and site JS / CSS across major wikis and doing some initial triage by ranking gadgets in order of size and popularity. This would be very valuable work, and you would definitely have partners for this work in WMF Engineering. I can elaborate further, but I want to stop and check with you if this is consistent with what you had in mind, or if I'm missing the mark. --Ori Livneh (talk) 21:45, 30 May 2015 (UTC)[reply]

I would love to help the WMF in any way that I can in this area.

Before I get into the details of what I have in mind, I want to make sure that everyone reading along understands that this only concerns number of HTTP requests a page makes and the total number of bytes sent to the browser (the page weight). It has nothing to do with how hard Wikipedia's servers have to work to generate those HTTP requests and bytes of data. The gold standard is low page weight on the first access to a page, but making it so that subsequent accesses get as much data from local cache instead of from Wikipedia's servers is also an important factor in reducing page weight. Also optimizing for mobile (optimizing for a small screen, no mouse/keyboard, low-power CPU, and moderately limited bandwidth) is not the same problem as optimizing page weight (optimizing for severely limited bandwidth and nothing else). I cannot emphasize this strongly enough.

The above is a good description of the general idea I have in mind, but I would go about it in a somewhat different way. First I would split the problem into two problems:

  1. Reduce page weight without changing anything that is visible to the user.
  2. Reduce page weight by changing what the user sees.

Work on the second problem should be delayed until we have done all we can to solve the first problem.

Next, I would look at a few of our most-accessed pages (especially the main pages at www.wikipedia.org and en.wikipedia.org) and analyze exactly how many HTTP requests and bytes of data it takes to display them. Do those gadgets and JS / CSS add a lot of bytes? Or are the images a larger problem? Is there any place where we can replace two HTTP requests with one? Measure first, then optimize where it does the most good.

I am going to break my own rule now and talk about optimizing the talk page you are reading. I am doing this because every time I bring this up someone inevitably says that Wikipedia is already doing pretty much all that it can to reduce page weight. I am not implying that the following should or should not be a high priority before we do the measuring I discuss above.

Even simple text-based pages such as this talk page can be optimized.

Consider the following snippet from the thread above:

[...] Maybe it needs to be reevaluated.
-- Menner (talk) 16:14, 30 May 2015 (UTC)
@Guy Macon:: some of the subtlest and most crucial performance engineering is already being done [...]

That's 180 displayed characters, plus whatever it takes to make the links, bold, etc. work.

The wikimarkup for the above is really quite compact:

[...]Maybe it needs to be reevaluated.
: -- [[User:Menner|Menner]] ([[User talk:Menner|talk]]) 16:14, 30 May 2015 (UTC)
:{{Ping|Guy Macon}}: some of the subtlest and most crucial performance engineering is already being done[...]

That's 225 characters, and you get the the links, bold, etc.

Now let's look at the HTML sent to the browser:

[...] Maybe it needs to be reevaluated.</dd>
<dd>-- <a href="/wiki/User:Menner" title="User:Menner">Menner</a> (<a href="/wiki/User_talk:Menner" title="User talk:Menner">talk</a>) 16:14, 30 May 2015 (UTC)</dd>
<dd>@<a href="/wiki/User:Guy_Macon" title="User:Guy Macon">Guy Macon</a>:: some of the subtlest and most crucial performance engineering is already being done [...]

Now we are at 406 bytes sent to the browser (ignoring compression for the sake of argument, because I would have to post what looks like random garbage above. When we do the measuring, compression should be taken into account).

So, can we reduce that page weight?

First. every line sent to the browser has a DOS-style carriage return and line feed (OD OA) as a line ending. If we used a Unix-style line feed (0A) that would save one byte on every single line of HTML on Wikipedia.

Actually HTML works just fine with both the carriage return and the line feed removed, but it isn't as readable for geeks like me who look at the raw HTML output. This is easily addressed by making the HTML line ending configurable in the preferences.

OK, how about that "title=" in the link? Can we get rid of that?

So right there we have a bunch of useless bytes sent to the browser for every signature. They have zero benefit to anyone. All they do is increase the page weight.

I could go on and on with other obvious ways to optimize this page without changing what the user sees, but again, the first step is to measure the page weight of various pages and identify where we will get the most benefit for the least effort.

I am open to help WMF in any way that I can in order to make this happen. I will tell you, though, that measurable goals and a schedule are non-negotiable. I have worked on too many engineering projects to let my name be associated with a project that lacks measurable goals and a schedule. See [ http://www.guymacon.com/structuredengineering.html ] for some reasons why. --Guy Macon (talk) 08:40, 31 May 2015 (UTC)[reply]

I humbly suggest that your focus on HTML bytecount is a bit misplaced. Some other useful readings which were shared elsewhere by the mw:site performance people and others: http://www.nngroup.com/search/?q=performance , https://docs.google.com/presentation/d/1MtDBNTH1g7CZzhwlJ1raEJagA8qM3uoV7ta6i66bO2M/present --Nemo 18:52, 31 May 2015 (UTC)[reply]
You are presenting data that (correctly) claims that for those of us in the first world with adequate internet bandwidth there are more important things than HTML requests and byte counts, but you have completely failed to address my argument that in rural third-world areas with severely limited bandwidth high page weight makes websites completely unusable. Try using a 1200 baud dial-up modem with its typical 300ms latency to connect to the Internet and see how you like trying to access websites with a high page weight. --Guy Macon (talk) 19:38, 31 May 2015 (UTC)[reply]
Assessment of that kind of very poor networking is precisely what I linked those resources for. --Nemo 08:45, 18 June 2015 (UTC)[reply]
phab:T98986 seems related, especially if it is true that in "rural third-world areas" the Internet is basically accessed with mobile devices.--Qgil-WMF (talk) 10:04, 18 June 2015 (UTC)[reply]
It isn't true. In urban third-world areas the Internet is basically accessed with mobile devices. Once you get out of the range of cell phone towers and (relatively) high incomes, the Internet is largely accessed by a village-full of obsolete laptops all sharing a single Wifi connection with an extremely limited-bandwidth connection to the rest of the world. Read the Page Weight Matters essay at the top of this thread. Those Youtube users almost certainly were not using phones to access the net. Low bandwidth Wikipedia access and mobile Wikipedia access are two separate problems. Mobile has somewhat limited bandwidth, small screens, no keyboard, and slow processors designed to extend battery life. Low bandwidth has extremely limited bandwidth, with typical older laptop screen size, processor and keyboard/mouse. --Guy Macon (talk) 00:32, 8 July 2015 (UTC)[reply]
This doesn't sound like it's in the scope of the Community Tech team. I believe Ori has been working on this recently, though. Kaldari (talk) 18:01, 7 July 2015 (UTC)[reply]
Is that a personal opinion or are you speaking on behalf of the WMF? And can you point to the description of exactly what would be "in the scope of the Community Tech team"? Oh wait, there isn't one. Didcot power station (talk) 19:19, 7 July 2015 (UTC)[reply]
This is just the standard WMF stonewalling technique. When anyone posts any sort of proposal -- even in places specifically designated as being for proposals -- a WMF employee tells him or her that it was posted in the wrong place with no indication as to where the right place might be. Sometimes, just for variety, they suggest another place and then you get stonewalled when you go there. Its all very predictable after you have experienced it a half a dozen times. --Guy Macon (talk) 00:32, 8 July 2015 (UTC)[reply]
Indeed, it is just two years since this was illustrated at MediaWiki [1]. And every time it happens it demonstrates that this "Community Tech" process is a sham. We were told recently [2] by a WMF employee that "no WMF employee will say much on behalf of the Community Tech team before the Community Tech team lead is hired and announced". Yet Kaldari, a WMF staff member, tells us what the scope of the project is. So I challenge them, give us some reason to believe that this project is not a huge sham by publishing the scope here and now. No real project would be set up and staffed without someone, somewhere, having a clear idea about scope. If there is a scope, publish it. If not, why not, and why is he trying to put off volunteers by making guesses about what it might be? Didcot power station (talk) 06:47, 8 July 2015 (UTC)[reply]
If we want this page to be useful, we need to add ideas... but also remove them when they can be addressed better elsewhere. Reducing page weight fits squarely within the scope of the Performance team lead by Ori Livneh, who added a comment above. This interesting proposal is getting into deep details, and it deserves a more productive context for discussion and work than a segment in a huge wiki page with many unrelated updates. I have created phab:T105136. There you can subscribe, capture what matters in its description and you can find or create subtasks, blockers, related tasks.--Qgil-WMF (talk) 11:11, 8 July 2015 (UTC)[reply]

Frequently Unanswered Questions about this proposal[edit]

Line feed[edit]

Frequently Unanswered Question # 1:

In the HTML that Wikipedia sends to the browser, every line sent to the browser has a DOS-style carriage return and line feed (OD OA) as a line ending. If we used a Unix-style line feed (0A) that would save one byte on every single line of HTML on Wikipedia. Actually HTML works just fine with both the carriage return and the line feed removed, but let's just discuss (OD OA) vs (OA) for now. We could do this by making the line ending configurable in nthe preferences with the default (OD OA) and (OA) an option, then after we are sure there are no bad effects, change the default. Why am I unable to get anyone at the WMF to discuss the merits of doing this? --Guy Macon (talk) 00:26, 8 July 2015 (UTC)[reply]

title attribute[edit]
Tracked in Phabricator:
Task T2542

Frequently Unanswered Question # 2:

OK, how about that "title=" in the HTML output for our signatures? Can we get rid of that?

So right there we have a bunch of useless bytes sent to the browser for every signature. They have zero benefit to anyone. All they do is increase the page weight. Why am I unable to get anyone at the WMF to discuss the merits of doing this? --Guy Macon (talk) 00:26, 8 July 2015 (UTC)[reply]

There are gadgets/user scripts that rely on that. Mostly because a link can be a redirect. Navigation popups uses this for instance. Perhaps we can output them only when there are redirects, but still those scripts relying on it's presence will break. —TheDJ (talkcontribs) 21:55, 12 July 2015 (UTC)[reply]

Local Wikibase Repository[edit]

It would be great to have some storage for pages metadata. For example, there are different projects in wikipedia, and currently status and priority of an article within a topic are stored on talk page in templates like en:Template:Vital article. It would be easier to manipulate and analyze such data if it is stored in something like Wikidata. But this data is helpful only for specific wiki, so thats my idea: local Wikibase for each wikimedia project! --AS (talk) 16:42, 27 May 2015 (UTC)[reply]

Hit counter extension[edit]

MediaWiki no longer includes hit counters in core, following a request for comment, which means that Special:PopularPages and the "Most Viewed Pages" section of Special:Statistics are now removed. The hit numbers, which occurred until the 1.25 upgrade was installed, will still be kept in the database, but they will no longer be updated. It is planned to re-implement this functionality in an extension.

Has the extension been started? Is there any timeline of its planned development --PhotographerTom (talk) 19:31, 27 May 2015 (UTC)[reply]

How is this relavent to community tech. The hitcounter feature was not used on wikipedia, and is inherently unsuitable to the architecture that wikipedia (and other wikimedia wikis) use. Thus its not in scope of the community tech team, at least as I understand their scope. (However, to answer your question, User:MarkAHershberger was working on this I believe). Bawolff (talk) 04:18, 10 June 2015 (UTC)[reply]


I have been contributing to nl.wiktionary for a long time and I am now trying to overhaul the en.wikibook Dutch that I wrote a long time ago and I am very frustrated at how primitive and inadequate wikisoftware is when it comes to interactivity, even such passive interactivity where readers can push a simple button to hear the pronunciation of a word.(Let alone the kind of interactivity of websites like Memrise or Quizlet, I'm not even talking about that. In fact instead I send my readers to Quizlet to go practice there, because I don't have much hope that wiki will ever be able to do what they are doing.)

First of all it took years before it became even reasonably feasible to upload pronunciation files to commons. Luckily that has been streamlined enough that there is a treasure trove of sound files there. But now the question is whether you can actually use them. The only way that I have sound that comes even close to what I need to let people learn some language from my page is

[[file:nl-geweldig.ogg|noicon|40px]] geweldig
resulting in


All other templates like audio etc. either result in something HUMONGOUS or in something that abducts my readers away from the text I want them to read while listening, to some primitive black screen.

Even the simple arrow as above has its problems. It is still too big and it does not match the size of a line of text. It cannot be used inside a piece of text and the only way I have found that suppresses the automatic line feed is to put in "left"

[[file:nl-geweldig.ogg|noicon|left|40px]] geweldig


Unfortunately, you can only do that once, otherwise you get a mess


So, the logical thing would to put it in a table, but look what happens inside a collapsible wikitable, which apparently doesn't work here, so please follow me to the french wikibook and open the two boxes saying "Solution" to see what I mean. Also look at the convoluted way I put all my arrows in. It was necessary, I assure you otherwise the mess is even greater. I spent an hour trying to defeat this wonderful software..

So my tech idea? To actually start worrying about how primitive this wonderful software is. Am I insulting you with that? Then please look around on the internet and you will find videos that start whether you want them to or not or websites that suddenly start talking to you and ask for your input. You don't even have to push a button...

Jcwf (talk) 23:44, 9 June 2015 (UTC)[reply]

To be honest, it was difficult to understand what your actual complaint was (Other then that our support for audio/video multimedia sucks, which I think everyone agrees with). After reading a couple times, you basically want an inline play button for audio files, in order to make something more like:
1.Ik houd niet van vis.
2.Ik kan geen kaas eten.
3.Ik houd van sinaasappelsap.
4.wij eten spaghetti.

? Bawolff (talk) 04:44, 10 June 2015 (UTC)[reply]

Cross-project watchlists[edit]

Merged to 2015_Community_Wishlist_Survey#Cross-wiki watchlist

Already completed or in progress[edit]

Add a Category watchlist[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I've got good news on this one :) TCB, Wikimedia Deutschland's Community Tech team, has been working on a Category watchlist, and we should see the first deployments within the next few weeks. You can check out the Phabricator ticket for more details. -- DannyH (WMF) (talk) 22:54, 18 November 2015 (UTC)[reply]

Tracked in Phabricator:
Task T9148

Add a category watchlist feature, that lists all changes, additions to, and removals from a category. En-Wiki has HUGE maintenance backlogs dating back to 2006 or earlier in categories like Articles lacking sources. I don't think those backlogs would be as bad if we could watchlist categories and know when an article was added to them. Likewise, some articles have a significant overlap, and if interested editors could watchlist categories and see when new articles were added to categories it would help avoid unnecessary duplication of content. ONUnicorn (talk) 14:11, 8 November 2015 (UTC)[reply]

  • This is currently being worked on right now by the German TCB Team and will be made available in the coming months. See the linked ticket for details. I Endorsed Endorsed this, by the way, if Community Tech can help get this out the door faster. MER-C (talk) 14:19, 8 November 2015 (UTC)[reply]
  1. Endorsed Endorsed I need that too. JackPotte (talk) 23:02, 9 November 2015 (UTC)[reply]
  2. Endorsed Endorsed --Ilya (talk) 23:11, 9 November 2015 (UTC)[reply]
  3. Endorsed Endorsed --Nicolabel (talk) (sysop in it.wp) 23:18, 9 November 2015 (UTC)[reply]
  4. Endorsed Endorsed --JarrahTree (talk) 00:19, 10 November 2015 (UTC)[reply]
  5. Endorsed Endorsed Beeblebrox (talk) 00:41, 10 November 2015 (UTC)[reply]
  6. Endorsed EndorsedDavey2010Talk 00:53, 10 November 2015 (UTC)[reply]
  7. Endorsed Endorsed Esquilo (talk) 08:06, 10 November 2015 (UTC)[reply]
  8. Endorsed Endorsed בנימין (talk) 15:05, 10 November 2015 (UTC)[reply]
  9. Endorsed Endorsed --Yann (talk) 16:08, 10 November 2015 (UTC)[reply]
  10. Endorsed Endorsed WereSpielChequers (talk) 19:26, 10 November 2015 (UTC)[reply]
  11. Endorsed Endorsed Fluffernutter (talk) 17:22, 11 November 2015 (UTC)[reply]
  12. Endorsed Endorsed Sarah talk 21:41, 11 November 2015 (UTC)[reply]
  13. Endorsed Endorsed absolutely yes! --Helichrysum Italicum (talk) 08:04, 13 November 2015 (UTC)[reply]
  14. Endorsed Endorsed Jheald (talk) 13:10, 13 November 2015 (UTC)[reply]

This feature is now in core MediaWiki, but disabled by default. @Addshore: What else needs to be done for this to be deployed and enabled? MER-C (talk) 13:22, 14 November 2015 (UTC)[reply]

Oppose Oppose calling this a new "Community Tech project". This is obvious very valuable, but it appears to be completed, deployed, and awaiting routine-review(?) to flip the on-switch. Alsee (talk) 13:11, 15 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Cross projects notifications[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This is an excellent idea. In fact, it's one of the Collaboration team's quarterly goals for Oct–Dec 2015, and they're actively working on it. See T114350 for more details. So it doesn't make sense as a project for Community Tech :)—Neil P. Quinn-WMF (talk) 19:59, 11 November 2015 (UTC)[reply]

Notify me when my name is mentioned or I receive a comment on meta in another project (Tell me on mediawiki that I was mentioned in meta).

Endorsed Endorsed +1 --AS (talk) 16:31, 27 May 2015 (UTC)[reply]
Endorsed Endorsed+1 --Edgars2007 (talk) 07:11, 28 May 2015 (UTC)[reply]
Endorsed EndorsedI agree we need to get cross project notification running. Doc James (talk · contribs · email) 07:22, 28 May 2015 (UTC)[reply]
Endorsed Endorsed --Jarekt (talk) 16:56, 11 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Cross-wiki alerts[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate of Cross projects notifications. MER-C (talk) 11:47, 11 November 2015 (UTC)[reply]

Alerts are for matters that require urgent attention, like mention in a discussion or proposed deletion of a picture I uploaded. It is sad that I almost always see these alerts when I happen to come back to that particular wiki, where it is usually too late. Syced (talk) 07:30, 11 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Develop tools to convert Flow and LQT pages to normal talkpages[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
If that hypothetical scenario ever did become true, the proposed tool would be fully-developed. The WMF has a duty and intends to maintain or improve the extension, and that extends through all the standard software life-cycle phases. Quiddity (WMF) (talk) 00:38, 14 November 2015 (UTC)[reply]

In the not too distant future the Flow project will be abandoned and people will be forced to admit that it failed (just like LQT). When the inevitable happens, we need to have a way to convert the messy and unreadable Flow and LQT pages back to talkpages. The Quixotic Potato (talk) 05:46, 21 July 2015 (UTC)[reply]

Subsequent discussion moved to this talk page. Rogol Domedonfors (talk) 06:25, 26 July 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Gadget statistics[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Completed by Community Tech team. Ryan Kaldari (WMF) (talk) 19:36, 29 November 2015 (UTC)[reply]

Resolved. now there is Special:GadgetUsage at each project. --Edgars2007 (talk) 11:25, 12 November 2015 (UTC)[reply]
See also: Gadgets and mw:Extension:Gadgets/Roadmap.

Statistics on gadgets usage (number of users like for beta-functions). It is currently unclear, which old gadgets should not be maintained anymore. --AS (talk) 09:26, 30 May 2015 (UTC)[reply]

Endorsed Endorsed Yes we list the number of people using the beta features [3] so one would think this would not be too difficult. Doc James (talk · contribs · email) 10:40, 30 May 2015 (UTC)[reply]
Endorsed Endorsed I think, that beta features and gadgets are quite different story, but yes, it would be nice for developers to see, which gadgets are used more (are more popular), so they can be developed more. --Edgars2007 (talk) 07:27, 31 May 2015 (UTC)[reply]
I made a proposal (with wireframe sketch) at mw:Talk:Requests for comment/Redesign user preferences#Gadgets for a potential upgrade to the gadgets tab, which would include usage numbers (+other info).
The main hub of notes/links is mw:Extension:Gadgets/Roadmap. --Quiddity (WMF) (talk) 22:38, 1 June 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

JS scripts without import[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Mostly implented recently. Good enough for now. -- Menner (talk) 07:11, 21 November 2015 (UTC)[reply]

It would be nice to have special area where JS scripts can be placed. That could be a namespace like script: and only users with assigned rights can edit them. This scripts will be executed by every visitor of that page.

In a more relaxed scenario these script pages might be embedded into common wikipages like templates similar to LUA.

The advantage over imported commons:COM:User Scripts is that it requires no obscure technical methods before the scripted features can be used.

An example might be to realize advanced search bars, special upload tools, diffrent kind of calculators, template filling forms with wikitext generator or in my case a replacement of commons:com:SVG Check and maybe other tools that currently require specific wmf tool server.

--Menner (talk) 18:40, 24 August 2015 (UTC)[reply]

The Gadget namespace was added recently, as part of Gadgets 2.0 (phab:T31272). Helder 15:23, 27 August 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Searchable contributions[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Tool for this already exists and there's no obvious way to improve it. Ryan Kaldari (WMF) (talk) 19:32, 29 November 2015 (UTC)[reply]

It would be nice to be able to search one's contributions by edit summary or such. For example, I label my proposed deletions as such, and then I check on them once or twice a year. Currently I have to look at 1000+ entries, and do a search for them using a browser function. Would be nice if this was doable through the contributions page itself. --Piotrus (talk) 05:04, 10 November 2015 (UTC)[reply]

Hmmm... There is such link at the bottom of user contributions page ("Edit summary search"), at least at enwiki. Or you are thinking about something else? --Edgars2007 (talk) 05:49, 10 November 2015 (UTC)[reply]
User:Edgars2007: wow, I never noticed that. Ha. Thanks. Through in this case I'd revise my request to: make the tool work faster. It's been chewing on my query for several minutes now... (Finished: Elapsed time: 332.21 seconds. ) --Piotrus (talk) 03:28, 12 November 2015 (UTC)[reply]
As in that tool is used the biggest Wikipedia database table (revisions), I think it can't be faster. --Edgars2007 (talk) 11:20, 12 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Structured metadata for Commons[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Work on this proposal is currently underway by the Wikidata team, and we should see the first user-facing results of that work in early 2016. I'm sure the Wikidata team is cheered by the level of support shown for this proposal. :) -- DannyH (WMF) (talk) 20:34, 24 November 2015 (UTC)[reply]

We should resume the Structured metadata for Commons project. A lot of the problems Commons currently faces come from the fact that MediaWiki is not a very suitable content management system for media files. With structured metadata it does become a much more flexible and scalable content management system. All user groups would benefit from a better functioning Wikimedia Commons: It's easier to find suitable images, easier to classify images, more accessible, etc. Multichill (talk) 18:48, 10 November 2015 (UTC)[reply]

Also it would mean Commons (and the names of Commons Categories) could be localised in lots of languages. Filceolaire (talk) 16:54, 12 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

SVG Help Button[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Completed on my own -- Menner (talk) 12:45, 15 November 2015 (UTC)[reply]

Besides improving SVG rendering it would be useful to have a "SVG Help Button". Like the Media Viewer button it could be placed below SVG files on Commons media meta pages visible only for loged-in users. Because SVG itself as a non-WYSIWYG format has many pitfalls, it is important to give guidance to contributors.

Until end of 2015 I'll make a prototype with an idea of its look and feel based on user scripts.

--Menner (talk) 18:11, 29 June 2015 (UTC)[reply]

Endorsed Endorsed +1 Absolutely needed and simply to implement!! ↔ User: Perhelion 07:39, 3 July 2015 (UTC)[reply]
By copying commons:User:Menner/common.js on can try out how this SVG button might look like --Menner (talk) 12:39, 8 August 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Wikitext paste conversion tool interferes with table pasting from MS Word for one user(?)[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Fixed, will be deployed on the 8th if all goes to plan. MER-C (talk) 08:49, 2 December 2015 (UTC)[reply]

Till last week Whenever I was coping table form ms word and pasting that in visual editor, than that table was converted in wikitable format. you can see here... https://sa.wikipedia.org/w/index.php?title=%E0%A4%95%E0%A4%B0%E0%A5%8D%E0%A4%AE%E0%A4%A3%E0%A5%8D%E0%A4%AF%E0%A5%87%E0%A4%B5%E0%A4%BE%E0%A4%A7%E0%A4%BF%E0%A4%95%E0%A4%BE%E0%A4%B0%E0%A4%B8%E0%A5%8D%E0%A4%A4%E0%A5%87...&action=edit&section=4

But In this week some other process is called "Converting Wikitext". In that process my table is not being as wikitable and it pasted like this...

अन्वयः विवरणम् यदा अव्ययम् ते युष्मद्-ज. सर्वे.ष.एक. श्रुतिविप्रतिपन्ना आ.स्त्री.प्र.एक. बुद्धिः इ.स्त्री.प्र.एक. समाधौ इ.पुं.स.एक. निश्चला आ.स्त्री.प्र.एक. अचला आ.स्त्री.प्र.एक. स्थास्यति √ष्ठा गतिनिवृत्तौ-पर.कर्तरि, लृट्.प्रपु.एक. तदा अव्ययम् योगम् अ.पुं.द्वि.एक. अवाप्स्यसि अव+‍√आप्लृ व्याप्तौ-पर.कर्तरि, लृट्,प्रपु,एक.

केशव अ.पुं.स्मबो.एक. समाधिस्थस्य अ.पुं.ष.एक. स्थितप्रज्ञस्य अ.पुं.ष.एक. का किम्-म.सर्व.स्त्री.प्र.एक. भाषा आ.स्त्री.प्र.एक. स्थितधीः ई.पुं.प्र.एक. किम् किम्-म.सर्व.नपुं.प्र.एक. प्रभाषेत प्र+√भाष् व्यक्तायां वाचि-आत्म.वि.लिङ्.प्रपु.एक. किम् किम्-म.सर्व.नपुं.प्र.एक. आसीत √आस् उपवेशने-आत्म.वि.लिङ्.प्रपु.एक. किम् किम्-म.सर्व.नपुं.प्र.एक. व्रजेत √व्रज् गतौ-आत्म.वि.लिङ्.प्रपु.एक.

And this is the big problem. Any one can understand that before I was doing only copy and past. Now I will have to make a wikitable every time. So I have put this wish into https://phabricator.wikimedia.org/T117859 here. But this bug has "Low" Priority. I have seen history of phabricator and bugzilla. There are numbers of bugs which have "Low" priority and they filed before 4 year and 5 year ago. I thing this problem will harm sa.wikipedia and slow sa.wikipedia's speed. Moreover "for one user(?)" this portion signs that it bug will never solved. I personally have 700+ tables to paste in sa.wikipedia. So my wish to solve this bug as soon as possible. We are small community and this is the biggest problem fort of us. This is not for only one user but all sa.wikipedia. We wish to solve it.NehalDaveND (talk) 07:08, 11 November 2015 (UTC)[reply]

Earlier discussion and endorsements


  1. Support Support. Szalakóta (talk) 16:57, 1 December 2015 (UTC)[reply]
  2. Support Support as this sounds like a serious regression that is hampering wiki development. Stevie is the man! TalkWork 18:43, 1 December 2015 (UTC)[reply]
  3. Support Support Jan.Kamenicek (talk) 19:19, 1 December 2015 (UTC)[reply]
  4. Support Support Gap9551 (talk) 20:47, 1 December 2015 (UTC)[reply]

This bug has already been fixed in master. It is marked as resolved on Phabricator. ESanders (WMF) (talk) 22:16, 1 December 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


Cookies for autoblocker[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate of #Improve MediaWiki's blocking tools. MER-C (talk) 11:51, 11 November 2015 (UTC)[reply]

Tracked in Phabricator:
Task T5233

This extends the autoblocker such that a cookie is placed when a user is blocked, and triggers the autoblocker when such a cookie is detected. This impedes shifting IPs (sometimes unintentionally) to evade blocks. MER-C (talk) 01:50, 8 June 2015 (UTC)[reply]

Isn't that way too easy to exploit? The Quixotic Potato (talk) 15:56, 16 July 2015 (UTC)[reply]
It's better than what we have now, which only triggers the autoblocker when the same IP address is used. MER-C (talk) 01:46, 20 July 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Cross-Wiki Watchlists[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate of #Cross-wiki_watchlist. MER-C (talk) 18:30, 12 November 2015 (UTC)[reply]

Tracked in Phabricator:
Task T5525

Notes and bug-links collated at mw:Watchlist wishlist.

Now that SUL finalization is complete, there is no longer an obvious obstacle to developing a proper cross-wiki watchlist. This is a very old request (phab:T5525 from September 2005) and has been cited as one of the reasons why users on, say, Wikipedia are reluctant to branch out and participate on Meta, Commons, etc. There has been an effort to develop this as an external OAuth tool (phab:T92955), but it really should be developed within MediaWiki itself, dovetailing in with the existing Special:Watchlist page in some manner. This, that and the other (talk) 10:05, 17 July 2015 (UTC)[reply]

Note: the bug had 32 votes. --Nemo 11:00, 17 July 2015 (UTC)[reply]
Note: Upcoming phab:T92955 is released as Crosswatch. --Menner (talk) 06:39, 19 August 2015 (UTC)[reply]
Endorsed Endorsed. See also https://github.com/he7d3r/mw-gadget-CrossWikiWatchlist. Helder 12:01, 12 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Generate automatic summary /* blah */ when I manually add a new section heading when editing[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate, merged with the one in the Editing category. DannyH (WMF) (talk) 23:25, 14 December 2015 (UTC)[reply]

See Community Wishlist Survey 2015/Editing#Generate automatic summary /* blah */ when I manually add a section heading when editing. Particularly helpful on talk pages. Wbm1058 (talk) 15:04, 16 November 2015 (UTC)[reply]

Earlier discussion and endorsements
Endorsed Endorsed Davidwr/talk 22:46, 25 November 2015 (UTC)[reply]


  1. Support Support Jenks24 (talk) 10:50, 30 November 2015 (UTC)[reply]
  2. Support Support Grüße vom Sänger ♫(Reden) 22:21, 1 December 2015 (UTC)[reply]
  3. Support Support in clear cases where the new section is the beginning of what's inserted. Stevie is the man! TalkWork 13:18, 2 December 2015 (UTC)[reply]
  4. Neutral Neutral. It could be useful in some cases but not sure it does not have negative consequences in some other cases. Beagel (talk) 14:56, 12 December 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Global, shared gadget list users can pick from[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate of #Central Global Repository for Templates, Lua modules, and Gadgets. MER-C (talk) 11:44, 11 November 2015 (UTC)[reply]

Yes, I know if you put your gadgets on meta it gets to all wikis, but this is not user friendly and has a lot of RTL issues all over the place. Matanya (talk) 22:46, 19 May 2015 (UTC)[reply]

Endorsed Endorsed And they need to be live searchable, so there is no reason to restrict on publishing gadgets, because "the preferences section already has 60 of them". —TheDJ (talkcontribs) 06:55, 20 May 2015 (UTC)[reply]
We need a whole package of add ons (such as template and gadgets) that Wiki's can opt into and which are supported by the WMF. I love WikEd for example but it is not an option on many Wikis and thus if I want to use it I need to copy the content to En Wiki first. Doc James (talk · contribs · email) 04:08, 22 May 2015 (UTC)[reply]
Endorsed Endorsed+1 for global, centralized and configurable gadgets! Helder 16:32, 25 May 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Global templates[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate of #Central Global Repository for Templates, Lua modules, and Gadgets. MER-C (talk) 13:25, 14 November 2015 (UTC)[reply]

A lot of effort goes to duplication of templates all along different wikis. It would be ideal if certain / many of them would be available under a Global Template wiki, with multilingual support by Wikidata. --FocalPoint (talk) 21:51, 13 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Improve SVG rendering (2)[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate of #Improve SVG rendering. MER-C (talk) 11:49, 11 November 2015 (UTC)[reply]

Placeholder. Details see here. --2A02:810D:1740:1554:1464:B61E:AF7D:42D 19:29, 26 May 2015 (UTC)[reply]

How often is SVG rendering a problem? Appears there is a work around here [4] Doc James (talk · contribs · email) 11:16, 27 May 2015 (UTC)[reply]
This is me working on librsvg. I've fixed five long term bugs in five days. SVG is everytime a problem when I draw a scientific graphic. Detailed analysis isn't done yet. Currently I'm trying to get some important fixes into latest gnome release before next freeze. Anything else would mean years of waiting. -- Menner aka 2A02:810D:1740:1554:D50D:D2D:256C:10D4 17:49, 27 May 2015 (UTC)[reply]
See also Re-evaluate librsvg as SVG renderer on Wikimedia wikis.--Qgil-WMF (talk) 08:32, 2 June 2015 (UTC)[reply]
Endorsed Endorsed +1 It is absolutely annoying, time and resource wasting for everyone is willing to share SVG. Take simply a look on Commons, many SVG have an flooded crappy file-history (and then sometimes unused and dead or replaced by pixel-graphics). ↔ User: Perhelion 13:24, 3 July 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Improve talk pages editing[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
As stated in the Survey description, "A proposal that duplicates or conflicts with items on another WMF team's roadmap may be flagged by the Community Tech team, and not included in the voting phase." The Collaboration team is responsible for Flow, and Community Tech isn't going to override their plans. Proposals for disabling Flow will not be included in the voting phase. Concerns about Flow and the Collaboration team's roadmap should go to the Collaboration team; this page is not an appropriate place for discussing them. DannyH (WMF) (talk) 19:30, 15 November 2015 (UTC)[reply]

I'm not sure how to migrate existing talk page to something like mw:Extension:Flow, but it would be helpful. Current page-like-editing is not user-friendly for newbies :( --AS (talk) 16:51, 27 May 2015 (UTC)[reply]

There is already a team of developers working on Flow from what I understand. There is an early version that one can test at the link you give. Doc James (talk · contribs · email) 00:56, 28 May 2015 (UTC)[reply]
thanks, now I've noticed roadmap on mw:Flow --AS (talk) 11:05, 28 May 2015 (UTC)[reply]
Oppose Oppose Flow is a failed experiment. What we need is tools to convert Flow and LiquidThread pages back to talkpages. The Quixotic Potato (talk) 10:57, 15 November 2015 (UTC)[reply]
  • Some years ago, the community identified four desirable improvements to talk page editing, all of which can be done in MediaWiki using Wikitext (and hypothetically could be extended also to VE editing). They are:
    • automatic signatures on talk page entries (easily done, we have bots that do it now - Flow automatically appends the username, not the user signature)
Tracked in Phabricator:
Task T21110
    • a button on the editing toolbar to automatically and correctly indent a post in a discussion and automatic outdenting after a certain number of indents (both also fairly easily done - on last looking at Flow, the indentation scheme made most threads almost unreadable)
    • more graceful edit conflict management (significant work on this has already been done - this is the only thing Flow is better at, but that is because it literally creates a new page for each entry)

Tracked in Phabricator:
Task T72163

    • ability to watchlist an individual thread or discussion (this is a challenge for wikitext, but Flow's current solution seems to be that you have to watchlist individual threads on a 'page' in order to see changes to that thread, which essentially deprecates watching entire 'pages')

Tracked in Phabricator:
Task T2738

  • It escapes me why we have gone on to create a *third* user interface that new users would need to learn in order to be full participants in their editing communities. (In fairness, VE is optional on most projects.) Even if Flow was fully implemented on all talk pages, users would still need to use wikitext for a large number of workflows such as deletion discussions (where Flow would actually impede the work with its method of data storage), many discussion boards, requests for comment, requests for adminship, and dozens of other places. Adding another user interface adds complexity, it does not make things easier for new users. What it does is marginalize them, because it makes it that much harder to learn how to participate in almost all of the areas where input from community members is important. If it weren't for the fact that VE prevents people from adding signatures (and blocks a few other key wikitext functions), I'd say just go with permitting VE on talk pages. In fact, I think it would be fiscally more efficient to figure out how to add these features to VE dependent on namespace, rather than invest further in Flow. Risker (talk) 22:26, 23 July 2015 (UTC)[reply]
  • I think this is one of the points where exposure of the WMF software development roadmap to the community would be useful. Currently the Flow Portal shows the roadmap ending at 2014-15 Q4, ie at the end of last month. (I may say that the paragraph there beginning The roadmap items that appear below are guesses does not exactly fill me with confidence.) Questions have been asked of the ED as to her plans for Flow, but that discussion remains unresolved. It is hard for the community to make sensible proposals for improvements or new features if it is not told what the software base is expected to be, nor what the design criteria are, nor when, if ever, it is to be delivered. Rogol Domedonfors (talk) 10:16, 24 July 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Linksearch per namespace[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate of #Improve Special:LinkSearch. MER-C (talk) 21:25, 13 November 2015 (UTC)[reply]

The MediaWiki software does offer the ability to search for links only in a specific namespace, but this functionality is disabled on WikiMedia projects, due to efficiency issues. The Quixotic Potato (talk) 01:39, 11 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Show additions or removals of items from categories on watchlists[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate of #Add_a_Category_watchlist. Jheald (talk) 13:10, 13 November 2015 (UTC)[reply]

It would be good if there was an option to have additions to watchlisted categories, or removals from it, appear as watchlist notifications for a watched category. Jheald (talk) 12:38, 13 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Watch single sections of a Talk Page[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Duplicate of #Section watchlists. MER-C (talk) 12:27, 12 November 2015 (UTC)[reply]

Sometimes, I just want to watch a single section of a Talk Page and not all of it. Thanks, --Gnom (talk) 10:13, 12 November 2015 (UTC)[reply]

It's now available using mw:Flow and can be activated on talk pages (or user talk page) per user or community request, for example mw:Talk:Flow. Kenrick95 (talk) 11:23, 12 November 2015 (UTC)[reply]
Unfortunately, it is not clear whether all communities will get Flow in near future. And even if so, it will certainly not replace all talk pages. WMF has realized that Flow is a good piece of software, but also far away from being a solution for all talk pages. We will therefore have to continue to deal with regular wikitext talk pages for quite some while. This proposal needs endorsement. —MisterSynergy (talk) 11:44, 12 November 2015 (UTC)[reply]
Endorsed EndorsedMisterSynergy (talk) 11:44, 12 November 2015 (UTC)[reply]
Endorsed Endorsed I hope those who still support Flow won't prevent us from getting improvements in talkpages without the burden of Flow. WereSpielChequers (talk) 11:47, 12 November 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Withdrawn by proposer[edit]

Increase edit summary and log reason length[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Withdrawn -- this is currently a database operations task. MER-C (talk) 12:01, 11 November 2015 (UTC)[reply]

Tracked in Phabricator:
Task T6714
Tracked in Phabricator:
Task T6715

Edit summaries are currently limited to 255 bytes. This is a pain for non-English editors, where one UTF-8 character consumes at least two bytes. MER-C (talk) 06:29, 3 July 2015 (UTC)[reply]

For what is worth: phab:T102611.--Qgil-WMF (talk) 11:17, 3 July 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Tell prospective users what Wikipedia is not for[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Withdrawn by request of JohnCD. Ryan Kaldari (WMF) (talk) 16:57, 8 December 2015 (UTC)[reply]

The problem: prospective users get no explanation before they sign up of what Wikipedia is for, and more importantly what it is not for. They know "anyone can edit", and suppose that means "anyone can post whatever they like". Therefore very many new articles are posted which have no hope of becoming encyclopedic: non-notable Facebook-style autobiographies, CVs, company advertisements, copies of promotional websites, puff pieces about garage bands...

Who would benefit:

  • Prospective Wikipedia users who are really looking for a social-networking site or an advertising platform would be spared wasted effort and disappointment.
  • New page patrollers and administrators would be saved unproductive, tedious and repetitive work deleting unsuitable pages and explaining, over and over again, why Wikipedia is not for what the disappointed newbies wanted to do.
  • If the flood of no-hope new articles were reduced, more time and attention could be given to those newbies who really want to contribute but need guidance.
  • With fewer disappointed newbies out there, Wikipedia might lose some of its reputation for being unfriendly.

Proposed solution: the sign-up page you get on clicking "Create account" should say something like:

"Wikipedia is a project to build an encyclopedia. It is not a social-networking site, or a free platform for promotion. If you want to help build the encyclopedia, you will be very welcome; but if what you want to do is tell the world about yourself, your friends, your company, your client, your band, your good cause or your new original theory, this is not the site for you to do that."

For those who want more explanation, a link could be provided to a page giving brief summaries of the policies on autobiography, notability, advertising and conflict of interest. My experience of this problem is on en:wp, but I expect others have it, too: each project should be able to decide what message, if any, to display on the sign-on screen.JohnCD (talk) 09:27, 21 November 2015 (UTC)[reply]

Earlier discussion and endorsements

Endorsed Endorsed --Uncle Milty (talk) 16:20, 21 November 2015 (UTC)[reply]

Endorsed Endorsed Agree totally with the importance of at least attempting to tell people what they are signing up for. Rather than say "build an encyclopedia" twice, I would try to explain briefly what we mean by this - even at the expense of making the message longer. After getting the "not" part out of the way, we could say: "You are very welcome to sign up if you are interested in improving existing Wikipedia articles, or adding new articles about widely significant topics. We try to make sure that all information is reliable and well-written. You can find out more here [link to WP:Contributing to Wikipedia]" Noyster (talk) 18:08, 21 November 2015 (UTC)[reply]

Note that it's already possible for local admins to add/edit content on the sign-up page, e.g. https://en.wikipedia.org/wiki/MediaWiki:Signupstart. Not sure what tech work would be required here. the wub "?!" 00:22, 25 November 2015 (UTC)[reply]

@The wub:Unfortunately the link you give is to an announcement that the page was deleted by User:Amire80 on 30 Sept 2015 for reason "identical to source". Could either of you help in identifying the "source" that this page was identical to? Thank youNoyster (talk) 17:16, 28 November 2015 (UTC)[reply]
@Noyster: It looks like it's been blank since the page was redesigned. However the message would go above the create account form, you can see this at [5]. the wub "?!" 10:29, 30 November 2015 (UTC)[reply]


  1. Support Support Lugnuts (talk) 12:05, 30 November 2015 (UTC)[reply]
  2. Full Support SupportTitoDutta 14:46, 1 December 2015 (UTC)[reply]
  3. Support Support Seems like a good idea, so long as the message is diplomatic and unambiguous. I think it might be better to provide links to Wikipedia content guidelines rather than a direct message to new users. Sort of, trying to show prospective users what's expected of them, rather than discourage people from joining altogether. -- 2ReinreB2 (talk) 17:29, 1 December 2015 (UTC)[reply]
    Support Support the need to do something, but Oppose Oppose the proposed solution as it comes off snotty and condescending. In its place, I would propose stating what's expected of editors in a professional tone, with appropriate links to details. E.g., "Wikipedia editors from the very new (like you!) to the most experienced are engaged in the serious editing of a comprehensive, high-quality encyclopedia (link 'encyclopedia', as many may not even know what an encyclopedia is and what it should be.). Newly created articles are expected to be about notable subjects. Edits to existing ones are expected to be..." Stevie is the man! TalkWork 18:29, 1 December 2015 (UTC)[reply]
  4. Neutral Neutral per MisterSanderson below. This isn't meant to detract from my previous statement about how it could work. Stevie is the man! TalkWork 18:05, 4 December 2015 (UTC)[reply]
  5. Support Support-- Akela (talk) 21:04, 1 December 2015 (UTC)[reply]
  6. Oppose Oppose, this is just useless. Editors who came here to promote something will do it anyway, but good faith editors may think we consider them vandals and leave the project before their first edit — NickK (talk) 14:54, 2 December 2015 (UTC)[reply]
  7. Support Support --Misibacsi (talk) 04:46, 3 December 2015 (UTC)[reply]
  8. Support Support As a one-time popup, it can be written in a nice, encouraging way that doesn't put people off. This won't end the problem, not even close, but if it cuts it by 20% or even 10%, that's not a bad return. Even 5%. It has to be friendly and very readable, not like those stupid EULA's that nobody reads and we all just click OK. Like, have the window say what WP is and is not, and then have new users click on "I want to help make a great encyclopedia" or "I want to meet people who share my interests", or something broader. Just so it doesn't look like an automatic step. Dcs002 (talk) 12:25, 3 December 2015 (UTC)[reply]
  9. Neutral Neutral. I like the idea, but it's not necessary to bring this to the Foundation's Technical Team, it can be solved locally by tech voluntaries. So I don't want to waste 1 of the 10 projects the Technical Team will implement.--MisterSanderson (talk) 15:53, 3 December 2015 (UTC)[reply]
  10. Support Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  11. Oppose Oppose We don't need to talk about our own history as yet another hurdle to take for someone interested in contributing. Let them come contribute with as few barriers as possible. --Jane023 (talk) 16:32, 4 December 2015 (UTC)[reply]
  12. Oppose Oppose totally pointless, every test in the past and has shown that it only confuses good faith people, makes them scared and doesn't actually teach them anything, while bad faith people just ignore it and do there thing anyways. —TheDJ (talkcontribs) 22:53, 5 December 2015 (UTC)[reply]
  13. Support Support hundreds of new pages each day from people who are not "bad faith", they simply have no idea what distinguishes WP from any other website. Like others, though, I would prefer a more positive wording (see my suggestion under "Earlier discussion"). Noyster (talk) 13:40, 7 December 2015 (UTC)[reply]
  14. Oppose Oppose per NickK and TheDJ. --Waldir (talk) 14:58, 8 December 2015 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.