Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.

Renaming Category:WikiProject Infoboxes

I just want to alert people that there is currently a proposal at CFD for renaming Category:WikiProject Infoboxes to Category:Wikipedia infoboxes [1]. Personally, I have opposed this, as this is obviously a maintenance category. I don't understand the rationale behind the proposal. ---Steve Quinn (talk) 18:04, 15 January 2017‎ (UTC)

RfC: Linking to details regarding the offline Medical Wikipedia app

The offline app allows you to download all of Wikipedia's medical articles in an app to access them when you have no Internet.
Wikipedia's health care articles can be viewed offline with the Medical Wikipedia app.

Should we allow a {{sister project}} style sidebar, i.e. Template:Offline in the form of {{offline|med}}, to be placed within the external links section of medical articles for the purpose of promoting Wikipedia:WikiProject Medicine/App? — Godsy (TALKCONT) 17:36, 29 March 2017 (UTC)

Support

  • Support Prior discussion here. Part of our efforts include "giving free access to the sum of all human knowledge" to all people. This should not be restricted to just when people have a functional Internet connection (something those in the developed world take for granted). Part of our work is to improve access to knowledge in the language of people's choice and in formats that they can use. For many of those in the developing world Internet access is only avaliable for a couple of hours a day or only when they visit larger urban centers. Offline content address these limitation. We know our online content struggles to reach those in the developing world. Our offline medical apps however have been downloaded by more than 150,000 people of which about 80% are from the developing world. Doc James (talk · contribs · email) 17:50, 29 March 2017 (UTC)
  • Support I wasn't a great fan of a huge banner for this, but I can't see any problems with this template, and Doc James makes a compelling case for the apps usefulness. Sam Walton (talk) 17:57, 29 March 2017 (UTC)
  • support per reason [2]--Ozzie10aaaa (talk) 17:58, 29 March 2017 (UTC)
  • Support: The Offline Medical Wikipedia app is an application that allows Wikipedia's medical content to be downloaded in a choice of languages in compressed ZIM format (as well as a free, open-source offline browser, Kiwix, that will natively display the compressed data, if required). Its principal purpose is to allow mobile phone users in parts of the world where internet access is restricted, intermittent, or unreliable to have constant access to our medical content. As an additional means of distribution of our content, I'd personally prefer it to be a sidebar link (like "Download as PDF" is), but I'll certainly support a link somewhere in the footers of medical articles to the WikiProject Medicine page where it is documented. --RexxS (talk) 18:24, 29 March 2017 (UTC)
  • Support. There are more than a million billion of people in developing countries that only have access to the Internet for a limited time. This banner is useful for million billion of readers who can use it when they are not online. The banner is the sum of all human knowledge at your fingertips for people who don't have unlimited Internet access or who want to use it while offline. Is there a better solution? QuackGuru (talk) 19:03, 29 March 2017 (UTC)
User:QuackGuru I think you mean more than a BILLION :-) Doc James (talk · contribs · email) 19:06, 29 March 2017 (UTC)
Yep. QuackGuru (talk) 19:17, 29 March 2017 (UTC)
  • Support - I had thought this debate had already been resolved satisfactorily in the deletion discussion. Yes, the sidebar is non-intrusive and helping users access our articles is an important part of our mission. Sizeofint (talk) 19:35, 29 March 2017 (UTC)
  • Support The debate had already been resolved to almost everyone's satisfaction, and this RFC appears to be unnecessarily pointy. • • • Peter (Southwood) (talk): 19:57, 29 March 2017 (UTC)
  • Support I also support this. I think anyone working in a developing countries context knows how important it is to have Wikipedia content available offline. I wonder if the people opposing this have ever lived in an area with poor internect access and poor public health, few doctors available, no access to healthcare etc.? For people like that having the offline version of medical content (in several languages) is wonderful. Due to the fact that not many people are aware of this app yet, I strongly support having the template (or any other form of awareness raising for this app) in an appropriate place of many related Wikipedia articles. Having it at the bottom right seemed like a perfect solution to me! EMsmile (talk) 20:01, 29 March 2017 (UTC)
  • support is a related WMF project, and will be limited to medical articles. Jytdog (talk) 00:18, 30 March 2017 (UTC)
  • Support - would also support the "inline" type being discussed below. Note, this support is contingent on the format that has already been debated multiple times - primarily that it links to an editor-controlled page. — xaosflux Talk 00:22, 30 March 2017 (UTC)
  • Support - the proposal is similar to other boxes that we have, so should be understandable to people who consult Wikipedia for a variety of topics. I would particularly note that the template should also display on mobile devices (I was disappointed to find that {{Library resources box}} does not). --122.108.141.214 (talk) 00:55, 30 March 2017 (UTC)
This template should also be included in {{Sister project links}} if this goes ahead. --122.108.141.214 (talk) 01:05, 30 March 2017 (UTC)
  • Support. This really is a very worthwhile initiative for the purpose of helping more people become readers of Wikipedia – which after all should be what we all want. In previous versions, there have been problems with potential advertising or with overly-large banners, but those problems have now been solved. And putting it in EL is the right way to do it. I think this RfC helps tie up loose ends from previous discussions, by spelling out where and how the box will be used. I also would support the inline idea described below. --Tryptofish (talk) 01:10, 30 March 2017 (UTC)
  • Support. Seems like a worthwhile cause that could be very helpful in regions of the world with poor internet infrastructure. ---- Patar knight - chat/contributions 02:29, 30 March 2017 (UTC)
  • Support Wikipedia's health care articles are generally high quality and it is helpful to inform readers about the app which displays that content. Johnuniq (talk) 10:45, 30 March 2017 (UTC)
  • Support, it's a good way to give the app visibility. Icebob99 (talk) 15:39, 30 March 2017 (UTC)
  • Support per Doc James. Gestrid (talk) 04:53, 31 March 2017 (UTC)
  • Support for the same reasons as at the XfD I commented at. jcc (tea and biscuits) 12:31, 2 April 2017 (UTC)
  • Support — There really are no reasons to oppose beyond simply being obstructionist and wanting to hinder any improvement to the encyclopedia. It always ends up being the same people starting these pointless RfCs or who take it upon themselves to be the sole arbiters of guidelines and interpreters of policy. Carl Fredrik talk 00:37, 4 April 2017 (UTC)
  • Support - Addresses offline content issues for those in the developing world with limited internet access. SW3 5DL (talk) 04:44, 7 April 2017 (UTC)
  • Support seems pretty obvious per above arguments, Sadads (talk) 22:45, 11 April 2017 (UTC)
  • Support, conditional on the template a) being restricted to the "see also" or "external links" sections as proposed, and b) linking to a Wikimedia-site page about the app rather than directly to one or more app stores. It's a great idea as long as its implementation follows the same principles as our other article meta-content. {{Nihiltres |talk |edits}} 15:05, 12 April 2017 (UTC)
    • @Nihiltres: One other possibility that I've previously suggested is hosting the page about the app on Meta, probably at a subpage of m:WikiProject Med Foundation (because the app is available in many other languages besides English). As you mention linking to "a Wikimedia-site page about the app", am I right in thinking that you'd still be in favour if the landing page were moved to the Meta-Wiki instead? --RexxS (talk) 18:14, 12 April 2017 (UTC)
      • @RexxS: Yes, definitely. {{Nihiltres |talk |edits}} 18:22, 12 April 2017 (UTC)
        • Will get to the move to meta shortly. Agree with the other comments by User:Nihiltres aswell.Doc James (talk · contribs · email) 05:34, 13 April 2017 (UTC)
          • There are downsides of a move to meta; namely, keeping it local means it remains in our jurisdiction (i.e. it is governed by our local policies and guidelines). I'm curious what Xaosflux thinks, due to "support is contingent on the format that has already been debated multiple times - primarily that it links to an editor-controlled page", does it matter which contingent of editors control the page? — Godsy (TALKCONT) 15:22, 13 April 2017 (UTC)
            • @Godsy: It doesn't matter to me if it is a w:en: link or a meta: or a link; main point being that it leads somewhere under volunteer editorial control (as opposed to the original link to an external commercial website). — xaosflux Talk 18:00, 13 April 2017 (UTC)

Oppose

  • Oppose. Use formatting similiar to {{dmoz}} instead. KATMAKROFAN (talk) 20:28, 29 March 2017 (UTC)
    • Possibly an unfortunate analogy as DMOZ has just closed down. Nevertheless it's an interesting suggestion, so could you give an example of how this might look on an article like Pneumonia, please? --RexxS (talk) 21:05, 29 March 2017 (UTC)
Classification
External resources


KATMAKROFAN (talk) 21:35, 29 March 2017 (UTC)
Thank you. So essentially, you'd prefer the content of the template as plain text among the external links, rather than in a box floated to the right of the page with the sister projects? That seems a possible alternative. --RexxS (talk) 22:05, 29 March 2017 (UTC)
We also have Template:Commons-inline. The two are not exclusive of each other. Doc James (talk · contribs · email) 22:09, 29 March 2017 (UTC)
(edit conflict)Seems a strange way to do it. The links placed there are almost always links external to the Wikimedia projects, whereas we tend to put links to Wikimedia related places (Commons for example) in a side box like the one being proposed here. Sam Walton (talk) 22:09, 29 March 2017 (UTC)
  • I'm going to oppose.

    I'm sympathetic to the view that "offline reading" should be enabled.

    I do not, however, believe this is the way to do it. A systematic way, which relies not on en.WP's hack of a template, nor one which advertise a particular reader or viewer, is a) much better and b) provides the functionality for all pages, without c) the mess of a template addition to every article (within a certain scope) for d) every reader, mobile or not. To that end, there is a phabricator task for this funcitonality at phab:T113396. My final opinion: Just be patient. It's on the (WMF) radar. Courtesy ping to AGomez (WMF) who looks to have been editing the page at meta:New Readers/Offline. --Izno (talk) 12:58, 30 March 2017 (UTC)

  • Yup more options for reading Wikipedia offline are coming :-) The page this template links to will discuss that option as soon as it is avaliable. The template is not specific to raising awareness about a single app but about raising awareness about offline options generally (options of course need to be free and under an open license). Doc James (talk · contribs · email) 13:16, 30 March 2017 (UTC)
  • Oppose: it is not the job of each individual wiki article to make "meta" announcements of "other things that are available" related to Wikipedia. Articles are already at the borderline of being a mess in this sense, and if every special interest group within Wikipedia proceeded to add such "meta" announcements within individual articles, the result would clearly be untenable. I'm not sure why this particular announcement deserves an exception. Aureliano Babilonia (talk) 01:55, 3 April 2017 (UTC)
    • Because we see it as part of our mission to provide content to those in the developing world in a format that they can use. And also this appears to have consensus. Doc James (talk · contribs · email) 23:05, 9 April 2017 (UTC)
    • I'm sympathetic to your (Aureliano Babilonia's) argument; it is superficially good. The problem is that it relies on skewed priorities. At least in the short term the significant benefit (people with poor Internet access having access to Wikipedia's medical content) arguably outweighs the minor cost (us volunteers having slightly more work and slightly less organization), and in the longer term we can push for better ways to surface this sort of meta-content to users, to reduce or eliminate that cost. {{Nihiltres |talk |edits}} 15:37, 12 April 2017 (UTC)

Neutral

Discussion

Relevant discussions preceding this RfC: Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Sidebar, Wikipedia talk:WikiProject Medicine/App#Sidebar, and Wikipedia talk:WikiProject Medicine/Archive 94#Sidebar. — Godsy (TALKCONT) 17:36, 29 March 2017 (UTC)

it seems s support vote is best for everyone, not clear what(or why) your position is such given prior general opinion[3]--Ozzie10aaaa (talk) 18:10, 29 March 2017 (UTC)
Discussion about titling the RfC
The initial heading was "non neutral". Have adjusted it so that it is.[4]. And here is the link to policy requiring the statement of the RfC to be neutral[Wikipedia:Requests_for_comment#Statement_should_be_neutral_and_brief] Doc James (talk · contribs · email) 18:19, 29 March 2017 (UTC)
@Doc James: Advertising, i.e. "the act or practice of calling public attention to one's product or service", is not inherently non-neutral. However, raising awareness is inherently non-neutral. — Godsy (TALKCONT) 18:32, 29 March 2017 (UTC)
Godsy you appear to dislike the app. Can you explain why? I was under the impression that we address your concerns. Doc James (talk · contribs · email) 18:34, 29 March 2017 (UTC)
@Doc James: Would you find "Publicizing the offline Medical Wikipedia app" or "Promoting the offline Medical Wikipedia app" agreeable for the RfC title? — Godsy (TALKCONT) 18:40, 29 March 2017 (UTC)
We could use "Linking to details regarding the Offline Medical Wikipedia app" Doc James (talk · contribs · email) 18:43, 29 March 2017 (UTC)
 Done. I'll fix the existing links. — Godsy (TALKCONT) 18:46, 29 March 2017 (UTC)
Godsy, although you're a relative newcomer, you must know very well by now that this encyclopedia is strongly opposed to any advertising. It is inconceivable that you do not understand that calling other editors' contributions "advertising" is rude and and offensive to them. To then edit-war your calumny back into this RfC is beyond acceptable behaviour, and I shall be considering seeking administrative assistance to ensure that you do not repeat that behaviour in future. --RexxS (talk) 18:56, 29 March 2017 (UTC)
@RexxS: Changing it to raising awareness was no better. I reverted twice, then came here to discuss; Doc James changed it thrice. If you do choose to seek administrative assistance, it will likely be fruitless, as I've done nothing inappropriate. — Godsy (TALKCONT) 19:07, 29 March 2017 (UTC)
@RexxS: I misspoke, I reverted twice. I was concerned about the link at {{cent}}. Best Regards, — Godsy (TALKCONT) 19:13, 29 March 2017 (UTC)
Changing it to raising awareness was no better - That's simply untrue. "Raising awareness" on Wikipedia carries none of the pejorative implication of "advertising" and it's not the "euphemism" that you claimed in your edit summary, ... if you euphemize inappropriately again, I expect you to check my contributions and fix all the existing links. You don't seem to understand edit-warring either. You called the template "Advertising the Medical Wikipedia app"; Doc James changed it to "Raising Awareness of the Offline Medical Wikipedia app". That's the point where you take it to talk, not after forcing your preferred version back into this page twice more. I understand your concern about having to update links at Cent, but that's a small price to pay for not offending other good-faith editors. Quite honestly, I'd much prefer not to have to waste my time at ANI, but I remain concerned that you're not willing to own up to mistakes like 22 reverts with no reason other than the edits you reverted didn't seek consensus beforehand and calling an RfC with a non-neutral title. --RexxS (talk) 19:33, 29 March 2017 (UTC)
Euphemize wasn't the best description, though it is not necessarily inaccurate; it and the rest of my edit summary was a reaction to behavior that I've come to expect from some wp:med participants. I created it at Title X (creation), Doc James changed it to Title Y (Bold), I revered it back to X (Revert) - that is the point where discussion should have taken place. Doc James shouldn't have changed it a second time (Discuss), especially as the title they changed it to was not any better neutrality-wise. The over 20 reverts you mention: Doc James added {{offline|med}} to a group of articles (Bold), I reverted the additions notifying them that the change was contentious and suggesting a venue for discussion (Revert), Doc James ignored that and restored them all (Discuss). History is important for context: Wikipedia:WikiProject Medicine/App/Banner was added to the top of a few articles, some about a year ago, and at least one with the edit summary "one week trial". I'm not sure if there was any local consensus at that point, but editors removed the banners, and they were restored by members of the WikiProject. Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Medicine/App/Banner began. It was closed as "Keep, but not to be inserted into articles without obtaining consensus to do so." Editors removed the banners from the articles for a second time per that consensus, but again, members of the WikiProject restored them. Wikipedia:Village pump (proposals)/Archive 138#Use of Wikipedia:WikiProject Medicine/App/Banner on articles is opened, and finally 3 months later, the banners were removed after being present at the top of articles all that time (since the MfD) against community consensus. That's all I have to say on the matter here, as not to further detract from the RfC. — Godsy (TALKCONT) 04:26, 30 March 2017 (UTC)

I think it would be worth showing the actual template in question, to allow those unfamiliar with the previous debates to get an idea of what we are discussing. --RexxS (talk) 18:29, 29 March 2017 (UTC)

Thanks User:RexxS have moved to the top of the RfC. Doc James (talk · contribs · email) 18:38, 29 March 2017 (UTC)

If it is advertising, then it is advertising for something benign. The real offender is the link to the "Wikipedia Shop" selling T-shirts which appears on every page. Matthew Ferguson (talk) 18:51, 29 March 2017 (UTC)

The app is developed by volunteers at WPMED and Wikimedia CH. It is free and without advertising. The development cost (paying for programmers) is covered by movement funds. We are not "selling" anything so the user of the term "advertising" IMO is inaccurate. Doc James (talk · contribs · email) 19:15, 29 March 2017 (UTC)
agree--Ozzie10aaaa (talk) 19:40, 29 March 2017 (UTC)
Promotion/advertising/raising awareness/etc. It's semantics. I feel the reason this is an issue with some is that it represents placing a link on encyclopedia pages to a program which is not directly related to any given encyclopedia topic. Matthew Ferguson (talk) 20:40, 29 March 2017 (UTC)
It's more placing a link to the data - i.e. the compressed Wikipedia content. Surely the program (offline browser) is incidental. Wouldn't the reason you suggest be as logical as having an issue with the [Download as PDF] link, which is on every article page, because Adobe Acrobat "is not directly related to any given encyclopedia topic"? --RexxS (talk) 20:48, 29 March 2017 (UTC)
Invalid analogy really. 1. PDFs can be read with many programs, 2. downloading the article as PDF does not require you to download any program in particular, 3. the link gives you a PDF of the article you were on, I assume the link to the medical app will not directly link you to the article you were originally on. Matthew Ferguson (talk) 21:10, 29 March 2017 (UTC)
Not really. 1. ZIMs can be read by many programs; 2. downloading the data does not require you to download any program in particular – especially as ZIM is an open and standardized file format, unlike PDF; 3. the link gives you all of Wikipedia's medical content, including the article you are on, which allows you to go to all of the other medical articles that the article has wikilinks to (unlike a PDF). --RexxS (talk) 22:16, 29 March 2017 (UTC)
Yup exactly. The main WP app should be reading ZIMs soon aswell.Doc James (talk · contribs · email) 22:48, 29 March 2017 (UTC)
Clicking the "download as PDF" gives me a PDF of the article I was on. Clicking this link takes me to a description page about an app which I would have to download, which I would then have to navigate to find the article again. This is what is meant by not directly related to any given encyclopedia topic. Matthew Ferguson (talk) 19:54, 30 March 2017 (UTC)

I think it's about time to arrange for this RfC to be closed. I suggest to the closing admin that the overwhelming strength of argument lies with the support !votes, and that there is a strong, if not unanimous, consensus in support of the proposal. I wonder if I can ask the closer to make a judgement on whether this RfC is sufficient to allow the linked page to be moved to Meta-Wiki at some point in the future (as the app is used by multiple Wikipedias with different languages), or whether they feel a new RfC would be required if that course is to be taken? --RexxS (talk) 12:50, 27 April 2017 (UTC)

Abolish sidebar navigation templates

We now have hundreds of sidebar navigation templates that are identical (or nearly identical) to corresponding footer navigation templates. For example {{Conservatism US}} and {{Conservatism US footer}}. It is common practice to include both in any articles related to the subject. See, for example, Paleoconservatism. I don't see any point in including the same content twice in the same article. However, it is virtually impossible to keep people from adding these templates to the articles, even when one of the two templates is already present. The only practical solution, IMO, is to abolish the practice of having sidebar navigation templates. I'm not sure what purpose these templates were designed to address that isn't already handled by footer navigation templates. For anyone opposing this proposal, please explain why we need both. Kaldari (talk) 02:01, 6 April 2017 (UTC)

  • They're helpful in several ways. They're more likely to be seen than the templates at the bottom of articles. They often include images, so they contribute to the article not being a wall of text. And they help to shorten the long lines of text we have because we have no fixed width. If they're being added a lot, it means people like them. SarahSV (talk) 05:57, 6 April 2017 (UTC)
  • I'm very conflicted about these sidebar navigations. There indeed is a lot of duplication here, but there has always been a space for both of these. I think the problem is that if a series box becomes a 'let's link to everything' navbox with multiple levels of 'by default' collapsing (which ppl really need to start learning means 'only-collapsed-on-desktop'), then it's no longer working as it was intended. —TheDJ (talkcontribs) 10:43, 7 April 2017 (UTC)
  • The sidebar navigation should only have a few simple links without options to expand more links. Save that for the footer. Graeme Bartlett (talk) 01:53, 10 April 2017 (UTC)
  • I oppose any abolishment of these things. Or any rule that prohibits their use. Definitely WP:CREEP if you ask me and some of these work fine. I use the {{forensic science}} sidebar on almost every single article I care about. There is no bottom navbar for that topic. And I also agree with SarahSV. They break up the walls of text that are in the top of articles that don't have infoboxes. --Majora (talk) 02:00, 10 April 2017 (UTC)
  • Whether we need both or not, I see no harm in having them and therefore oppose a blanket abolishment of them. I would suggest that attempting to craft a more nuanced policy on nav templates may be more helpful than just trying to delete an entire category of them. Beeblebrox (talk) 02:58, 10 April 2017 (UTC)
  • We should stick with navbars and scale back on sidebars IMO. Doc James (talk · contribs · email) 09:25, 10 April 2017 (UTC)
  • Would there be any benefit in combining the templates for navboxes and navbars so that there is only one for any given subject, but it can be selected to display as either. This would allow user choice of output format, or could be linked to skin, etc. • • • Peter (Southwood) (talk): 09:35, 10 April 2017 (UTC)
    • Some more clarity around which should be used when would be useful. Doc James (talk · contribs · email) 10:32, 10 April 2017 (UTC)
  • The more links a sidebar navigation template has, the less valuable it becomes. They should be used for tightly focused topic areas. Praemonitus (talk) 20:17, 13 April 2017 (UTC)
  • Since many complain about sidebars becoming bloated with too many links, we should think about devising and enforcing guidelines on the appropriate level of comprehensiveness of sidebars. – Finnusertop (talkcontribs) 20:25, 13 April 2017 (UTC)
  • Oppose – 1) options are a good thing, 2) enables navigation from the top of articles. North America1000 21:31, 16 April 2017 (UTC)
  • Oppose - side bar templates are more noticeable than footer templates. Although, both are useful because if one scrolls all the way to the bottom, he/she would not need to come up to navigate. Same for those who just read the lead..Yashovardhan (talk) 11:41, 19 April 2017 (UTC)
  • Oppose Sidebar templates are much handier and easier to use. Dlohcierekim 18:00, 20 April 2017 (UTC)

Clicking on images

Another proposal of mine (also for all Wikipedia versions, if possible) would be to make sure that after clicking on an embedded file in an article and entering the Commons page of that file, you get back right to the position of that image in the article when using the back-button of your browser. Up to now, this is not the case at least for the current Firefox, but instead you always end up at the beginning of the article once you have entered Commons. Would this also be worth forwarding to Phabricator in your view?--Hubon (talk) 15:31, 12 April 2017 (UTC)

You'd better ask this question on Wikipedia:Village_pump_(technical). Ruslik_Zero 20:15, 12 April 2017 (UTC)
Do you have "Enable Media Viewer" at Special:Preferences#mw-prefsection-rendering? Media Viewer is known to mess with the normal functioning of the back button. PrimeHunter (talk) 21:52, 12 April 2017 (UTC)
@Ruslik0: Thanks for your advice! @PrimeHunter: Yes, I do, but still: If we take the article Nazi plunder and click twice on image no. 5, we get to this site. Now, if we click "back", we end up at the very beginning of the article instead of the relevant section. And it's the same with all the other Wikipedias! As recommended by Ruslik, I will now refer the issue to Wikipedia:Village_pump_(technical).--Hubon (talk) 22:30, 13 April 2017 (UTC)
If Media Viewer is causing problems for you, then disable it. It's crap quality, buggy code, and I recommend against using it. -FASTILY 22:42, 15 April 2017 (UTC)
@Hubon: Preservation of scroll state is a browser function (I have no trouble with Chrome or Safari). Which browser are you using ? —TheDJ (talkcontribs) 13:06, 17 April 2017 (UTC)
@TheDJ: Thanks for your interest! I use the latest Firefox version. Now, do you think it would be very difficult for Phabricator to modify Media Viewer in a way that would render it compatible with all common broswers regarding preservation of scroll state? Greetings--Hubon (talk) 13:11, 18 April 2017 (UTC)
I can confirm that this is a problem with Firefox. You should report it in phabricator. —TheDJ (talkcontribs) 09:55, 20 April 2017 (UTC)

Note: Unfortunately, nobody answered on Wikipedia:Village_pump_(technical)... :-(--Hubon (talk) 21:04, 19 April 2017 (UTC)

user:TheDJ: Many thanks for your interest! Would you mind reporting the issue on Phabricator? As I've already communicated before, I'm admittedly not at all familiar with this platform... Thus, I'd be very grateful for any help with passing on the the request to the institutions responsible. Best--Hubon (talk) 19:28, 23 April 2017 (UTC)
@Hubon: Reported as T163875. You can subscribe to it using the "Subscribe button" in the right column (After you logged in using your Wikimedia account, by pressing the Mediawiki button on this page) —TheDJ (talkcontribs) 08:35, 26 April 2017 (UTC)
@TheDJ: Thank you so much!!! I just did as you told me. Now let's wait and see what happens. Thanks once again and best regards--Hubon (talk) 13:53, 26 April 2017 (UTC)

Redirect talk pages with only banners

Some pages like WT:NJournals are tagged only with a banner and nothing else. I think it's pretty reasonable to say that people who link to WT:NJournals expect to have people be taken to the same place Wikipedia talk:Notability (academic journals). [This is true in Wikipedia talk space, just like in any other talk spaces, whether mainspace, category space, etc... This can be confusing to editors, because they are told "comment here", and the page doesn't redirect to the discussion they were meant to be taken.

So I propose that we have a bot with the following logic

For an example where this is already done, see WT:NJOURNALS. Headbomb {t · c · p · b} 09:37, 14 April 2017 (UTC)

Discussion

  • Support, as proposer. Headbomb {t · c · p · b} 09:38, 14 April 2017 (UTC)
  • Support to avoid confusion, the page and talk page should both redirect. AD 09:55, 14 April 2017 (UTC)
  • Comment are you referring to articles that were merged, but there were previous discussion on the talk page of the merged article? In that case, the talk page should be preserved and not redirected, any project banners on the talk page should be reclassed as Redirect to indicate to the projects that the articles were merged, but there were previous discussions preserved. —Farix (t | c) 13:33, 15 April 2017 (UTC)
    • No, this would be restricted to pages that only have banners on it, and nothing else. Pages with discussions would be skipped by the bot. Headbomb {t · c · p · b} 22:07, 15 April 2017 (UTC)
      • And what about talk pages where the only "discussions" are bot messages? Should those also be redirected as well? —Farix (t | c) 11:48, 21 April 2017 (UTC)
  • Support. Seems sensible enough. Gestrid (talk) 04:45, 16 April 2017 (UTC)
  • Support. Letting the talk page contain only banners will be confusing, while any other ways of linking to the redirect (like using {{Talk page of a redirect}}) would be roundabout and with no benefit that I can think of. – Uanfala (talk) 13:43, 17 April 2017 (UTC)
  • Support - page and talk page should both redirect.. SW3 5DL (talk) 04:53, 18 April 2017 (UTC)
  • Support per nom. Yashovardhan (talk) 11:49, 19 April 2017 (UTC)
  • OK. You have my axe. Herostratus (talk) 13:37, 20 April 2017 (UTC)
  • Support with emphasis on the first step in the bot logic (nothing but banners, if there's anything else it should not be auto-redirected). Respectfully, InsaneHacker (💬) 19:48, 21 April 2017 (UTC)
  • Support. I didn't know redirecting with the banner was possible, or I'd have been doing it this way all along. Good idea. Ks0stm (TCGE) 19:54, 21 April 2017 (UTC)
I discovered this fairly recently myself, otherwise I'd have proposed this years ago! Headbomb {t · c · p · b} 11:35, 22 April 2017 (UTC)
Support if all revisions of the talk page are nothing but banners. עוד מישהו Od Mishehu 21:16, 22 April 2017 (UTC)
  • Support I agree with others. But what if A redirects to B and Talk:A exists (is a blue link) but Talk:B doesn't (is a red link)? Should the bot create Talk:B with banners copied from Talk:A, have admin rights and delete Talk:A per WP:CSD#G8, or do a page move from Talk:A to Talk:B? Also, other bots such as AnomieBOT would be affected, for example, when an article title previously deleted at AfD was recreated as a redirect to another article. GeoffreyT2000 (talk) 00:44, 25 April 2017 (UTC)
    You raise excellent questions. My initial guess is that in this case Talk:B should be created with the banner copied from Talk:A and then Talk:A should have a REDIRECT prepended to point it to Talk:B. In general I'd be hesitant to delete Talk:A if it obscures any history. Doing a page move I think is a bad idea because the history of Talk:A may be very complicated even if it presently only has a banner. Many pages, especially project-related, have gone through multiple roles before they settled down on their present function. So the history of Talk:A may be completely unrelated to the purpose of Talk:B but make sense under the name of Talk:A. Jason Quinn (talk) 16:04, 26 April 2017 (UTC)
  • Support Trying to think of a reason this might be bad but only noticing benefits. Anybody else better at playing Devil's advocate with this? Jason Quinn (talk) 16:05, 26 April 2017 (UTC)

Experiment to see if training modules are helpful for new users

I'd like to run a controlled experiment with pointing new users toward these training modules, to see if providing such training modules makes newcomers more likely to stick around and become effective editors. We've done such things occasionally before — inviting 10,000 users to try The Wikipedia Adventure, for example — to mixed results, and we haven't yet found anything that actually makes a demonstrably positive difference, in terms of automated welcomes. However, I think there are a few differences that make it worth trying again with these training modules. First, the user experience is much more streamlined than any on-wiki intros / tutorials we've tested before. New users are typically overwhelmed with the abundance of links and places to go when they get started on Wikipedia. Second, compared to The Wikipedia Adventure, these training modules are much more practical, aimed at efficiently teaching the basics of how Wikipedia works and how to edit it. They've also been through a lot of iterations based on user tests and feedback from Wiki Ed classroom program student editors, to make sure they are clear and address the most common problems that new editors run into.

You can see a little more detail about what I'm proposing here: Wikipedia:Bots/Requests for approval/RagesossBot 3.--ragesoss (talk) 17:52, 18 April 2017 (UTC)

  • I support this proposal. I ran the experiments for Teahouse and Wikipedia Adventure invites, and I think it is a great low-impact/high-value method for testing out new approaches to onboarding newcomers. J-Mo 17:58, 18 April 2017 (UTC)
  • I'm all for initiatives like this but when I click through to an introductory module and see it's going to take me nearly half an hour to complete, I nope right out of there. I'm skeptical that someone who registers an account (presumably with some particular edits in mind that they want to make soon after account creation) would generally be up for completing hours of training modules. That said, I'm not opposed to a trial that might prove me wrong! Sam Walton (talk) 18:00, 18 April 2017 (UTC)
  • Yeah, I'm quite certain that most users will not go through them. But part of the design is to offer the whole set, each with a specific topic, so that if a user is actively interested in (say) learning about how to make edits, or learn about the rules, they'll have an accessible way to dive in.--ragesoss (talk) 18:05, 18 April 2017 (UTC)
  • Please gods yes. The pain point of new users getting smashed on their first article creation experience is something that needs our greatest efforts. --joe deckertalk 18:06, 18 April 2017 (UTC)
  • @Ragesoss: I think this is a great idea! New user retention is a huge challenge for us, but we've done comparatively little testing of strategies to address it (J-Mo and Aaron Halfaker's work being a big exception, of course). Unfortunately, I don't have much time to offer help, since I'm in the middle of preparing for a different research project about new editor success :) My one observation is that you may want to focus specifically on testing the hypothesis that it's not just offering help information, but offering a limited, manageable set of help information that makes the difference. That would be an even more useful result. So perhaps you could use a standard welcome template, instead of or alongside nothing, as a control.—Neil P. Quinn-WMF (talk) 20:23, 18 April 2017 (UTC)
  • The default situation for new users is no template at all, so I think we should at least have a control group where we do no intervention at all. I'm not opposed to a third group that gets a more standard template, but I was thinking to just start as simply as possible.--ragesoss (talk) 20:39, 18 April 2017 (UTC)
  • I'm not going to oppose a trial - we don't know if this will work until it has been tried. However, this is not support of the whole deployment, that has to come after reviewing evidence of the trial. I am not too keen on automated welcoming, they seem a bit artificial, and fake. A personal note with some helpful links or even templates I feel are much more useful, as they are more encouraging to the new user. I hope that I am wrong in this - let's give a trial and see. However, this idea of training is a great one and should be incorporated into existing welcome templates. TheMagikCow (T) (C) 19:44, 21 April 2017 (UTC)
  • As Sam Walton has pointed out this is a bit longwinded for new editors. Also it still has the unwelcoming here are the rules start that most welcome messages have. I've been developing a more low key, template based training welcome. Use {{subst:Welcome training}} ~~~~ to try it on a newbie. It came out of the GLAM program rather than education, but I don't think there is anything obviously GLAM in the current version. It can also be tailored for editathons by creating a version that links to your event page, and it feels more Wiki Like... ϢereSpielChequers 21:40, 25 April 2017 (UTC)
  • W00t, looks nice. A test seems interesting. I do wonder however how you would measure results. I suspect that actual results of something like this, lie much further down the line, then the immediacy with which people make their first edits. —TheDJ (talkcontribs) 07:45, 26 April 2017 (UTC)
    • @Ragesoss: BTW, the end of course drops you into the Program selector for wiki courses. Might want to give people a link with a ?disableprograms param or something to disable that full on wiki edu experience for this test. At least, as far as I understand you want to distribute to people outside of wiki edu. —TheDJ (talkcontribs) 08:38, 26 April 2017 (UTC)

Archiving weblinks

I would like to propose the development of a bot or program for all projects and languages that turns outdated weblinks into archived version links like in Wayback Machine. Would that be feasible and has there been an identical proposal here or at Phabricator yet?--Hubon (talk) 21:02, 18 April 2017 (UTC)

@Hubon: I don't think the WMF would do this for all projects and languages, given that there are more than 700 WMF sites (translation requirements and different templates; some projects just might be too small or not important enough and a bot might be unnecessary). InternetArchiveBot is currently running on the English and Swedish Wikipedias, and Wikiwix archive links seem to be automatically added on the French Wikipedia. I'm not sure about other projects though, but IABot is apparently "in ongoing development, to support additional wikis". Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
11:55, 21 April 2017 (UTC)
InternetArchiveBot is a project that is now in the process of being deployed to other wikis. If you have a Wikipedia in, start a discussion there and link to that discussion by creating a new ticket with this tool.—CYBERPOWER (Chat) 12:01, 21 April 2017 (UTC)
@Jc86035: Thanks for the information! @Cyberpower678: I'm sorry, but I'm afraid I didn't quite get your message. Apart from English Wikipedia, I mainly edit in the German project. And, in fact, I already asked there about this issue but didn't really receive a proper reaction... What now?--Hubon (talk) 19:20, 23 April 2017 (UTC)
@Hubon: This may interest you. I opened a discussion there, but go no response so far. Try to attract some editors to that thread. I have dewiki on my radar to deploy IABot.—CYBERPOWER (Around) 19:56, 23 April 2017 (UTC)
@Cyberpower678: Thanks for your help! I did as you asked me for. Now let's hope and see... Best--Hubon (talk) 00:34, 25 April 2017 (UTC)
@Hubon: Thanks. Can you point it to the proposal that can be found at de:Wikipedia:Projektdiskussion/Ein_Bot_zu_bekämpfen_von_WP:Defekte_Weblinks_(Bereitstellen_von_InternetArchiveBot_zu_dewiki)?CYBERPOWER (Message) 01:23, 25 April 2017 (UTC)
Derp, never mind. I didn't see the link. :p—CYBERPOWER (Message) 01:24, 25 April 2017 (UTC)

Recategorizing all medicine and biology articles using the more specific MeSH hierarchy

MeSH is a very important database created by the United States National Library of Medicine (NLM) to index books and journal articles in medicine and biology. It is updated annually. For 2017, it contains more than 55000 categories (they call them descriptors) which can very specifically categorize any article of biology or medicine. My idea is to import this tree hierarchy to Wikipedia. This could be achieved using AWB tool and an approved Bot account. I got already a *.xlsx file listing these descriptors from the official MeSH website. I have then converted it to a text file which is ready for mass category creation using CSV Loader Plugin of AWB. Some of these categories are already on Wikipedia, but I believe the majority are not yet. Each MeSH category will contain the following text:

Template:empty category
Template:MeSH category, including the unique MeSH ID as a key.
template:cat main
MeSH definition:
category:Medical Subject Headings, including the tree number as a key.

Examples of such MeSH categories are: Category:Anatomic Landmarks, Category:Body Regions

I think also that this idea, if applied, will reveal hundreds of new red links.

Previous discussions:

Tools needed:

Support

  • Support Doc James (talk · contribs · email) 23:27, 18 April 2017 (UTC)
  • support--Ozzie10aaaa (talk) 00:07, 19 April 2017 (UTC)
  • Support - AWB and bot usage to automate the organisation of already created categories into the MesH hierarchy, and future categories at a reasonable interval. I think the automated creation of (potentially 50,000+) categories needs a more thorough proposal with a more advanced bot or significant user interaction. PriceDL (talk) 12:27, 20 April 2017 (UTC)
    • Would also support the automated creation of currently nonexistent categories necessary to represent the MesH hierarchy. PriceDL (talk) 12:31, 20 April 2017 (UTC)

Oppose

  • This seems a misuse of the categorization system. Finding which articles are missing is not the purpose of categories (or else they should be maintenance categories, hidden from sight), normally one would create one or more lists in project space for this where the redlinks can be listed. Having 55,000 categories for this is serious overkill (do we really need Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4, which has two different codes to boot?). Creating a category system using a higher level of grouping from this tree hierarchy seems a potentially good thing though, with just a few thousand categories. I also don't see how you propose to differentiate between categories with the same MeSh name (e.g. "Superficial Musculoaponeurotic System" is A01.456.505.875 and A01.598.500). The actual benefit you propose (" It will ease access to medical articles from categories.") can better be achieved by a somewhat smaller category tree than the massive one you propose. Fram (talk) 07:17, 20 April 2017 (UTC)
    • @Fram: Would you suggest a way to remove very very specific categories like Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4 from the hierarchy? Regarding categories with the same Mesh name, they are basically the same category but subcategorized under two different categories, that's why they have different tree numbers, but you can notice that they have the same "unique" ID number. --Brainist (talk) 07:29, 20 April 2017 (UTC)
      • I don't know a way whereby a bot can decide which categories are too specific, and which aren't. It isn't as easy as saying "lowest level is not used, all higher levels are used". Perhaps something like "only go three levels deep" may be a (simplistic) solution. Or perhaps this simply isn't a good bot task after all. Creating thousands of empty mainspace categories seems like a bad idea in any case. Fram (talk) 08:48, 20 April 2017 (UTC)
        • Thanks for making me aware of the duplicates, which after exclusion, the unique categories came out to be almost exactly the half, just 27900 categories. I don't think this number for categorizing all articles related to whole medicine, dentistry, veterinary medicine, biology is massive. They will be temporarily empty till I fill them. Notice that out of those 27900, there are already thousands of medical categories out there in Wikipedia which will be skipped by the bot. --Brainist (talk) 09:39, 20 April 2017 (UTC)
        • Category:Peptidyl-Prolyl Cis-Trans Isomerase NIMA-Interacting 4 would be almost empty today containing just "PIN4", but after let's say 3 years, with the encyclopedia expanding, this category will contain articles about diseases caused by malfunction of this enzyme or drugs acting on it, etc. This hierarchy will be the last categorization needed for medical and biological articles, and it will be updated annually with the release of a newer version of MeSH database by NLM. --Brainist (talk) 09:51, 20 April 2017 (UTC)
          • We've had PIN4 for 9 years now, and no articles link to it. I see no reason to share your optimism that in a few years time, these categories will be populated with more articles suddenly. Subdividing categories when they turn out to be overpopulated is natural; creating thousands of empty and near-empty categories in the hope that they will magically become more populated in a few years time is not something I can support though. I also note that this is much wider than just medicine: your proposal would create categories like Category:Alouattinae, which owuld be a duplicate of Category:Howler monkeys. I don't see in your proposal how you wuold deal with the many, many similar cases where we already have a category for the common name and you would create one for the MeSH name. Basically, the more I look at this, the less erason I see to do this by bot or en masse. Fram (talk) 10:33, 20 April 2017 (UTC)
  • Oppose - we do need human judgement on which categories need to be created. For example, we have Category:Bonobo, so we don't need Category:Pan paniscus (on List of MeSH codes (B01)#MeSH B01.150.900 --- vertebrates, number B01.150.900.649.801.400.112.400.600); nor do we necessarily need Category:Papio anubis or its likely name Category:Olive baboon (number B01.150.900.649.801.400.112.199.120.610.050). While both of these items come from the organism subtree, I think similar attention would need to be given to the other subtrees. עוד מישהו Od Mishehu 11:41, 20 April 2017 (UTC)
  • I'm not going to use bold in this oppose, but is this not better done at Wikidata, which already has Mesh IDs? --Izno (talk) 12:20, 20 April 2017 (UTC)
  • Oppose We do not usually need this degree of specialization. There is no virtue in overly narrow categories-. For many of the MESH categroies, the WP search function will work quite well. Categoriews also normally use generally accessible terminology,; MESH is specialized. Our articles are intended for general readers. DGG ( talk ) 14:09, 20 April 2017 (UTC)
  • Oppose The human touch works well for creating needed categories. We do not need more elaboration in the form of over-specialization and creating overly narrow, contra-intuitive categories. If anything, the current tree needs pruning. Dlohcierekim 18:11, 20 April 2017 (UTC)
  • Please don't add them all, as it will result in many empty or useless categories, that will just have to be deleted. I think some human house will be required evaluate which ones are useful , and where they should be added into the already existing category tree. Graeme Bartlett (talk) 08:17, 21 April 2017 (UTC)
  1. Oppose we have already had very poor experiences using alternate category and tree categorisation systems in the anatomy space. Problems that we encounter are trying to morph our existing content to match systems that don't match our unique scope, style or notability or requirements. The fact is, we are a unique encyclopedia and we do not need to duplicate other categorisation systems. Wikidata would be a more appropriate mechanism to deploy MeSH data, and then link that to articles.--Tom (LT) (talk) 11:29, 22 April 2017 (UTC)

Discussion

How will the bot identify which categories to give to each article? Chiswick Chap (talk) 21:37, 18 April 2017 (UTC)

The bot will be used to create the categories. Categorizing article I will then do manually. Do you have a better idea to do this using a bot? --Brainist (talk) 21:43, 18 April 2017 (UTC)
Some articles already have a MeSH code, so they could be classified automatically by a bot. But there are already 2,600 categories and over 30,000 articles in the scope of WikiProject medicine. Is it actually your intention to make use of all 55,000 MeSH descriptors and manually assign each of the 30,000 articles into categories based on those descriptors? --RexxS (talk) 21:54, 18 April 2017 (UTC)
@User:RexxS, I think the hardest part is creating 55,000 new categories. This must be done using a bot. It is ok if I do the categorization part manually, even if it takes a while.--Brainist (talk) 23:03, 18 April 2017 (UTC)
What is the benefit? Doc James (talk · contribs · email) 22:28, 18 April 2017 (UTC)
@User:Doc James, the same benefits of categorization in general. It will ease access to medical articles from categories. For example without Category:Amygdala, it would be hard to find all Wikipedia articles related to amygdala's anatomy, histology, physiology, diseases, and surgeries. And as I mentioned before, It will reveal the shortage in medical content. I noticed that many MeSH descriptors don't have a corresponding Wikipedia article. --Brainist (talk) 23:03, 18 April 2017 (UTC)
Okay sounds reasonable. This will also incorporate articles related to anatomy, molecular and cell biology, and physiology etc. Doc James (talk · contribs · email) 23:27, 18 April 2017 (UTC)

Is the source for this bot available so we can confirm it won't break everything? Also, how will the task be separated between the bot and AWB? PriceDL (talk) 17:23, 19 April 2017 (UTC)

@PriceDL: using the CSV loader plugin, the column header:
Bot using AWB tool in CSVLoader plugin
##article_name##$$##Unique_ID##$$##Description##$$##treenumb##
for example:
  • I should mention than unsued categoriwes can be speedily deleted; categories
##Category:Cavernous Sinus##$$##D002426##$$##An irregularly shaped venous space in the dura mater at either side of the sphenoid bone.##$$##A07.231.908.224.334##

will be used, with the general text:

template:empty category
template:MeSH category|##Unique_ID## 
template:cat main
MeSH definition: ##Description##
category:Medical Subject Headings|##treenumb##

The AWB tool is semi-automated, namely it can find the column headers within a text and replace it, but it needs a user to click the save button for each category. In order to avoid clicking the save button 50,000+ times manually, I want a bot with AWB permission to automatically click the save button (see the picture). After creating all categories, the bot will use very simple pywikibot scripts to categorize them inside each other and form the MeSH tree.--Brainist (talk) 04:07, 20 April 2017 (UTC)

  • I should mention that it is part of general Deletion Policy for empty categories to be speedy deleted. Categories containing only very few items are routinely brought for discussion at WP:CFD, and almost always upmerged or removed. There is also a formal procedure for renaming categories. If anyone should add several tens of thousands of empty or almost empty categories, I expect it will be considered unconstructive. DGG ( talk ) 14:17, 20 April 2017 (UTC)

Change WP:NPROF

I think NPROF should redirect to WP:PROF, and a new redirect created for non-profits. Perhaps WP:NONPROF or WP:NPROFIT? We already have WP:NONPROFIT, so it is possible to free up NPROF. Many more times I will be looking for NSCHOLAR than NONPROFIT, and it took me a few extra minutes to guess at NADADEMIC which got me to the correct policy page. I created NSCHOLAR because I saw that many other editors had referenced SCHOLAR as that, and N is used ot denote the Notability guideline as opposed to some other guideline, or a sub-section of BLP. Any thoughts? L3X1 (distant write) 00:36, 22 April 2017 (UTC)

No one objected, so I have been bold:

NPROF now redirects to PROF which is Wikipedia:Notability (academics)
NPROFIT and NONPROf now go where NPROF used to go, Wikipedia:Subjective importance

L3X1 (distant write) 19:24, 24 April 2017 (UTC)

I wonder whether people will expect them to go to the same page as WP:ORG and WP:NGO instead. WhatamIdoing (talk) 06:04, 25 April 2017 (UTC)
  • The number of shortcuts is ridiculous. There are jargon. They are a barrier to newcomers. And when people start talking in shortcuts, it dumbs down the conversation. --SmokeyJoe (talk) 06:57, 25 April 2017 (UTC)
I disagree with your last statement. L3X1 (distant write) 00:28, 28 April 2017 (UTC)

Interwiki links

Hello, I would like to propose the development of an advanced function for interwiki links (if possible, for all Wikimedia projects): When we want to insert a wiki link, we already have a function that is able to convert a URL into a wiki link. However, this does not seem to work for URLs from other language versions and Wikimedia projects. So wouldn't an appropriate improvement make sense?--Hubon (talk) 00:45, 25 April 2017 (UTC)

Let's start with... "Which editor" ? :) —TheDJ (talkcontribs) 07:42, 26 April 2017 (UTC)
@TheDJ: Thanks for asking! Ideally both, I guess; otherwise rather the source editor. What do you think?--Hubon (talk) 20:50, 26 April 2017 (UTC)

How would it be, if the feature "page preview" made available for not-logged-in users?

The Page Preview option (still a beta feature) is a very useful and simple feature. It helps to check what's in a link, without loading the link. This helps the user to read/work, think and find stuffs faster, without losing focus. But it could be used only in logged-in condition/ by logged-in users.

How would it be; if this feature is made available for peoples who are not logged in? RIT RAJARSHI (talk) 15:41, 25 April 2017 (UTC)

@RIT RAJARSHI: See this page. With this said, I don't think it should be in beta any more. It's fine as is and should be released and enabled by default. Anarchyte (work | talk) 13:00, 27 April 2017 (UTC)

Proposal that pages created through Wikipedia:Articles for deletion be Autopatrolled regardless who creates them

I am proposing that any new pages created which start with "Wikipedia:Articles for deletion/" be automatically patrolled regardless if its creator has the "Autopatrolled" user right or not. This proposal is rather to the point, but the reasons why and the benefits, not so much. I discovered an issue while attempting to patrol new pages in the "Wikipedia:" namespace, and at the present time, my ability to find pages in that namespace with issues are difficult and time-consuming to find due to most new pages created in the "Wikipedia:" namespace (probably literally 19 of 20 of non-redirect pages created) starting with "Wikipedia:Articles for deletion/". The main benefit of this is the fact that Special:NewPages will not be blogged down by all of these pages and make it quicker to locate problematic pages in that namespace (such as essays, new policies not discussed, shortcuts to other pages, etc.), and the downside is of course that they will no longer be in Special:NewPages. However, in regards to "downside" ... from my understanding, most, if not all, pages created which start with "Wikipedia:Articles for deletion/" are detected by a bot which will fix listing issues with the page if it is not listed properly per the instructions at WP:AFD, meaning regardless if it is technically patrolled, editors will see it anyways there and be able to determine if the page is eligible for any of the "G" categories of the speedy deletion criteria.

However, with that being said, this should probably not apply to new redirects created which start with "Wikipedia:Articles for deletion/" since these are not nomination pages, and thus are not detected by a bot for listing on WP:AFD. Steel1943 (talk) 18:31, 25 April 2017 (UTC)

  • Oppose, besides being technically complicated, non-article pages of any kind are easily filtered out of NewPages. — xaosflux Talk 19:09, 25 April 2017 (UTC)
    Yes they can be filtered out, but when looking up solely pages in the "Wikipedia:" namespace, that is where the flood of "Wikipedia:Articles for deletion/" pages appear, and thus why I'm proposing this. That, and if this can technically be done (which I'm sure it can be), I'm not understanding why that's a reason to oppose since technical implementation isn't related to human error or vandals abusing the system. Steel1943 (talk) 19:30, 25 April 2017 (UTC)
    The technical implementation of "autopatrol" addition to the creation themselves is difficult. What might be considered instead is an "AutopatrollerBot" that takes a regex list of pages (or similar) that it can patrol. That said, that does remove it from a review queue--and I can imagine that AFD subpages are sometimes created in a vandalism sense. Are you comfortable letting those escape (even though they are not indexed)? --Izno (talk) 20:07, 25 April 2017 (UTC)
    Alternatively, perhaps this indicates that the patroller interface needs improvement (oh, how we've heard that!) such that multiple entries, if they are not now, can be patrolled at the same time. Or even more alternatively, give autopatrolled to more people (than) the frankly-ridiculous 25-article-creation requirement allows. --Izno (talk) 20:09, 25 April 2017 (UTC)
    @Izno: If this proposal doesn't pass, I support this an alternative, such as if there is a way to exclude pages with a certain prefix from results when skimming through lists of unpatrolled pages and since this option would fix more than the specific issue I brought up here. Steel1943 (talk) 21:07, 25 April 2017 (UTC)
    Which alternative was that? :D I proposed three. --Izno (talk) 03:15, 26 April 2017 (UTC)
    I'm not sure what you mean. I think I meant to say "an" instead of "this". Steel1943 (talk) 08:39, 26 April 2017 (UTC)
    @Izno: The "Are you comfortable letting those escape" concern I believe would be absolved by the fact that a bot lists most new pages on WP:AFD if they are not transcluded properly. (If a bot didn't do that at all, my answer to your question would be a huge "no" since then, there would no longer be a first line of defense to detect these pages.) Steel1943 (talk) 21:04, 25 April 2017 (UTC)
    Perhaps the transcluding bot could be modified to patrol the AFD which it is transcluding. Might feel bad to put it in that bot, but better that one (and when/if that bot dies, we know to include that as a required task, rather than have it scattered to a PatrollerBot). --Izno (talk) 03:15, 26 April 2017 (UTC)
    I support such a bot - and it should also patrol any properly transcluded non-patroled AFD page. This would serve as an indication for patrolers that the specific AFD has been handled to the point that if there are any issues (including clearly bad-faith nominatios), it will be handled - the truwe purpose of this feature (just like we generally mark CSD-tagged pages as patroled). עוד מישהו Od Mishehu 03:13, 27 April 2017 (UTC)
  • Support a non-mainspace patrol bot in general, for various purposes to be decided by consensus. This would include properly transcluded AFD's, MFD's, and SPI's, but could also conceivably work on things like user talk pages created by Huggle and talk pages consisting solely of WikiProject banners. – Train2104 (t • c) 23:57, 27 April 2017 (UTC)

Net neutrality

Wikipedia should do something to try to stop Ajit Pai and the FCC's attempt at eliminating net neutrality in the US, which could lead to censorship of websites like what Comcast did with slowing BitTorrent speeds on its network before net neutrality was the law. We could blackout Wikipedia like what happened with SOPA, or just place a large banner. I'm fine with either. Either way, this attempt at eliminating net neutrality is a big deal, and it is important that this attempt be stopped to once again to prevent censorship on the Internet. We'd also need to figure out a date to protest. AnAwesomeArticleEditor (talk) 11:21, 27 April 2017 (UTC)

Wikipedia has been involved far too much in politics, and adding this sort of political crusade is not really what Wikipedia is about. Collect (talk) 13:00, 27 April 2017 (UTC)

That black out better not be repeated, ever. L3X1 (distant write) 00:30, 28 April 2017 (UTC)

Agree w/Collect. Excepting issues where at least 90% of Wikipedia editors are in agreement (ain't happenin, even if it could be determined), Wikipedia should stay out of politics. Not sure whether I agree with L3X1, as a legitimate blackout situation is not inconceivable to me. But this isn't one. ―Mandruss  00:44, 28 April 2017 (UTC)

Well Mandruss, I can think of a reason for a legit sitewide lockdown: in case of a largescale vandal bot attack or something in which the disruption is more than can be handled, or DNS attacks etc. But shutting down a site (used by EVERYONE, lets not delude ourselves) to show how powerful the Grand Sysops are, is petty and an immature thing to do. Denying a resource (which is supposed to be neutral) to protest something like is a bad idea, and doesn't (to me, at least) demonstrate Competence. My thoughts on Net Wild West Net neutrality can be discussed or not, here or elsewhere, I just really really disapprove of the Project doing stunts like that. L3X1 (distant write) 01:43, 28 April 2017 (UTC)
I'm thinking of something so incredibly bad that the costs of tolerating it would exceed the admittedly high costs of a shutdown. In such a case, we probably would have 90% agreement, so I'm contradicting myself. It's probably unuseful to speak in generalities, and I can't think of a specific hypothetical offhand. It would be something worse than, say, a particular person being elected U.S. president. ―Mandruss  01:58, 28 April 2017 (UTC)

Adding an 'infrared flash photography' page to the wiki

After reviewing your 'Pages in category “Photography by genre”' I see you are missing a listing for infrared photography and infrared flash photography on the list. I gave up wasting my time with the Wiki after you deleted 200 of my photos because I would not allow commercial use. But if you want to add an infrared flash photography page you can take what you like from my photos here:

https://danielteolijr.wordpress.com/2015/08/17/piercing-darkness-update/

Just no commercial use of the photos, only educational and editorial use. The link also discusses the history of infrared flash photography which I am a specialist and world leader in.

Best Regards,

danielteolijr

We already have Category:Infrared imaging whereas Genre I would think refers to something else rather than the recording medium, method etc., itself. Yet it is worth considering a fresh look at these cats.Aspro (talk) 16:02, 27 April 2017 (UTC)

Project participants bot

A lot of WikiProjects have a participants page where people can sign up and say they are a member; however, those pages tend to get stale over time. I'd like to see a bot analyze the contributions of users who edit pages under a project banner and then give out a list of those editors who are, for example, in the top 25th percentile for activity. I would think that it should only run once a month, similar to how Popular Pages worked (or is it back again)? –Fredddie 21:16, 27 April 2017 (UTC)

@Fredddie: see Wikipedia:Bot requests to request someone build a bot. — xaosflux Talk 00:12, 28 April 2017 (UTC)

RfC: Community Based De-adminship

Looks like a consensus that this wouldn't work, so I'll WP:Snow close this now. Thanks for considering it. -Obsidi (talk) 02:13, 28 April 2017 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Introduction

The Arbitration Committee process is great for disputes among large numbers of editors where there are multiple possible remedies that could occur for a large number of editors. It doesn’t succeed as well for requests to desysop due to the bureaucratic nature, the long timelines, and the lack of community input. It is also not as successful for long term low-level abuse of tools where the admin has lost the trust of the community. I wish to propose a slight change to the current system.

I believe by giving the community a way they can start the process, along with a simplified procedure, that it will improve the system along with the trust of the community in giving people the bit more often.

Proposed Community Based De-adminship

If there is a consensus for De-adminship of a given administrator by the community at WP:Administrators' noticeboard, then a motion will be made on behalf of the community to the WP:Arbitration Committee to desysop the admin. It will still be up to the WP:Arbitration Committee to evaluate the evidence presented at the WP:Administrators' noticeboard and to evaluate if the administrator failed to act in a manner appropriate for an administrator to the extent of requiring desysop or to get any additional evidence or information needed to make that decision.

Thank you for considering this proposal. -Obsidi (talk) 23:15, 27 April 2017 (UTC)

Support

  • Support as proposer. -Obsidi (talk) 23:15, 27 April 2017 (UTC)

Oppose

  • Oppose A perennial proposal that always seems to run into roadblocks. This one is even more vague than any of the other ones that have come up and even more open to gaming and disruption by the countless trolls that inhabit enwiki. If you have a serious complaint about abuse of the admin toolset, ArbCom is always open to hear valid complaints. Having another step before the ArbCom process is silly. --Majora (talk) 00:41, 28 April 2017 (UTC)
  • Oppose The wording of this proposal is way to vague for me to comfortably endorse it. As Majora mentioned this is a perennial proposal that never seems to get more traction. Perhaps if this proposal was more definite in its explanations of the process I'd be more likely to support. As it is I can not in good conscience support this. --Cameron11598 (Talk) 00:52, 28 April 2017 (UTC)
  • Oppose While brevity is often to be admired, this proposal is just too simplistic to be implemented. Any attempt to fix its vulnerabilities (vagueness, susceptibility to gaming, likelihood to flood AN with spurious requests, etc.) would soon turn it into the bureaucratic process that is currently in place through ArbCom. Eggishorn (talk) (contrib) 01:08, 28 April 2017 (UTC)
  • Oppose I echo all of Eggishorn's concerns. The gaming by trolls with an axe to grind but little to no evidence already wastes to much time. MarnetteD|Talk 01:16, 28 April 2017 (UTC)
  • Opposer What we really need to do is be more discretionary in our elections: ie, are they civil and able to comport themselves properly? If yes, than give tools, if not, (no matter what else they have done, tenure, GA and FA, ITIS,) they shouldn't get it. Less content editors and more vandal police. L3X1 (distant write) 01:47, 28 April 2017 (UTC)
  • Oppose. This doesn't actually change anything. I like community-based desysopping as a concept, but this particular proposal isn't a step forward. Any editor can file a case request for ArbCom to take up and consider desysopping already. How does requiring consensus to file such a case request actually help anything? ~ Rob13Talk 01:54, 28 April 2017 (UTC)

Neutral

This already can and does happen in practice. Someone raises what the "terrible" admin did at AN, a bunch pile on, someone says take it to Arbcom and they are off. (It involves much more drama than that, but you get the picture). Alanscottwalker (talk) 02:02, 28 April 2017 (UTC)

I think you're missing the ArbCom fastpath part, which does not exist today. I think one of the questions is whether ArbCom is capable of venturing outside their own structure and bureaucracy, and the prevailing view appears to be "no". ―Mandruss  02:12, 28 April 2017 (UTC)

Discussion

My understanding is that it is still theoretically possible for the community to desysop by consensus; the problems are the practicality of finding consensus to do so, rather than the lack of a process for doing so. If we're going to desysop through AN, why involve the committee at all? Why not just say that the 'crats can find a consensus to desysop in a relevant AN discussion? GoldenRing (talk) 23:41, 27 April 2017 (UTC)

Per WP:Administrators#Review_and_removal_of_adminship, I believe the only groups that can currently remove admins are Jimbo Wales, by stewards, or by a ruling of the Arbitration Committee. Also there have been several previous requests to remove admins by the community which have failed not because anyone said that the community could already do so but because of fears of sockpuppets/meatpuppets or other "mob mentality" leading to an inappropriate desysop. This proposal is designed to go through a simplified WP:Arbitration Committee process to remove the possibility of such problems. Prior proposals have also requested that a committee of 'crats decide of a desysop should occur (see [5]), however it was opposed on the idea that 'crats are not selected for their abilities in this area (ArbCom members are), that 'crats are life-time appointments (many from a long time ago), and that it would add an additional bureaucratic organization in WP. This proposal tries to avoid all the problems previously presented. -Obsidi (talk) 23:50, 27 April 2017 (UTC)
@GoldenRing: You are incorrect, which perhaps helps you better understand why many people opposed your RfA due to lack of experience/record. If an admin is elected and then takes poor actions, the only possibility to remove them is to go through the Arbitration Committee. ArbCom has historically been extremely reluctant to desysop anyone without egregious abuse of the admin tools. The current Committee, in particular, has essentially pretended WP:ADMINCOND doesn't exist. There is zero community recourse if ArbCom chooses not to act. ~ Rob13Talk 01:57, 28 April 2017 (UTC)
Resolved Procedural Problem

@Obsidi: Procedural note. Remember that everything before the first signature comprises the listing entry. I don't think that should include a section heading. ―Mandruss  23:59, 27 April 2017 (UTC)

I've changed it, it looks like it updated correctly now. -Obsidi (talk) 00:03, 28 April 2017 (UTC)
@Obsidi: Solved the listing problem, but in a messy and unconventional way. The {{Rfc}} template is usually first. You could create "headings" without using section headings, as Introduction for example. ―Mandruss  00:10, 28 April 2017 (UTC)
Ok let me see if this works (removing the rfcid).-Obsidi (talk) 00:12, 28 April 2017 (UTC)

How is this any different from the current process? It all still needs to be taken to Arbcom. CHRISSYMAD ❯❯❯¯\_(ツ)_/¯ 00:50, 28 April 2017 (UTC)

This goes through the simplified motions process of ArbCom and not through the normal case process. Instead it allows greater community involvement with faster resolution once it gets to ArbCom. -Obsidi (talk) 00:54, 28 April 2017 (UTC)
Seeing as ArbCom would still have to review the evidence in the case and hear statements I don't see how a simple motion will fly here. Reviewing the evidence and hearing statements is a full case and full cases are always open to community involvement. In fact, during legitimate desysoping "trials" the case talk pages are usually full of community involvement. Seeking a faster resolution is the only saving grace here and frankly, it isn't that big of a saving grace. Rushing is not something that I particularly want to do in these cases. --Majora (talk) 00:57, 28 April 2017 (UTC)
They will have to review the evidence presented, but hopefully all the evidence and statements will have already been presented at AN without the need for extensive process by ArbCom. -Obsidi (talk) 01:02, 28 April 2017 (UTC)
"Without the need for extensive process by ArbCom"...yeah...you aren't familiar with how ArbCom works are you? Extensive process is kinda their thing. And seeing as there is no actual time table written into this (one of the many ways this proposal is vague) that isn't likely to change. --Majora (talk) 01:12, 28 April 2017 (UTC)
Note that WP:VPI is intended for incubation of ideas and formulation of specific proposals for this page, and that would work well if it had a lot more participation. Most editors aren't interested in that part of the process, we just want to !vote on specific proposals. This is part of the reason that any significant change is very hard to achieve. ―Mandruss  01:20, 28 April 2017 (UTC)

I would like to note that as to the "likelihood to flood AN with spurious requests," wp:Boomerang is always a possibility at AN, and filing a completely spurious request would likely lead to that. -Obsidi (talk) 01:18, 28 April 2017 (UTC)

Boomerang is a generally weak deterrent and would be no deterrent at all to a troll that knows they are likely to face indeff anyway. Eggishorn (talk) (contrib) 01:31, 28 April 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=777589286"
This content was retrieved from Wikipedia : http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (proposals)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA