Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 😂 (talk | contribs) at 21:55, 2 March 2018 (→Survey: MedCom rejects). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


ZipcodeZoo.com

ZipcodeZoo.com is a free online natural history encyclopedia, with a page for every living species. Text is supplemented with video, sound, and images where available. The site's 6.1 million pages include over 1.2 million photographs, 52,000 videos, 223,000 sound clips, and a 3.9 million maps describing 4.7 million species and infraspecies.

ZipcodeZoo draws on the Catalogue of Life for its basic species list, the Global Biodiversity Information Facility for its maps, Flickr and the Wikimedia Commons for many of its photos, YouTube for videos, the Taxonomicon for taxonomic information, and Xeno-canto for some of its sound recordings. All pages are published under one of the Creative Commons licenses.

I began creating ZipcodeZoo.com in 2004, and have thousands of hours invested in its development. Much of this time was spent in developing tools that could competently harvest other trustworthy public sources of species information, integrate that information, and display all pages with a standard look and feel.

MediaWiki is now the engine behind page delivery for the website.

I've posted over 40,700 of my wildlife photos to Commons.wikimedia.org (see here), and now want to act to preserve the intellectual content of ZipcodeZoo's pages by providing it to Wikipedia.

The addition of the ZipcodeZoo.com content to Wikipedia would add or change many pages. Consider the difference between the descriptions of Zenaida macroura on ZipcodeZoo.com and on Wikipedia.

My proposal is that

  • I would write the code that would create Wikipedia pages that do not exist, as well as to edit existing Wikipedia pages to incorporate the additional ZipcodeZoo.com information.
  • All uploaded material will be available under the Creative Commons Attribution-Share Alike License.
  • Prior to uploading, my code would remove all references to photographs other than those available at Wikimedia Commons.
  • No existing content in Wikipedia would be replaced. My goal is to only supplement the current information of Wikipedia.

Before I begin, I need to get some feedback on this proposal from those who've worked so hard on Wikipedia. I don't want to flood the site with SPAM, and don't want to invest a month in coding a bot that won't be used. - David Stang (talk) 13:55, 16 February 2018 (UTC) (240) 477-8817. [email protected][reply]

Comment - do you have an example of what this change would look like for an article? Nessie (talk) 14:45, 16 February 2018 (UTC)[reply]
Here are some examples:
  • Pileated Woodpecker on Wikipedia and ZipcodeZoo: expand the scientific classification section of the taxobox to include the additional details from ZZ; add the section on Distribution, with the map.
  • Northern Fur Seal on Wikipedia and ZipcodeZoo: add vernacular names; expand taxobox; add the map; add images; add bibliography.
  • Andaman shrew on Wikipedia and ZipcodeZoo: add vernacular names, habitat and ecology, taxonomy, distribution, and bibliography sections. Also expand taxobox.
In general, those pages that have little information at Wikipedia would grow more than those that already have a lot.
David Stang (talk) 17:53, 16 February 2018 (UTC)[reply]
ZipcodeZoo was offered to Wikispecies in July 2017 (species:Wikispecies:Village_Pump/Archive_43#ZipcodeZoo) One major concern expressed at Wikispecies was that some of the photos at ZipcodeZoo were licensed CC-BY-NC-SA and thus not compatible with WMF's CC-BY-SA license. Restricting photos to those on Commons might avoid that particular problem. However, I note that the text in ZipcodeZoo's Andaman shrew page is almost entirely taken from the IUCN Redlist. The IUCN does not permit commercial use of their data.
I appreciate the offer being made. I have some serious concerns about how ZipcodeZoo could be integrated into Wikipedia. I'll just pick two nits for now; I'm not seeing a link from ZipcodeZoos Andaman shrew article to the IUCN record, just links to the IUCN search page. The Wikipedia article has two direct links to the IUCN record. Secondly, long standing consensus is not to include minor taxonomic ranks in most cases; we don't want to expand the taxoboxes of Northern fur seal and Andaman shrew.
As one of the more active Wikipedia taxonomy editors I recognize that we have too many species already and not enough people working on them to get most of organism articles into any sort of useful state. Incorporating ZipcodeZoo might be helpful, but I'd want to proceed extremely cautiously. And we absolutely need to get copyright compatibility sorted out before any other steps are taken. Plantdrew (talk) 21:49, 16 February 2018 (UTC)[reply]
  • Response: I would agree that no material would be posted to Wikipedia that was not CC-BY-SA. So the only thing I would draw from IUCN is their claim of Redlist status, and the page would display the current information as it is now displayed for the Northern fur seal, including a status sentence ("The IUCN (2008) lists the species as globally threatened under the category "vulnerable".) and an entry in the References section.David Stang (talk) 15:25, 17 February 2018 (UTC)[reply]
  • Response concerning minor taxonomic ranks: At ZipcodeZoo, I got many comments from biologists and teachers who appreciated this information. But if consensus is to not display minor taxonomic ranks, I can certainly abide by that.
  • Response concerning links to IUCN: My bot can determine the specific link to IUCN, and include this information David Stang (talk) 15:25, 17 February 2018 (UTC)[reply]
  • Response: agreed. My database contains copyright details for most of my content. I would proceed ensuring that everything was CC-BY-SA.David Stang (talk) 15:25, 17 February 2018 (UTC)[reply]
  • @David Stang: I have some questions and comments.
    1. zipcodezoo.com seems to be down now and I cannot see the pages
    2. How many Wikipedia articles would you edit or change? 500? 5000? 50,000?
    3. Along with Wikipedia, do you have opinions about Wikidata or any plans to cross post information to there? There seems to be some conversation about the copyright and provenance of some of the data you have, and Wikidata might be a more appropriate place to solicit approval and also host the first upload of the data. Blue Rasberry (talk) 23:29, 23 February 2018 (UTC)[reply]

An update of the default introduction & tutorial to Help:Introduction

Wikipedia's default introduction (WP:I) and tutorial (WP:T) for newcomers has changed little in the last decade. Yet the introduction of visual editor has made much of its advice confusing for newcomers (e.g. the advise to manually insert references using <ref>Your Source</ref>). Nevertheless, it is in a prime location, with multiple welcome messages and help pages funnelling new users to it.

Over the last two years, a group of users from the Help Wikiproject, have put together an updated version. The main menu, Help:Introduction:

  • Clearly separates the VisualEditor and WikiMarkup versions of each help page
  • Is more up to date
  • Has an easier-to-read layout pioneered by the original Help:Introduction to referencing
Proposal

Replace WP:introduction and WP:tutorial with Help:Introduction. Overall, I think it is a marked improvement over the current default. Edits can be made if there are any elements of the old tutorial that are felt to be missing from Help:Introduction. T.Shafee(Evo&Evo)talk 11:42, 17 February 2018 (UTC)[reply]

'Oppose replace - have both as we do.....much more info in the tutorial that the help project keeps up to date dispite the assertion above (only 3 of us there really making updates and were not involved in these so called new pages about the wikitext portion). Like I indicated above no problem with having two different how to styles for this info. But the help project does recognize that these "Next Pages" things don't work out all too well as view count drops dramatically on the next page. The Wiki text links are old how-to pages the peoject has not update in a long time. I am concerned with the assertion made above that the project endorses the changes....some of the linked stuff is very old. Most automated post send our new editors to WP:Contributing to Wikipedia in hopes they find what they need on the first page with links etc. I hope this request is not because you can't edit the other templates. If you need help with them just ask...no need to replace. --Moxy (talk) 03:14, 18 February 2018 (UTC)[reply]
@Moxy: The proposal is because I think that help:intro series provides better learning materials for new editors than WP:I and WP:T. A large proportion of new editors get sent to WP:I and of WP:T. WP:I gets approx 100x more traffic, and the basic editing section WP:T gets approx 10x more traffic than their Help:intro equivalents. I think that the main options are:
  • Redirecting WP:T and WP:I to Help:intro equivalents, in my opinion the simplest solution.
  • Reduce the direction of new users to WP:T and instead direct to Help:intro in the various welcome messages, templates, help pages.
  • Overhauling and modernising the existing WP:T, but I think it would end up looking extremely similar to the Help:intro equivalents, at which point it'd be much of a duplication.
Apologies if I seemed to be speaking for the whole of WP:WPHELP - I was attempting to not take credit for the work of multiple people on the help:intro series. My application for templateeditor status was largely to be able to edit the {{Intro_to}} template. T.Shafee(Evo&Evo)talk 05:05, 18 February 2018 (UTC)[reply]
I do not belive Help:Introduction sub wiki introductions that have not been updated in a long time look better. They provide less readable text because of the sandwiched text beside the side tabs.... by omitting top tabs text is less readable especially in mobile view. Your asking to redirect two tutorials and the sub pages (Including Wikipedia:Tutorial/Editing/sandbox that is used daily) that are linked in many templates and automated messages to a list of links in a fancy format. This is a huge change that even omits a link to the projects main help pages. I am more them willing to help update what you think is missing in our long standing intros.--Moxy (talk) 06:21, 18 February 2018 (UTC)[reply]
  • Oppose: I'm not at all sure it is a good idea to show Visual Editing as the first option on "Help:Introduction". To become an effective editor, newcomers need to adopt the traditional approach using Wikicode. I note, btw, that "Help:Introduction" is linked with explanations from the Wrap-up page of WP:T. If WP:I and WP:T are not as "up-to-date" as Help:Introduction, they should be improved asap. Any important new features from Help:Introduction could also be incorporated.--Ipigott (talk) 11:14, 18 February 2018 (UTC)[reply]
Can someone explain what needs updating? So far those of us that work for the help project cant figure out what is not up to date.--Moxy (talk) 16:23, 18 February 2018 (UTC)[reply]
I've put some examples of things that I think would be worth updaing or replacing in some comments below. I really don't hthink that newcomers need to adopt the traditional approach using Wikicode. Plenty can be done without using it, and many users who just want to add a few paragraphs and references find the MS-word-like nature of VE easier to pick up than the html-like nature of WikiMarkup. Markup is certainly still more flexible, butVE is easier for first steps. T.Shafee(Evo&Evo)talk 12:18, 22 February 2018 (UTC)[reply]
  • Support in principle, though I haven't had a full read through the new pages yet. Attitudes like "newcomers need to adopt the traditional approach using Wikicode" are going to be the death of Wikipedia. It's painfully obvious that the visual editor is a vastly better way of introducing new editors to Wikipedia and a set of updated introduction pages which reflect this is a sensible idea. Sam Walton (talk) 13:11, 18 February 2018 (UTC)[reply]
The reason it's not used more is because there is so many problems Wikipedia:VisualEditor#Limitations. Need to learn some wiki code it they want to use talk pages. Files etc. We have a request to redirect 2 tutorials of 10 pages that covers both editing versions to a tutorial that separates the two and directs editors to a tutorial that has over 30 pages. The project stopped this formate years ago because....first page 5500+ views.....But...50% loss by 4th page. We have trouble keeping new editors reading 7 tabs.....not sure how 30+ tabs will help that. It's why we direct editors to WP:Contributing to Wikipedia an article style with all the info on one page.....no link runaround. Moxy (talk) 16:16, 18 February 2018 (UTC)[reply]
However, we'd need eye-tracking studies to know how much of the content on the one page is getting read. It's possible that many people aren't scrolling down to the later content, which could mean the multi-page approach still reaches more people. isaacl (talk) 17:08, 18 February 2018 (UTC)[reply]
100 percent correct....we use 2 styles of intros one has 7 tabs the other is in the article style (and the adventure that also has a completion problem) We direct most to the article style because some research seems to indicate that people get serviceable information out of the contents eye tracking and Which_parts_of_an_article_do_readers_read. Things are done in certain manners for a reason at the project. This request is a big change that the data we have tells us is not the way to go. Having more and being more stylish is not always the best way to go.KISS -Moxy (talk) 17:21, 18 February 2018 (UTC)[reply]
  • Oppose from what I can see this is a proposal to delete both Wikipedia:Tutorial and Wikipedia:Introduction, and basically replace them with Help:Introduction and a yet unfinished Help:Introduction to Wikipedia. Well I oppose these changes. The format of the pages, as well as missing a lot of detail, is a lot less user friendly in my opinion. While Wikipedia:Introduction doesn't contain a lot of information, Wikipedia:Tutorial does but in a far more user friendly format. Help:Introduction to Wikipedia hasn't even been completed yet, which makes me really question why this has even brought forward yet. Replacing a lot of advice in Wikipedia:Tutorial and replacing them mostly with a series of links is in my opinion a big mistake. Update them to include more VE info if necessary, but their basic format is a lot more favorable. Even the naming of the pages is poor and confusing. --Jules (Mrjulesd) 20:57, 18 February 2018 (UTC)[reply]
Just as a minor note, Help:Introduction to Wikipedia is only meant to be one page long. T.Shafee(Evo&Evo)talk 12:18, 22 February 2018 (UTC)[reply]
  • Oppose but with some sympathy I rarely look at either of the three pages, but I couldn´t support replacing the old with the unfinished. The old pages are clumsy written in a overcomplex form of English and jam too much on to each page and need severe pruning. The new page is focussed on how wonderful visually editor is and how there are equivalent functions in two disparate editing systems that the neophyte hasn't yet encountered.
Instead we need to function on the 'user of the page' and present what we need to tell him- in a language that is appropriate to his position on the learning curve. So at level one we want to say. A wikipedia edit has three parts- you type in an interesting fact- you say where you found the information- you write in the edit summary what you have done so you can find it later. When I am teaching wikipedia editing, my students start by writing me a message on my talk page, before they make a correction in an article. Failing that they write a short message on the article talk page, asking for forgiveness for any errors they are about to make. This blows out of the water, Visually Editor, which doesn't do talk pages- and kills stone cold the new suggested Help:Introduction. The next level one learning point is that wikipedia is not a free-for-all but has rules. This is targetted not only at the neophyte but the journalist passing by with the intention to to show anyone one can introduce a false fact so had to be prominent.
Now we get to level two skills and basic markup- student have little difficulty in understanding our markup, but we relish in failing to explain the obvious. Everyone seems to try and do a worse job than his predecessor. The difference between exposition and tutorial becomes more obvious. However remember the user will probably be very experienced in his own field, but may not have English as his first language. Put less text on each page. Avoid compound sentences, remove the nuances and put them in footnotes with {{efn}} or float individual level three pages where these can be discussed with all their options.
There are some tutorial booklet on my training page, that folk are welcome to customise for classroom use. User:ClemRutter/training * ClemRutter (talk) 01:15, 19 February 2018 (UTC)[reply]

@ClemRutter can you fix the dead links at User:ClemRutter/training would love to see what your using .--Moxy (talk) 14:52, 19 February 2018 (UTC)[reply]

@Moxy: So what happened there! Could it have something to do with MS buying Dropbox, and resetting permissions to make it more Linux unfriendly! So I have removed the links and am starting to rebuild them. Thanks for caring. ClemRutter (talk) 19:31, 19 February 2018 (UTC)[reply]
I think the links are all working- I have tested them on a third machine, as an ip logged into a new account- on a different brower-to get round the nest of cookies that were trying to be helpful. All the same the pdfs on Commons continue to work. Please let me know if you have any fresh ideas- or if I can be helpful getting the online help sorted.
  • Support (but keep the other pages around for now, and seek more input). As I learned while working on my help pages fellowship a few years ago, it's near impossible to write a perfect introduction to editing Wikipedia since users' aims and existing knowledge levels vary so much. The new pages could use more work, and better navigation between them would be helpful. However I believe they are improvements over the older pages in a number of respects:
  • The modular "Introduction to X" format was generally well received by new and experienced editors alike when I was working on the help pages, and it's great to see how these have been extended. From my research then it seemed these simpler "bitesize" introductions were a good structure. These should be backed up by easily findable more detailed help pages for topics people might be interested in, and also more personal interactive methods like the Wikipedia:Help desk.
  • The old pages attempt to cover too much for newbies. For example Wikipedia:Tutorial/Editing contains a section on Renaming articles. Not only would doing this require quite a lot of familiarity with Wikipedia:Article titles policy, but new users can't even move pages or see the relevant tab until they are autoconfirmed! And how often do you need subscript and superscript that it's one of the first things you're taught about editing? (and there are buttons for it in the toolbar if you do happen to need it).
  • While VisualEditor is not suitable for every type of edit, it does provide a better experience for many of the simple edits new users will be making at first. The new pages at least provide users with a clear choice between the editing methods, while the old pages (especially Wikipedia:Introduction) have mostly added VisualEditor as an afterthought.
  • The old pages are quite reliant on videos. Not everyone likes these as a learning method, and they are significantly harder to keep up to date with changes (the one about creating articles is from 2010!)
Since most of us commenting here are old hands and way beyond needing these kinds of introductions, perhaps we should ask for input from some actual new users on which of the pages they find more helpful? the wub "?!" 19:54, 19 February 2018 (UTC)[reply]
In writing a support, you have used almost all the same arguments I used for writing an oppose! I do hate the way that the way that sensible consensual discussion is converted into a binary edit war. So now the topic is open, I will add a few unsupported POVs to the soup, supported only by grey hair that is. There is a difference between an Introduction, Help, Tutorials, Learning materials and Marketing material- trying to do all five in the same format does not work. Taking a Support/Oppose vote to instruct writers to do so doesn't change reality.
People who have grown up with mobile phones are comfortable with that type of interface (which we need to provide for our readers) but it remains an obstacle to the keyboard generation. This applies to standard markup code keyed in with a texteditor which is familiar to anyone who has typed in his PhD or paid their way through college doing other folks typing. Visual Editor is the youngsters toy. It is a toy that every dev and coder loves- but it is too slow and it doesn't work. Older new Wikipedians spend more time hunting and pecking than being productive. It is not suitable for early work as most of that will be done on talk pages. When you are up to speed, on a fast internet connection on a fast computer (like a dev) and typing in content it has its place.
I like bitesized chunks. I agree the old pages attempt to cover too much for newbies- they were a product of their time and have dated. I have never found the need to rename a page- wikignomes do that for me (and correct my typos). I don't like comic stick figures and videos leave me cold but my grandchildren are spellbound by them (ours though are not that good) we need more not fewer but more professional in standard.
Yes to comment here you will be an old hand- but do not stereotype our newbies as being different to us. I am targetting some new potential editors- but they are all retired use pencils not phones and meetup at the archives centre under the banner of a Local History Society. People who are sent by their managers to our training sessions and editathons rarely contribute but are too polite to say why.
It would be good if a user wanted help was directed instantly to the level and type of help he needed- written in the most appropriate register of English- or at least got an instant choice on whether he was seeking an example, an introduction to the topic, a tutorial or copy for the newspaper article he was writing.
As I have said above if I can be any assistance. I don't believe that WP direction should be imposed or be the result of a binary vote- and people should have a track record in the area and have something they can offer for others to improve.ClemRutter (talk) 12:55, 20 February 2018 (UTC)[reply]
 Done removed Renaming articles and Subscript as per above from tutorial .--Moxy (talk) 16:43, 25 February 2018 (UTC)[reply]
We use the videos because data tells us people view them more then clicking to the next page ....Data. More will see the video's over click next 30 times. --Moxy (talk) 19:20, 25 February 2018 (UTC)[reply]
  • Support The new tutorial is much improved. For many users, it's much easier to start with Visual Editor for editing. The hardest part for new editors is making the first edit, which should be as easy as possible. Later on they can return to the tutorial to learn more about source editing. It seems like a great compromise and it's more focused than the general introduction. Rachel Helps (BYU) (talk) 18:31, 21 February 2018 (UTC)[reply]
  • Support per Sam Walton and Rachel Helps: the newer tutorials are much more friendly, share the right kind of information, and really focus folks on the new tools appropriate to the current editing environment. Other language wikis, have translated the Help:Introduction with success (including for example from Spanish Wikipedia for the visual editors, Sadads (talk) 22:16, 21 February 2018 (UTC)[reply]
We already use both Help:Getting started not sure why there is this plan to delete one of them.--Moxy (talk) 21:43, 25 February 2018 (UTC)[reply]
 Done add VE stuff to all tutorial pages. --Moxy (talk) 21:43, 25 February 2018 (UTC)[reply]
  • Support but I also have some comments. Avoid deleting the old pages or even marking them as deprecated, but I do favor replacing links from the old pages with the newer tutorial. Also I think the old pages could me marked to recommend the newer tutorial. For a more complete deprecation, I would like to either see some time pass with the old ones referring to the new ones or anyone publishing a comparison of the old with the new. At a glance, the old ones look quite outdated and the new one looks quite better, but I am not seeing any description of the details or any evidence that there is not some great dependence on the old tutorial. I do trust that the team at Wikipedia:Help Project has done a good job in developing this but do not now see a reason to make an immediate switch, instead of perhaps making some changes now and proposing a full switch in 3-6 months. I am unaware of how many policy or tutorial links go anywhere, so I do not know how much of an undertaking it is to manage the traffic to tutorials. Also, I am aware of another new and up-to-date training program for which there is a lot of evidence of uptake and use at [1], described on meta at meta:Programs & Events Dashboard. I know that site is off-wiki but it is in the Wikimedia network and has advantages including tracking when a user completes the training and of being part of an interface which wiki event organizers present to 1000s of new users a year with a suggestion that they complete it. I am not saying that this off-ENWP training should replace on-ENWP resources, but probably over the past few years it has been the training with the most use and uptake, and also competes with other options for what content experienced Wiki editors present to new users. I would like to stay flexible about what wiki training means, because we have no consensus on what is best for new users. I am persuaded that we should start the wind-down process for these older tutorials. Blue Rasberry (talk) 21:59, 23 February 2018 (UTC)[reply]
We already use both Help:Getting started for new editors....this request is basically a delete request.--Moxy (talk) 21:46, 25 February 2018 (UTC)[reply]

Some comments on the points above In the interests of consensus building, I thought I should clarify what I think are some of the limitations of WP:I and WP:T. Whether WP:I and WP:T are updated or replaced, I think that these would be useful to address.

  1. Line length should be narrower to aid readability. This is optimally <75 characters, but certainly narrower than the average screen. Can be achieved through CSS max-width parameter in template. Although I'm not advocating style over substance, bits of Wikipedia can look pretty dated, and a style update may improve this corner a bit.
  2. are overused in the headings.
  3. If both Markup and VE are taught together, I think that introducing VE first in each page makes more sense for new users.
  4. The first tab of WP:I is pretty good. I think that the intro should be pitched at a reader who is considering editing but still unsure. It should therefore emphasise how Wikipedia works and
  5. The second tab of WP:I largely overlaps with the final wrap-up, and could sensibly be merged there.
  6. Similarly, the third tab of WP:I includes info on how to navigate Wikipedia, and could be left until later in the series, probably merged into the Wrapup. The final two links of "Find out more" don't need to be in a separate style (italic sentence).
  7. The final tab of WP:I redirects to the first tab of WP:T, but tab is still titled "Introduction". Content ok, but a little verbose?
  8. WP:Tutorial/Editing introduces VE briefly in the first section, then almost repeats itself in the final section. These could be merged. If both systems are presented together, there should be some info on how to switch between. It also uses "Main page:", "For more information" and "For more details" in its links to other pages.
  9. WP:Tutorial/Formatting includes how to use HTML to custom format paragraphs. This is pretty uncommon, and probably not something for a new editor. The markup toolbar is explained in detail but the VE toolbar omitted.
  10. WP:Tutorial/Wikipedia links doesn't mention VE at all in this case, but otherwise ok
  11. WP:Tutorial/Citing_sources demonstrates how to add plain references inside <ref> tags before . In reality most references are encouraged to be CS1 these days. Explaining {{Reflist}} or <references/> is also a bit unnecessary since even if they are omitted, references are still shown, and adding them is better left to wikignomes.
  12. WP:Tutorial/Talk pages is ok, though perhaps a bit long. Three-tilde and five-tilde don't really need to be explained here. Example markup is better shown side-by-side (e.g. here).
  13. WP:Tutorial/Registration is probably too long. This is already mentioned way back on the third tab of WP:I and could probably be left at that initial detail level with a link for people interested in the pros and cons.

These are only my opinions, and perhaps people will agree with some of these and not others, but I hope they can help the discussion. They can also be copied to a relevant talk page if necessary. T.Shafee(Evo&Evo)talk 12:12, 22 February 2018 (UTC)[reply]

OK I will work on these....because I don't have the time to fix the new pages. Really wish we has more experienced help people looking at this.--Moxy (talk) 22:47, 22 February 2018 (UTC)[reply]
 Done have made changes to WP:Tutorial as per above ...but not number 13 as the intro and tutorial are seen separately. The intro and tutorial are not the same..they are automated links for 2 sets of bots for different readers. .--Moxy (talk) 16:19, 25 February 2018 (UTC)[reply]
Pinging User:MKramer (WMF) and the ever-awesome User:John Broughton. Whatamidoing (WMF) (talk) 19:37, 23 February 2018 (UTC)[reply]
I'm happy to help out with updates to the wp:t series. I'll try to incorporate the sentiments and opinions voiced in this thread and try to implement what I think are some of the strengths of the help:intro series. Anyone still following this discussion: Let me know if there are any elements in the list of suggestions that I made above that you particularly disagree with! I agree that keeping it short is important, and as well as ensuring that it's mobile-friendly, and I acknowledge that those are limitations of help:intro. T.Shafee(Evo&Evo)talk 08:06, 28 February 2018 (UTC)[reply]
I don't know if I'd go so far as to call it unready for prime time. I think it's pretty functional for most new editors, especially those looking to contribute content, references and images. The only thing in the tutorial that it clearly fails on is talk page editing. T.Shafee(Evo&Evo)talk 02:30, 2 March 2018 (UTC)[reply]

Aliases for arbitration cases

Following up on the discussion at Wikipedia talk:Arbitration Committee/Noticeboard/Archive 36#Community feedback: Proposal on case naming, I created a proof-of-concept template to create aliases for the cases opened in 2017 and 2018. Please see Wikipedia talk:Arbitration/Requests#Aliases for arbitration cases for more details. isaacl (talk) 02:28, 21 February 2018 (UTC)[reply]

Budget for games and changes in the representation for film budgets

Hi everyone, I have two suggestions. Should we show budget in the wikis for computer games? This is already done in the film wikis.

Also, should have a special entry for marketing costs when talking about a film budget? For example it might say that a film budget is 25 mil. The box office might be 30 mil. A reader of this wiki might then believe that the made a profit of 5 mil. However, with film the marketing might very often be double of the budget. So, if a film budget is 25 mil + 25 mil marketing then you would have a loss of 30 mill. Not 5 mil. profit. Same could be done with computer games

Video game developers rarely have those figures published in reliable media. It is something we would like to include were it possible under the requirements of WP:RS. --Izno (talk) 12:10, 21 February 2018 (UTC)[reply]
couldn't these just be added into the respective infobox templates? Then if sourced information is found, it can be included. Nessie (talk) 14:41, 21 February 2018 (UTC)[reply]

Hi all thanks for replies suggestions. Is there an easy way to give for example all computer games a budget template? And yes I of course agree that the sources for these numbers should be reliable. Also, would eventualism be ok. I'm pretty confident that I can get reliable sources on the newer and bigger games for the older or smaller ones that might be a bit more difficult.

Template:Infobox video game (edit | talk | history | links | watch | logs) looks to be the one to edit. If you aren't sure how, ask on the talk page. Nessie (talk) 14:06, 24 February 2018 (UTC)[reply]

RFC: Autopopulate Category:Infobox templates when we can

tl;dr version: I propose that we change Category:Infobox templates to a {{all included}}/{{tracking category}}, and get all the benefits this would entail.

Current situation/Proposed solution

Currently Category:Infobox templates is setup as a {{container category}} [with a handful of infoboxes which are mistakenly in the category], which is pretty much completely useless. Infoboxes are sub-categorized in an extremely incomplete way, so finding anything is almost impossible simply because this scheme is pretty much ignored, on top of just badly designed in general. Try to find something like {{Infobox journal}} from the main category, and you'll be spending a long time browsing things before realizing it's located in

or

And that's when it's categorized in the first place. You can't get to {{Infobox ABL team}}, because it's not categorized.

So to fix/improve this situation, I propose that we change Category:Infobox templates to a {{all included}}/{{tracking category}}. This would have several benefits, such as (non-exhaustive list):

The category could be automatically populated and correctly sorted by the {{Infobox}} template itself (and other similar templates) in the vast majority of cases (at the very least anything that starts with Template:Infobox foobar can be), with the rest being manually categorized. This wouldn't change the subcategory system, so editors could still find {{Infobox element}} via

if they prefer browsing that way. Headbomb {t · c · p · b} 12:43, 21 February 2018 (UTC)[reply]

!Vote (Infobox categorization)

As the preliminary talkpage discussions show, this example originated with "automation", not with "redefinition". A pity that has not been corrected now, though I must say some early incidental issues are addressed.
* 'Cornercase' examples are, each from a different reason/origin (i.e. each example here represents a single issue): {{Taxobox}}, {{Chembox}}, {{Infobox3cols}}, Wikipedia:Manual of Style/Infoboxes, {{PBB/2239}}, {{Outline header}}, {{Infobox Wikipedia user/sandbox}}, {{Infobox drug/licence}} . - DePiep (talk) 12:30, 25 February 2018 (UTC)[reply]
As explained above, not everything with the infobox class is an infobox, so that's why the proposal says all infoboxes, rather than all templates with a class=infobox in them somewhere. As for your cornercases, this has also been explained above. Those can be handled by adding [[Category:Infobox templates]] manually to the templates (or subpages) when appropriate. Headbomb {t · c · p · b} 23:09, 25 February 2018 (UTC)[reply]
Then what does define something being an infobox? Also, not all "cornercases" are solved above (and let's keep in mind that 'cornercases' are not exceptions. They may constitute 50% of all infoboxes. -DePiep (talk) 11:40, 26 February 2018 (UTC)[reply]
See WP:INFOBOX. Headbomb {t · c · p · b} 12:14, 26 February 2018 (UTC)[reply]
Self-contradicting: WP:INFOBOX is about articles, so off-mainspace boxes are not infoboxes by definition (etcetera: as I predicted, now all the 'cornercases' must be handled on a one-by-one argument). This knot tying could be prevented by first defining what infoboxes should be categorised. Also, still no answer on how the subcategory contents will be treated. (BTW the pattern of reasoning in this topic is this: A. Some statement is made, B. I point to a problematic issue, C. Reply: no that is not an issue and it would be solved in such and such way.) - DePiep (talk) 20:51, 26 February 2018 (UTC)[reply]
At this point, you're clearly trolling. WP:INFOBOX is about infoboxes, not articles. To quote "An infobox is a panel, usually in the top right of an article, next to the lead section (in the desktop version of Wikipedia), or at the end of the lead section of an article (in the mobile version), that summarizes key features of the page's subject." Concerning "no answer on how the subcategory contents will be treated", that's covered by "This wouldn't change the subcategory system" above, and "All other categories would remain unchanged" below. Start making sense or go away. Headbomb {t · c · p · b} 22:10, 26 February 2018 (UTC)[reply]
Another example. The OP says: "[with a handful of infoboxes which are mistakenly in the category]". Clearly, that is changing the definition of this category, you still don't want to acknowledge. All in all I listed eight different situations, each one is stumbling to an "explanation" that does not hold. - DePiep (talk) 11:00, 27 February 2018 (UTC)[reply]
Refuse to acknowledge? That's what the entire proposal is about. Changing Category:Infobox templates from a container category to a category that contains all infoboxes. Headbomb {t · c · p · b} 12:19, 27 February 2018 (UTC)[reply]
Make this a Permanent objection. The nom has shown no intention of improving the proposal after having been pointed to major design flaws. Also I listed some eight exception situations, and have to pull for each and every reply which then turns out to be "people know", assuming obviousness, contradiction, et ecetera — instead of creating a sound base. - DePiep (talk) 11:00, 27 February 2018 (UTC)[reply]
  • Support DePiep seems to be knowledgeable about cases where the general rule will not apply and those cases do merit extra and unusual attention. However, to the extent of my understanding, the general proposal made here does apply to many cases, and its implementation would usually bring improvement. It seems reasonable to enact this on a scale of 100s of infoboxes. Blue Rasberry (talk) 00:42, 26 February 2018 (UTC)[reply]
One of the arguments is that single-category listing is useful in automated tracking. Still no effort is made or proposed to include all infoboxes systematically. There is only one single automation proposal, the rest is left alone (both pages to include, and pages to exclude). The cornercases I mentioned do represent an uncovered issue each. Instead of implicitly assuming a dozen solutions ("what do we do with /sandboxes?"), the principled solution is to define 'what is an infobox to be categorised'. Also, omitting a sound category definition increases the chaos between the top-category and it's current subcategories. That is hardly an improvement. - DePiep (talk) 11:40, 26 February 2018 (UTC)[reply]
That's mostly because people know what infoboxes are, and are well aware that sandboxes aren't to be categorized in the main category, much like drafts are to be excluded in mainspace categories. Headbomb {t · c · p · b} 12:17, 26 February 2018 (UTC)[reply]
Replied under previous bullet. - DePiep (talk) 20:51, 26 February 2018 (UTC)[reply]
re people know what infoboxes are - apparently that knowledge differs. For example, it differs between you and me, and between template forms. In general, "people know" is not a strong base for a definition (category redefinition in this case). Also, I mentioned eight non-standard situations, about none of which have been answered wrt category definition. - DePiep (talk) 11:12, 27 February 2018 (UTC)[reply]
It only seems to differs between you and the rest of Wikipedians. If you don't know what an infobox is, then you should probably avoid commenting on them until you learn what they are. None of your 'non-standard' situations cause any issues with this proposal. {{Taxobox}}, {{Chembox}}, {{PBB/2239}}, are infoboxes and would be categorized and sorted accordingly. {{Outline header}} seems to be a navbox and would probably not be categorized (it's unused anyway, so it could probably simply be deleted). But if the community deems it an infobox, then it would be categorized. {{Infobox Wikipedia user/sandbox}} is a sandbox and would not be categorized (although {{Infobox Wikipedia user}} would be). {{Infobox3cols}} is an infobox metatemplate like {{infobox}} is and would get the same sort of update as {{infobox}} and would remain categorized as it currently is (at the top of the category). {{Infobox drug/licence}} is a sub-template used by an infobox and would not be categorized. WP:Manual of Style/Infoboxes is a style guideline about infoboxes, and while not an infobox itself, it is part of a small set of core guidelines related to infoboxes, and would remain categorized as it currently is (at the top of the category, along other similar pages). This is obvious to everyone but you. Headbomb {t · c · p · b} 12:02, 27 February 2018 (UTC)[reply]

Discussion (Infobox categorization)

Why would that be better? We have an existing category. There's no downside to using that one and making it useful. Headbomb {t · c · p · b} 22:39, 23 February 2018 (UTC)[reply]
@Bluerasberry: Not quite sure what's asked here exactly. The only thing different would be that {{Infobox journal}} would be categorized in Category:Infobox templates, sorted under 'Journal'. All other categories would remain unchanged. Headbomb {t · c · p · b}
@Headbomb: I am asking for you to talk through changes to {{Infobox journal}} as an example. You seem to be proposing to add [[Category:Infobox templates|Journal]] to {{Infobox journal}}, right? Blue Rasberry (talk) 23:13, 23 February 2018 (UTC)[reply]
@Bluerasberry: No, that would be done by {{Infobox}} automatically. No edits would be needed to {{Infobox journal}}. Headbomb {t · c · p · b} 23:19, 23 February 2018 (UTC)[reply]
@Headbomb:, Okay, so you will not add that category directly, but the change you are proposing will indirectly put that article into that category, correct? Blue Rasberry (talk) 23:21, 23 February 2018 (UTC)[reply]
Correct. There will be some corner cases that will need to be handled manually, but those are minority.Headbomb {t · c · p · b} 23:24, 23 February 2018 (UTC)[reply]
@Headbomb: Okay, and in general, the sorting will be of the format "Infobox Whatever", which is the name of the template minus the word "infobox", right? And you are saying that the minority of manual cases will be the ones which for whatever reason do not have that sort of typical name? Blue Rasberry (talk) 13:42, 24 February 2018 (UTC)[reply]
Pretty much, yup. Headbomb {t · c · p · b} 14:52, 24 February 2018 (UTC)[reply]
Thanks. Blue Rasberry (talk) 00:42, 26 February 2018 (UTC)[reply]

A Bot for Creating Arthropod Stubs, Trial

The bot to make stub articles for arthropod species is coming along. It even has a name: Qbugbot. I've made a couple of thousand stub articles and manually posted them. Thanks for all the suggestions and edits! The articles now include Speciesbox and Automatic Taxobox, CS1 citation templates, and a taxonbar.

The first online trial was done today for the BRFA, creating and uploading the twenty random articles below. Everything worked fine, except for a minor bug that has been fixed (talk pages were blank for pages with images). Comments, questions, suggestions, and criticisms are welcome.

Bob Webster (talk) 03:22, 26 February 2018 (UTC)[reply]

Note: please see the original VPP discussion (now archived) for background.   ~ Tom.Reding (talk ⋅dgaf)  04:33, 26 February 2018 (UTC)[reply]
The bug in the template on the talk page can easily be eliminated if "needs-image=yes" is replaced by "needs-photo=yes". JoJan (talk) 15:38, 26 February 2018 (UTC)[reply]
JoJan, is this the correct location for your post? Feel free to remove this (my cmt) if so.   ~ Tom.Reding (talk ⋅dgaf)  14:58, 27 February 2018 (UTC)[reply]
  • Strongest possible oppose No, we should not become like the Cebuano Wikipedia and allow a bot to create up to 15,000 new articles. That is to be blunt, absolutely crazy and will prove next to impossible to quality control. We either grant the bot autopatrolled, which means that it doesn't flood the new pages feed, but means that there is no one reviewing the articles to see if there are issues that can be caused by an automated process (which will exists), or we don't grant it autopatrolled, meaning the new pages feed is flooded with new articles, and articles that might be much more problematic can't be found quickly because of these stubs. I also hate the precedent that this would set for bots to create other types of articles, maybe about living people (I'm sure you could write code for footballers or other sports people?). That the trial went well does not impact the major disruption that 15,000 bot created articles could cause to the English Wikipedia. As I'm saying in my edit summary, under no circumstances should this BFRA be approved. TonyBallioni (talk) 03:32, 26 February 2018 (UTC)[reply]
  • Conditional support Look, I can't support granting the bot autopatrolled (which is unnacceptable without explicit community approval, which I have not seen), and I also cannot countenance flooding the newpage feed with new arthropod stubs (NPP is struggling as it is). However, this bot is capable of creating quite good stub articles and I do want to find a way of accommodating them into the wiki if possible. At the moment I would say that the maximum number that NPP could deal with would be about 50 of these stubs a day. This would slowly release the stubs over almost a year or so, which is reasonable. Logistically it would be better if all the 50 articles for each day were posted at the same time (i.e. in one large block). If they don't have major issues, this should make patrolling them relatively trivial. Spacing them out evenly over the day would be bad, as it wouldn't make it as easy for a reviewer to get 'in the zone' of reviewing a particular type of article (which speeds things up a lot). Edibobb You have to coordinate with new page patrol on this as we are the group of editors impacted the most. So far you have managed to get on Tony's bad side by pushing ahead with this without reaching out to us. I'd suggest changing your approach by asking for suggestions at WT:NPR before moving ahead with anything else. My support is conditional on this bot project working closely with NPP, otherwise I am firmly in TonyBallioni's camp. — Insertcleverphrasehere (or here) 04:16, 26 February 2018 (UTC)[reply]
  • 50 a day would also be overwhelming. Mass articles about sports teams seasons or elections by years or villages in remote parts of the Middle East also flood the feed on occasion, and make it difficult to deal with, but at least those are done by people who we can eventually grant the autopatrolled flag to because we don't have to worry about some glitch creating a completely malformed article that no one will ever see (and even if they did, they would immediately recognize and fix it). Those also usually stop after a week or so, and are typically done 10-20 at a time, not 50 at a time. I know we have had automated creations in the past, but have we ever had anything on the scale of 15,000 stubs created by a bot that will eventually have no human review as to it's output (and from the proposal I see at BRFA, the suggestion is that the operator will review at least one article a day to make sure the bot isn't messing up, which is nothing).
    In terms of getting on my bad side, I don't mind not being reached out to, I just honestly find this idea terrifying as to the future implications it could have for Wikipedia. This could easily be replicated for BLPs as I mentioned above, and there are likely almost as many notable living footballers out there as there are bugs. This is a slippery slope argument, I'm aware, but I don't think people have a problem imagining how that could turn into a disaster fast. We have less risk with these stubs, but we're currently living in an environment re: bots where people get mad about a bot making whitespace edits because it shows up on a watchlist.
    That's just an annoyance thing. Do we really want to think about the large scale disruption and damage to the reputation of Wikipedia that could happen if somehow the bot started messing up the articles and they hit Google without someone catching them? Look at KolbertBot for a good bot that serves a much needed purpose to see how many people are mad about a bot that just changes http to https in links. An article creation bot could do so much more damage and would be likely to create articles that would never be expanded. I know I'm getting into tl;dr mode here, but the sheer potential for disruption here is huge on many different fronts. TonyBallioni (talk) 04:36, 26 February 2018 (UTC)[reply]
  • As far as whether this has happened before - this reminds me of User:ProteinBoxBot which created 10,000 or more gene stubs several years back (and appears to still be running). I'm sure the folks who run that bot would be happy to advise, both on technical issues they've encountered and on outreach issues with various editor groups they've encountered. Ajpolino (talk) 06:28, 26 February 2018 (UTC)[reply]
  • Thanks for that, much appreciated. It currently at a rate of a less than 10 on any given day that it runs. I would be fine with a bot that created 5-10 articles a day, max, which is what the protein bot seems to be doing now (though it used to create hundreds a day). I have no confidence in the ability to maintain the 2-4 volunteers mentioned below to review even 50 articles a day.
    I suspect this goes one of two ways: it either creates inordinate amounts of disruption that requires the bot to be blocked and not unblocked at some point, or it creates a major mess that no one wants to clean up so everyone just ignores because no one really visits one line bug stubs, and we already have backlogs in the six figures in article space, so no reason to focus on these (mostly high quality), stubs. I don't see either as being good for Wikipedia. TonyBallioni (talk) 06:45, 26 February 2018 (UTC)[reply]
  • Continued support for the creation of a large number of high quality stubs. I don't see that the quality checking issue is anything to flip out over. We certainly want to avoid the two cases of a) either flooding NPP, or b) having a huge number of auto-patrolled stubs come in which have only been spot-checked. But a limited number of articles per day is perfectly realistic to deal with; specifically since it will amount to format and consistency verification only (no notability, COI, or copyright issues with these...). I'm positive that, for example, 50 articles a day could be handled without the least problem by 2-4 interested people who commit to checking these daily (for which I do volunteer). A committed small task force could be combined with auto-patrolled status so that the stubs don't add to the NPP lists. - As for axing a promising idea because it sets a "bad precedent", that way lays stagnation. Bug Stub Creation is not a suicide pact. --Elmidae (talk · contribs) 06:13, 26 February 2018 (UTC)[reply]
One technical comment: how much "Further reading" is desirable? Nothing inherently wrong with having lots of general bug books suggested for the reader's further perusal, it's just that I have rarely seen such large reading lists as in Kuschelina jacobiana in anything but particularly well-developed full-length articles. Actually, when encountering this in a random stub, I would assume indiscriminatory ref spamming, and trim it down (not that that's a suspicion here :). Is there a suggested limit to the length of that section? --Elmidae (talk · contribs) 06:15, 26 February 2018 (UTC)[reply]
I agree, there's a bit too much further reading in some pages, especially some of the Beetles. I did cut it a little, but it needs more reduction. I'll weed out some of the less important references.
I would also volunteer for stub verification, and I see no problem with a limit of 50 per day.
Bob Webster (talk) 07:01, 26 February 2018 (UTC)[reply]
Strong support at a reasonable pace. עוד מישהו Od Mishehu 08:34, 26 February 2018 (UTC)[reply]
  • If this bot is implemented, it needs an addition, or a companion bot, to create incoming redirects from common names (sometimes several per article). I see that there is now a redirect from Virgata toothpick grasshopper to Paropomala virgata, but it should have been created at the same time as the target stub (it's the common name, bolded in the stub). I also see that the same editor (@William Avery:) who added the necessary redirect also added Category:Insects described in 1899, which presumably could have been created automatically by using the date in the source in the infobox. If this bot is going to go ahead it needs to be as good as it can be - checking the edits made to all those 20 articles might be a useful source of enhancements to consider. PamD 08:46, 26 February 2018 (UTC)[reply]
  • Strong Oppose mass creation of bug stubs by a brainless bot is as bad as mass creation of sports bio stubs by human editors that don't use their brains. We already can't handle the normal creations at NPP. How about bot creating these into Draft space at a reasonable rate and then once a qualified human has checked them the human moves them to mainspace. By qualified human I mean someone who understands the topic and has NPP and pagemover flags to both approve the page and remove the redirect in Draft space. That way disinterested reviewers never see these pages in the feed. There is no good reason to saddle NPP generalist with Thousands of bot created bug pages. They will quit! Legacypac (talk) 08:57, 26 February 2018 (UTC)[reply]
I mean if it is approved the pages will obviously be autopatrolled Galobtter (pingó mió) 09:05, 26 February 2018 (UTC)[reply]
Legacypac, would you please read at least some of the preceeding material regarding NPP/autopatrolled etc. in this and the previous discussion? People are well aware of that issue, and no one is proposing bombing the NPP queues. --Elmidae (talk · contribs) 09:17, 26 February 2018 (UTC)[reply]
I read all the discussion and thought through the issues before posting. Sorry you think so poorly of me. I'm pretty familiar with NPP, AfC, Draft management, and dealing with mass created pages (I handled more Neelix creations than any other editor), and I've done huge cleanup in Draft and Userspace. I oppose putting these directly in mainspace without a qualified human checking them. I oppose any plan that puts thousands of bug stubs anywhere the NPP feed. I offer a constructive suggestion that allows the bot to run and satisfies the concerns I and others have. Perhaps a bot could even do batches of page moves after a human checks the batch? What is wrong with running them by a real human's eyes for a quick check? Legacypac (talk) 09:28, 26 February 2018 (UTC)[reply]
Also 15000 pages at 10 a day is over 4 years worth that NPP will need to deal with. Legacypac (talk) 09:34, 26 February 2018 (UTC)[reply]
Okay, sorry if that came off as thinking poorly of you (I certainly don't). Your comments seemed to start from a position of "this bot will dump 15k stubs into NPP", which I hope no one is advocating - multiple editors have identified that as insupportable. - Creating stubs into draft space at a certain rate and human-checking them before moving sounds good; indeed I wanted to suggest that as an alternative to "autopatrolled + task team", but didn't want to muddy the waters too much. --Elmidae (talk · contribs) 09:52, 26 February 2018 (UTC)[reply]
Many sportspeople are non-notable, which us the reason we don't want mass creation of sports bio stubs by human editors that don't use their brains; on the other hand, according to Wikipedia:Articles for deletion/Common outcomes, All species that have a correct name (botany) or valid name (zoology) are inherently notable. Their names and at least a brief description must have been published in a reliable academic publication to be recognized as correct or valid. This means that the bot's output is articles which are inherently notable, while the mindless humans would be outputting articles most of which are on non-notable topics. עוד מישהו Od Mishehu 12:45, 26 February 2018 (UTC)[reply]
Every footballer who has ever set foot in a fully professional league is notable. The slippery slope argument here is not nonsense, despite what has been claimed by a BAG member. This process could easily be replicated for the footballer stubs we see if someone wanted to. We need a reasonable review process for this, just as we would for the footballer scenario. BLPs are much more delicate, but any article not created by a human needs human review. TonyBallioni (talk) 13:41, 26 February 2018 (UTC)[reply]
  • Support Articles appear to be of reasonably good quality for stubs. Darylgolden(talk) Ping when replying 11:33, 26 February 2018 (UTC)[reply]
  • BAG note: The slippery slope 'Footballer's BLP stubs' argument is nonsense. Any bot that wants to create articles on a large scale needs to follow WP:MASSCREATION. If you oppose a bot creating BLP stubs on footballers, then oppose that bot, don't transfer your opposition to a bot that creates non-BLPs stubs about species of bugs. Headbomb {t · c · p · b} 11:36, 26 February 2018 (UTC)[reply]
  • Strong support Issues are taken care of. Agathoclea (talk) 12:04, 26 February 2018 (UTC)[reply]
  • Conditional support as long as throttling controls are in place to not overwhelm quality control processes, I'm fine with allowing an automated process to handle these. --Jayron32 12:50, 26 February 2018 (UTC)[reply]
  • Support Legacypac’s alternative I would support Legacypac’s alternative of allowing the bot to create these in draft space as an alternative to the suggested 50/day+task force model, which I think would not be sustainable in the long run (the bot will keep running, but people will stop reviewing, and the task force will review far less than 50 a day even at the beginning when no one has burned out.)
    @Elmidae and Edibobb: does a throttled draftspace bot make any sense to you all? This also has the advantage over autopatrolled because we could grant the bot/reviewers autopatrolled or NPR do these don’t overwhelm the feed. Granting autopatrolled for mainspace would be a concern as it would instantly Google index these without human review. Granting it for drafts would not have this concern. TonyBallioni (talk) 13:41, 26 February 2018 (UTC)[reply]
Seems workable; provided I understand from the above (not quite clear to me) that there is a way to shortcut the process of "check + move + review" by chopping off the review bit, or rather the ending-up-in-NPP-queue bit. I actually don't know whether moving out of draft space un-reviews - if so, then that could not be solved by just AP'ing the bot, and it would have to be AP for the reviewers? --Elmidae (talk · contribs) 14:05, 26 February 2018 (UTC)[reply]
Moving out of draftspace to mainspace adds it to the feed, but I'm not clear on the details as to if it is the status of the creator or the reviewer that marks it unpatrolled (Xaosflux might know sorry for the ping it's one of the few technical areas of NPP that I'm unsure of). Either way, it's easy to sort out. The software does not prevent a reviewer from marking something they have moved to mainspace as reviewed, so worse case scenario, we just give the NPR flag, and they manually mark as reviewed in mainspace. It'll be easy to do once we figure out exactly what marks something coming from draft as unreviewed. TonyBallioni (talk) 14:11, 26 February 2018 (UTC)[reply]
Elmidae see this thread on my talk by Xaosflux. All we'd have to do in this scenario would be to grant the reviewers autopatrolled (which if they are experienced editors who are working on this project, I'm sure we would). Also (as I just learned all bots get autopatrolled, which I Was not aware until talking with him), I really think the draft space plan is the way to go here: it is the only way that will ensure human review of the articles before they are indexed. TonyBallioni (talk) 15:04, 26 February 2018 (UTC)[reply]
I think a throttled draftspace would make some people more comfortable with this project. As you point out, it would definitely reduce the impact of any mistakes generated by the bot. A consideration is the human time involved moving articles from draftspace to mainspace. One way to do this efficiently is for the bot to periodically move any articles that have been human-verified from draftspace to mainspace. If the bot has autopatrol status, all would be finished when the article is moved. This would not impact the NPP queue, but would still require each article to be checked by a human. Bob Webster (talk) 15:49, 26 February 2018 (UTC)[reply]
Thanks Tony; that does indeed sound promising. Bob, as for the effort involved in moving: it's like three clicks, I think, possibly less if by Twinkle or similar - I doubt there would be any big savings in having some kind of alternative "verify" mechanism (which would also require some kind of logging action on part of the reviewer, presumably more complex) followed by bot move. Or so I assume. --Elmidae (talk · contribs) 16:36, 26 February 2018 (UTC)[reply]
@Elmidae and TonyBallioni: Yes. I had also forgotten about the bots having a-pat status. The "bot > draftspace - a-pat reviewr > mainspace" seems to be our best option yet. But I wonder how many of our editors are familiar with bugs. I have rudimentary knowledge of entomology (it was me who nominate Bob for A-PAT), the only reason I dont study/read entomology is that most of the photos give me heebie-jeebies. To the point: we need volunteers who could be trusted with A-PAT, and are willing to perform this reviewing/moving thing. —usernamekiran(talk) 00:21, 27 February 2018 (UTC)[reply]
  • Conditionally support Every species is notable and deserves its own article. The stub articles created by this bot have a certain quality and should be accepted in NPPP. However their large number creates an understandable problem for NPP. The solution is to find a way to accept them as autopatrolled AND keep them from appearing in the New Pages. There is however another problem that hasn't been raised yet: the taxonomy in every branch of the Tree of Life is changing rapidly: new species are discovered all the time and also many species become synonyms. These changes happen in such a fast succession, that it is almost impossible for anyone to keep up. Therefore this bot actually needs a second bot to list all these changes in a list that the collaborators, working on the beetles and other families, can use to redirect the existing articles of species to their new names. This way, the bot-created articles can remain up-to-date. JoJan (talk) 16:09, 26 February 2018 (UTC)[reply]
  • Conditionally support The blocker on this seems to be getting them patrolled. Is there a way to tag those which are patrolled, and throttling the bot to allow only a limited number of unpatrolled articles?, maybe 50 unpatrolled stops the bot, and it starts again when the number drops below 40. That way there can be as many created as the patrollers choose to check, and if they stop, so does creation of articles until they start again. There would never be more than a specified number of unpatrolled articles.
  • I would also request that the bot creates Wikipedia:Short description for all articles too, as they will need them, and this should be a trivial addition, · · · Peter (Southwood) (talk): 18:40, 26 February 2018 (UTC)[reply]
  • Perhaps I used the wrong terminology. There seems to be a concern that the articles should be checked by a human editor, which is what I was trying to express. A template identifying the article as human-verified with default as not verified (F) could do this. By using an F or T it would be very quick to verify after checking, and could bypass the NPP completely. I am in favour of stubs for all species, as there have been many occasions that I would have added a bit to an existing article, but did not have the time or inclination to create the article first.
  • JoJan also makes a good point about names changing and using a bot to keep them updated. · · · Peter (Southwood) (talk): 19:49, 26 February 2018 (UTC)[reply]
  • Support I think this is fine; I followed the earlier VPP discussion and am satisfied by the quality of the articles. I am of the belief that stubs will eventually get expanded. I find the comparison with the Cebuano Wikipedia to be disingenuous; 95% of their articles are autogenerated stubs on living organisms, I don't believe this trial is aiming to make 95% of our articles Arthropod stubs. jcc (tea and biscuits) 18:47, 26 February 2018 (UTC)[reply]

So if the autopatroled bot creates the page in mainspace it does not hit the NPP list and we have no way to know if a human looked at it and it will be immediately indexed? Too scary. If the autopatroled bot creats in Draft and an autopatrolled human moves it to mainspace we know a human checked it and its indexed only on move to mainspace. Much better. Moves are easy - not harder thsn reviewing the pages and somehow recording that page is human reviewed. Legacypac (talk) 19:47, 26 February 2018 (UTC)[reply]

@Legacypac: it only marks it as patrolled, it does not hide it from the feed - now yes, most people don't re-review patrolled new pages, but they could if they wanted to. An example of another bot that is creating new pages directly as articles is User:ProteinBoxBot (see Its created pages). — xaosflux Talk 20:03, 26 February 2018 (UTC)[reply]
  • Support - I think the examples are more than stubs (though labeling them as stubs will push them towards expansion). I sympathize with the page patrollers getting overworked. perhaps the page creations by the bot can be throttled to an acceptable level? or can there be a 'semi-patrolled' status set up so these articles take a lower priority from the standard page creations, but aren't completely autopatrolled? Nessie (talk) 20:35, 26 February 2018 (UTC)[reply]
  •  Comment: I think NPP/R folks should be given a little time (at least 72 hours) to discuss this issue before the bot is given a green signal. The community should wait for a official statement from NPP/R, as they are the (only?) ones who are working with deadlines related to external search engines. This incident would impact on their activity directly, as it is their task to make sure if an article is good enough for mainspace. On a completely different note: a lot of photos from entemology give me heebie-jeebies. —usernamekiran(talk) 00:05, 27 February 2018 (UTC)[reply]
  • Continued conditional support - Bob Webster, I had to perform author enumeration on 12/20 (60%) of the test articles (1 2 3 4 5 6 7 8 9 10 11 12). Also worth noting that on my 12th edit, I noticed |author8=Prendini, L., Ra, which seems like it chopped off the next author name? Can you incorporate these changes (not just with these authors, but all potential sources)? I recall you linked me to your 'master reference list' of sorts - would it help if I corrected that?   ~ Tom.Reding (talk ⋅dgaf)  14:54, 27 February 2018 (UTC)[reply]
Thanks for pointing that out. I'll take care of that, hopefully today. There are currently 162 out of 2000+ references without enumerated authors. These are the ones that got kicked out of the conversion from freeform for inconsistent or ambiguous format. I guess if you average 8-10 references per article, one of these should show up in the neighborhood of 60% of the time. I'll also do some validity checking to find incorrect names. These are all in a database, so it probably wouldn't be worthwhile to edit the list I put online. Bob Webster (talk) 15:32, 27 February 2018 (UTC)[reply]
  • Oppose mass creation outside of draftspace - To me creating these as drafts and having a human move them over makes the most sense - there are no articles that have not had a human touch them finding their way to Google, a quality control check is being done by people who presumably would notice if something is off with the content, and assuming the moves were done by someone with Autopatrolled, NPP would not be flooded. From a human factors point of view there would be no throttling required as the moves to mainspace could happen at whatever rate the people working on it wished to go. PGWG (talk) 19:15, 27 February 2018 (UTC)[reply]
  • Support running the bot and giving it the autopatrolled flag. This is a sensible use of a bot and I think the stubs it creates will be a net improvement to the encyclopaedia. I understand the concerns of my fellow new page patrollers, but I'm willing to trust the bot operator to do their own quality control, as outlined in their earlier village pump proposal. If it screws up, the bot can presumably mass-fix or mass-delete the articles just as easily as it created them. – Joe (talk) 09:39, 28 February 2018 (UTC)[reply]
  • Conditional support My gut feeling was 'no way', but as long as the bot is throttled and/or puts it in draft space. !dave 13:02, 28 February 2018 (UTC)[reply]
  • Strong support would be great improvement to Wikipedia. As an Inclusionist, I believe stubs are better than nothing, and that over time they will be improved. Whoever searches these articles will be happy to find something, even a stub. I also suppot giving the bot the autopatrolled flag. L293D (☎ • ✎) 15:18, 28 February 2018 (UTC)[reply]
  • Strong support: I see no problem with the created content, let's get coverage of these missing subjects. The concerns about crappy stub mass creation are overblown--this is clearly good work. FACE WITH TEARS OF JOY [u+1F602] 15:46, 28 February 2018 (UTC)[reply]
  • information Administrator note All bots are already "autopatrolled" - it is built in to their access bundle. If these pages are created in (Main/Article) the pages will already be "patrolled" - if it is created in Draft it will also already be patrolled. When a page is moved from Draft to Main its patrol status as an article is inherited from the person who moves it. — xaosflux Talk 16:26, 28 February 2018 (UTC)[reply]
  • Support' the bug bot, provided it takes it nice and slow. My spidey NPP senses say it will be alright L3X1 ◊distænt write◊ 20:43, 28 February 2018 (UTC)[reply]
  • Support I don't see any problem with these articles, and concerns about flooding Wikipedia with bot-created articles are overblown given the sheer number of articles we have already. It doesn't make any sense not to give it the autopatrolled flag, that would only waste NPP time and unlike humans we do have a reasonable guarantee that the bot won't create anything inappropriate. Hut 8.5 21:34, 28 February 2018 (UTC)[reply]
  • Support I don't quite understand the argument against auto-patrolled, but I think that NPP could handle 50-100 of these per day. It can't be worse than the stream of articles on football players we already get. There's no dispute regarding their notability, and most of the difficult cases in NPP involve assessing notability. power~enwiki (π, ν) 22:30, 28 February 2018 (UTC)[reply]
  • User:Edibobb This is really cool! How are the further reading lists generated? (Thinking about copyright issues here...) Thanks, Calliopejen1 (talk) 23:23, 28 February 2018 (UTC)[reply]
There is a big list of citations, and a few of these are applied to each article based on the scientific name of the bug. For example, Cerotainiops abdominalis is a robber fly, so the article "Robber flies of the world" is used for that (and other robber flies). The list of citations came from a number of sources such as ITIS, Google Scholar, Zookeys, and Crossref.org. Bob Webster (talk) 23:47, 28 February 2018 (UTC)[reply]
  • Support including autopatrolled. These stubs seem like an excellent addition to the encyclopedia, and IMO it is better to build standardized scaffolding for human editors to build on. Assuming this process occurs at a reasonable rate that allows for human spot-checking, these articles seem significantly less likely to contain errors than stubs created by human editors. Calliopejen1 (talk) 00:08, 1 March 2018 (UTC)[reply]
  • Support. The proposer appears to be handling this very carefully, has discussed the proposal widely with subject-matter specialists, is very responsive to feedback, and has provided high-quality examples. We should be going beyond the knee-jerk reaction 'all bot-created articles are by definition bad', and encouraging well-thought-out projects of this type. MichaelMaggs (talk) 13:08, 1 March 2018 (UTC)[reply]
  • Support creating these directly in the mainspace. I oppose dumping them in draftspace, and double-extra-oppose putting them there for the purpose of protecting the NPPers at the direct expense of the already-struggling AFC folks. We do not serve our mission by hiding decent content in the draftspace, and we do not help the community by letting one group of volunteers shift work onto another group of volunteers. These should be auto-patrolled when created, because all of them already pass the NPP threshold: they are 100% about notable subjects, they do not qualify for any form of deletion, speedy or otherwise. Sure, it'd be nice to glance at them to make sure that there isn't a stray typo mangling the wikitext formatting, but (a) that's what normal editing is for, and (b) there is no reason for this to end up in anybody's backlog. WhatamIdoing (talk) 04:41, 2 March 2018 (UTC)[reply]
@WhatamIdoing: I don't think anyone is suggesting that they be submitted to AfC. If they're created in draftspace, the idea is that Edibobb and/or other editors interested in this subject check and move them themselves. – Joe (talk) 13:31, 2 March 2018 (UTC)[reply]
  • Neutral: I don't care if its humans, bots, or monkeys on typewriters that create articles as long as the topics are notable and core content policies are followed. But since we are dealing with a bot and not monkeys, we are able to program it to produce the best possible result, every time. I have observed the following shortcomings:
  1. General references: some of these include sources in the reference section that are not footnoted, so it remains entirely ambigious as to what (if anything) they support in the article. (e.g. Acmaeodera decipiens)
  2. Unreferenced infobox fields: out of the infobox fields, synonyms and status have parameters for references (see template doc). These are intended to be used (high quality taxa articles do), so why isn't that the case here? (e.g. Acmaeodera decipiens, Cannaphila insularis)
  3. The Species, Subspecies, and Genera sections: I think you should include all the relevant information you have in these sections, and not just in the lead. This contributes towards an actual article body/lead distinction and lets you have references where they should be. (e.g. Cerotainiops, see suggestion)
  4. Images: I suppose there is no way of guaranteeing that the images added by the bot are actually variable enough to add anything of use. I notice some missing captions though. Perhaps make the bot repeat the article title if all else fails. (e.g. Amblytylus nasutus)
  5. Box-type Commons templates should be "at the beginning of the last section of the article [...] so that boxes will appear next to, rather than below, the list items". Yours are neither. Because these articles tend to have long infoboxes, you could place the Commons template in the External links section and use the inline version, as recommended by the linked guideline. (e.g. Acmaeodera decipiens)
Bob Webster, can you look into these issues and I might switch to support. By the way, I think you have done an incredible job with responding to questions and suggestions. I think, thanks to your effort, this bot has more "brains" than some human (monkey?) stub-creators that I have been unable to communicate with. Cheers. – Finnusertop (talk ⋅ contribs) 17:32, 2 March 2018 (UTC)[reply]
I'm not convinced that including captions that repeat the title of the article is worthwhile. Template:Taxobox#Images says "A caption need not be provided if it would just repeat the title of the article." In organisms without a common name, the binomial already shows up at the top of the infobox, in abbreviated form in the species line, and again in the binomial line. Plantdrew (talk) 20:00, 2 March 2018 (UTC)[reply]

April 1st... Wikipedia as Viewdata (Page 100 for Main Page?)

Withdrawn by proposer. power~enwiki (π, ν) 22:31, 28 February 2018 (UTC)[reply]

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.

As many people here know, there are ocassional April 1st items posted on English Wikipedia,

However, this year I was wanting to ask if there would be any interest in doing something a little unusual.

During the 1980's in the United Kingdom there was a viewdata system called Prestel, which used a presentation

format not dissimilar to the Teletext system used by the BBC's "over the air" CEEFAX.

I'd be interested for April 1st to see what English Wikipedia might have looked like as a viewdata based system c. 1988.

I've posted a similar proposal on French Wikipedia (although for obvious reasons the basis system would be the french TeleTel/Minitel)

It would need a moderate amount of technical effort, as currently Commons doesn't necessarily support a view for the Teletext frame formats the GPL frame editor I found supports.

ShakespeareFan00 (talk) 10:59, 27 February 2018 (UTC)[reply]

  • I like it. The old "Lets post funny but true stuff" on April Fools is getting a bit old. Something fresh and different is welcome here. --Jayron32 13:00, 27 February 2018 (UTC)[reply]
  • If I am reading this right, the proposal is essentially a new skin that is then enabled by default on April 1st? To even be considered it would need a level of polish that might not be possible in just a month and a half, and would definitely need a big 'off' button clearly visible to users as well. There is also mobile to think about, etc. — Insertcleverphrasehere (or here) 13:30, 27 February 2018 (UTC)[reply]
Not necessarily a new skin, but development of derived content, given the 40x24 layout and numeric linking approach (Ceefax used 100-999 whereas prestel used a 32bit number range IIRC. Not sure how those would translate on wiki (article title or id-hashes maybe?) 13:53, 27 February 2018 (UTC)
There's a font called Bedstead which emulates the old style teletext font - http://bjh21.me.uk/bedstead/ , there are also some online frame editors, but I'm not sure of the license details.ShakespeareFan00 (talk) 13:53, 27 February 2018 (UTC)[reply]
A monospace font? --NaBUru38 (talk) 18:28, 27 February 2018 (UTC)[reply]
The font is monospaced. but see below.19:19, 27 February 2018 (UTC)
  • Strongly oppose. It took years to get rid of the idea that Wikipedia should celebrate April Fools Day and to see off the "strange but true" folks (except on DYK, where they're still grimly hanging on); we don't need yet another pack of self-appointed comedians. Wikipedia exists as a service to its readers, not for its editors to slap each other on the back about who can be the biggest smartass. Aside from anything else, if you're planning to impose a 40X24 character layout, you'll need to persuade the people who run all the existing elements of the main page to withdraw; I can't imagine someone who's spent years bringing an article up to FA standard, and is hoping to run it on 1 April because that's a significant anniversary (and there is currently a backlog of 6 articles waiting to run on this date at Wikipedia:Featured articles that haven't been on the Main Page/Date connection) is likely to be very impressed. ‑ Iridescent 18:38, 27 February 2018 (UTC)[reply]
This was not intended to replace the current Main Page on April 1st. It would be parallel content.ShakespeareFan00 (talk) 19:13, 27 February 2018 (UTC)[reply]
It seems there's little interest in this, Abandoned due to the reasoning stated above. ShakespeareFan00 (talk) 19:19, 27 February 2018 (UTC)[reply]
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.

RFC here, please join -> MediaWiki_talk:Wdsearch.js#Add_link_to_search. --Superchilum(talk to me!) 10:50, 28 February 2018 (UTC)[reply]

Turn off extended edit summaries

Today the edit summary limit was extended from 250ish to 1000. Apparently this was a request from dewiki on the Community Wishlist. See phab:T6714 for one of the many phab requests about it. This is a prime example of the potential problems with this. It will do nothing more than cause massive disruption in the histories of numerous pages. For that reason I'm putting this to the community.

Should enwiki request that the old edit summary limit be put back on this project? --Majora (talk) 23:51, 1 March 2018 (UTC)[reply]

Survey

Noting I'd also be happy with Legoktm's solution. -- Begoon 09:33, 2 March 2018 (UTC)[reply]
  • Support Don't solve something that was never a problem.--v/r - TP 02:46, 2 March 2018 (UTC)[reply]
  • Support TonyBallioni (talk) 02:48, 2 March 2018 (UTC)[reply]
  • Support If you can't say it in 255 characters you should be pointing to a talk page. However, sometimes the preloaded stuff doesn't leave you enough space. Britmax (talk) 12:02, 2 March 2018 (UTC)[reply]
  • I prefer edit summaries longer than 255 character being available; often with section edits, a lot of space is taken up by the section heading, and when reverting edits from IPv6 editors, a lot of space is taken up by the boilerplate text. (I appreciate some suggest deleting this text to make room; I prefer keeping the standard text as an aid to those who are accustomed to it, and adding a brief summary afterwards.) A lower limit than 1000 would probably be suitable, though. isaacl (talk) 03:19, 2 March 2018 (UTC)[reply]
  • Oppose. Between unicode characters and IPv6 it's clearly a net improvement. The diffs provided indicate that the auto-summaries need tweaking to not include the full length of what was written. Something like "cut at the end of the first sentence" would solve this easily. FACE WITH TEARS OF JOY [u+1F602] 03:49, 2 March 2018 (UTC)[reply]
    • These aren't autosummaries. That's the problem. Some people are used to copying their entire comment into the edit summary on the assumption that it gets cut off. TonyBallioni (talk) 03:54, 2 March 2018 (UTC)[reply]
      • Ah gotcha, understood. Still: I think a few examples from before people were aware of the new behavior are not a big deal. People adapt when their environment changes :) FACE WITH TEARS OF JOY [u+1F602] 03:58, 2 March 2018 (UTC)[reply]
        • A "few" in the span of a few hours being turned on will turn into a massive mess as time goes on. These are, for all intents and purposes, permanent in page histories. While temporary, they also completely disrupt watchlists. This is nonsensical. I can understand that the Germans wanted this, you can have some crazy long sentences in German, but we didn't ask for this. We didn't ask for a 1,000 byte limit. --Majora (talk) 04:01, 2 March 2018 (UTC)[reply]
          • This is *NOT* a request just from the German community. If you look at phab:T6714 it goes all the way back to 2006! Even English Wikipedians wanted (and still want this). Legoktm (talk) 04:08, 2 March 2018 (UTC)[reply]
          • (ec) This has nothing to do with Germans, really...plenty of folks have commented on these tasks over quite a few years (including some enwiki users). Issues with poor display on watchlists and so forth can be cleaned up as time goes on (like a "expand full summary ->" link?). Nothing is perfect the first time, and I think the underlying change will ultimately be beneficial to folks. FACE WITH TEARS OF JOY [u+1F602] 04:12, 2 March 2018 (UTC)[reply]
  • Support We're barraged with text everywhere else, this is one place to the point writing is enforced. -- GreenC 03:51, 2 March 2018 (UTC)[reply]
  • Oppose There are plenty of places where the old limit was entirely problematic. Protection logs getting trimmed, rollbacks having broken links, and so on. Maybe we need a better way of displaying these, but lets not throw the baby out with the bathwater here. Legoktm (talk) 03:53, 2 March 2018 (UTC)[reply]
  • I'd agree with you for log entries and the like. Is there a way to adjust a setting locally so we can limit user generated edit summaries specifically? Killiondude (talk) 03:58, 2 March 2018 (UTC)[reply]
    No, that's not really a setting. It's still a problem when you undo an IPv6 user's (or someone with a longer username) edit and want to leave a rationale after it though. I put a proposal in the discussion section about how we could do truncation without losing the benefits of this change which I hope is a workable compromise. Legoktm (talk) 04:06, 2 March 2018 (UTC)[reply]
  • Oppose in favour of Legoktm/😂's proposal (see below), which is to truncate the display and add a clickable "..." (or similar) to reveal the rest of the summary. For this see phab:T6717. I don't know how long this would take to implement, but it's only JavaScript, so it can't be that hard.[citation needed] Worse comes to worse we can implement something ourselves here, but my bet is other Latin wikis will want the same. I wouldn't stress over it. A solution will be found. — MusikAnimal talk 04:27, 2 March 2018 (UTC)[reply]
  • Oppose cutting the limit back down - my god I'm glad that when reverting an IP edit, the entire span isn't taken up any more with monster-IPv6 user name + link to said monster-IPv6 talk page! Having a higher character limit is entirely welcome from my point of view. Implementing some dynamic truncation with option to reveal more content, as discussed below, might be a good option though. --Elmidae (talk · contribs) 06:58, 2 March 2018 (UTC)[reply]
  • Oppose cutting back to 255 per Legoktm, Elmidae et al. 1000 may be beyond reasonable needs, I prefer a reasonable number plus section name or username/talk page automatically generated content etc. Old length was often too short to put in a useful comment on top of the automatic stuff. A warning should come up when exceeding 255 characters and additional text could go on a highlighted background, or one could click to extend the summary box by say 255 characters at a time, yellow highlighting the first time, then orange, then red.· · · Peter (Southwood) (talk): 08:40, 2 March 2018 (UTC)[reply]
  • Oppose Long edit summaries can be truncated, per the above suggestion. Need to do something with IPv6 addresses as they may cause problems with being able to write a full comment. !dave 08:56, 2 March 2018 (UTC)[reply]
  • Oppose per above. Benefits clearly outweigh the drawbacks. Broken links in rollback summaries or log entries are confusing even to experienced users. -FASTILY 09:20, 2 March 2018 (UTC)[reply]
  • Oppose 255 characters is not enough for a summary when reverting a long IPv6 address edit. It doesn't need to be 1000 chars either though, maybe somethig in between. -- intgr [talk] 10:24, 2 March 2018 (UTC)[reply]
  • Oppose. Firstly, the opening statement in this RfC has obviously incorrect statements in it. This is not the result of "a request from dewiki", it was the #2 item from the 2016 Community Wishlist, and in fact had many users from the English Wikipedia voting in support of it. Secondly, the opening statement fails to actually describe the damage that is being caused by these longer edit summaries, other than that page histories can now be longer due to the longer edit summaries, which is merely different and is not actually damaging. Continued change aversion serves nobody. Let's wait and see how it works out, rather than rushing to turn the new things off simply because they're new. --Deskana (talk) 10:54, 2 March 2018 (UTC)[reply]
    • Comment: this was maybe the intent of developers, but it has no relation to #2 item from the 2016 Community Wishlist. We asked for 255 Cyrillic and other non-Latin symbols to be treated as 255 ASCII symbols, we got 7x increase in edit summary length. stjn[ru] 11:14, 2 March 2018 (UTC)[reply]
  • Oppose — Although, 1,000 characters may be more than one wants, 255 characters are in no shape or form enough. Also, per rationale provided by Deskana (talk · contribs) and 😂 (talk · contribs). No prejudice towards making the limit a bit reasonable — to say, 500-600 characters — though.
    Regards, SshibumXZ (Talk) (Contributions). 11:09, 2 March 2018 (UTC)[reply]
  • Oppose. I occasionally have to deal with copyright violations from multiple URLs and I find 255 characters goes pretty quickly. I support Legotm's solution. I'd also try to change editor behavior, but that's hard. MER-C 11:23, 2 March 2018 (UTC)[reply]
  • Oppose - looks like a useful change, having to shorten edit summaries to fit under the previous limit has been annoying on occasion. Thanks. Mike Peel (talk) 11:26, 2 March 2018 (UTC)[reply]
  • Cut the baby and make it 300-400 per SshibumXZ. Not too disruptive, not too limiting for long section headers. ~ Amory (u • t • c) 11:30, 2 March 2018 (UTC)[reply]
    Just to add, it's not clear to me why this happened. The "#2 on the request list" argument pretty clearly supports our Russian friend here that the request was for 255 characters. I get that with some characters taking 3 bytes, a byte limit of 750-1000 was likely the easiest solution, but it does seem to be counter to what was actually proposed and supported. ~ Amory (u • t • c) 15:37, 2 March 2018 (UTC)[reply]
  • Oppose. There's a common pattern here. WMF does something that improves experience for a substantial part of the movement (in this case, non-Latin-character-using projects). Someone notices this has a marginal impact on their personal experience. That person goes "OMG THIS IS AWFUL WHY WAS I NOT CONSULTED" and starts some kind of demand for the WMF to undo what they've just done. Then there is an unproductive conversation about whether this change is a good or bad idea, usually started without reference to the WMF's rationale for doing something in the first place, and with an unrealistic insistence that the WMF only do things when they have crafted something that works in an ideal way for everyone who might possibly have an opinion on the matter. Looking at the cost-benefit, I am quite happy to have longer edit summaries and more cluttered edit histories here, if that means the Russian Wikipedia and others can have edit summaries at a reasonable length. But maybe we should also look at the cost-benefit of the number of RFCs we seem to have saying "WMF please undo whatever it is you've just done", as well... The Land (talk) 11:43, 2 March 2018 (UTC)[reply]
    No opinion on your general point, but it's not hard to see how this, multiplied many times, will be a serious disruption, far from a marginal impact on personal experience. You can tell folks not to do that until you're blue in the face and many will do it anyway, either because they are unaware of your guidance or because they don't care about silly old guidance. It's clear that something needs to change, the question under discussion is what. ―Mandruss ☎ 11:52, 2 March 2018 (UTC)[reply]
    @The Land: Improving experience of Russian Wikipedia and other communities was not intent of this change. This was a complete decision mystery from WMF, we and others were asking only for increasing 255 bytes to 255 symbols across the Wikimedia projects, what we got is the same 1000 characters out-of-nowhere as you do. We are frankly as surprised about this change as your community is. stjn[ru] 11:55, 2 March 2018 (UTC)[reply]
    Well it's pretty clear that this is the WMF's chosen method of implementing that request. I'm not claiming it's a perfect implementation, but then, the reality is that the WMF does not have the tech resources to do everything perfectly. The Land (talk) 20:54, 2 March 2018 (UTC)[reply]
    The specific wording of the proposal is as follows: Should enwiki request that the old edit summary limit be put back on this project? This proposal is for our project and does not impact the Russian Wikipedia at all. Given that you only edit here very rarely, and apparently don't even have enough time to actually read the proposal before !voting, you should not be so dismissive of the opinions of those who are actively contributing to the encyclopedia. This change may not affect you, but it most certainly does affect us. Lepricavark (talk) 19:35, 2 March 2018 (UTC)[reply]
    lol, once you've been contributing to the Wikimedia movement for 14 years, then come back and tell me I don't understand Wikipedia! The Land (talk) 20:54, 2 March 2018 (UTC)[reply]
  • Oppose. If there is an actual problem here (and I'm struggling to see one), then the way to solve it is to get consensus for a local guideline about edit summary length and educate people about it. Thryduulf (talk) 11:48, 2 March 2018 (UTC)[reply]
  • Support Allowing scope to place long diatribes in edit summaries (whether displayed or not) will hasten the demise of the talk page. We do, however, need to shorten lengthy auto summaries like "Undid revision ***** by *****": Noyster (talk), 11:54, 2 March 2018 (UTC)[reply]
  • Oppose per Thryduulf and The Land, but it would definitely be useful to have some way to truncate the display of long summaries. ​—DoRD (talk)​ 12:50, 2 March 2018 (UTC)[reply]
  • Oppose I have no problem with the new edit summary length. If people are using it to be disruptive, then deal with that on its own. --Jayron32 13:28, 2 March 2018 (UTC)[reply]
    Do we not have enough disruption to deal with on its own without creating new opportunities for it? There are already alternative solutions on the table that do not. ―Mandruss ☎ 13:32, 2 March 2018 (UTC)[reply]
  • Oppose clearly a net improvement for the community per The Land, Sadads (talk) 14:58, 2 March 2018 (UTC)[reply]
  • Oppose clearly this is a net improvement. However, I very much support a 255 displayed-character "soft" truncation with a clickable [...] to expand to the full summary. Or any other reasonable limit to displayed character if 255 is deemed too much.Headbomb {t · c · p · b} 15:05, 2 March 2018 (UTC)[reply]
  • support This is not an improvement and just invites people to write yet more things that they cannot redact or edit. And no I do not want my watchlist crammed with overlong rants. And as noted above. people already treat edit notes like tweets (some history pages look like my twitter feed with fake dialogue) and longer edit notes will only encourage that, and the edit warring that goes on underneath it. Dramatic changes like this to user experience should have a prior RfC in any case. Jytdog (talk) 15:27, 2 March 2018 (UTC)[reply]
  • Oppose There are often times I have to shorten or remove details in an edit summary just fit it in the limit. Would rather be able to explain things without being limited. I would be fine with a lower limit if the character limit was limited to only displayed characters, as often wikilinks(to ip/user+talk) can take up a significant portion when reverting. Other cases are when I want to link to a talk page discussion with section, but there isn't enough space to link it and give a detailed edit summary, and you are forced to just simply say see this linked discussion with short summary, or give more detailed summary and refer them to go to talk page, where they have to find discussion on their own there or in archives. If there seems to be a high level of abuse/disruptions, limiting it to extended confirmed users could be an option. WikiVirusC(talk) 15:37, 2 March 2018 (UTC)[reply]
  • Oppose grandstanding tends to be a bad look for people --Guerillero | Parlez Moi 15:54, 2 March 2018 (UTC)[reply]
  • Support Overly long edit summaries clutter the history page, watchlist, and are unnecessary. If the argument is for IPv6 addresses, extend it to 300 characters. If you need more than that, use the talk page. Natureium (talk) 16:48, 2 March 2018 (UTC)[reply]
  • Oppose – large edit summaries would likely indicate a bigger issue or problem being dealt with, something that should probably attract more attention. If I see a huge edit summary on my watchlist, I will likely pay more attention to that edit. This feature may also encourage editors to speak to each other more, right on the front lines where editing is taking place. Better communication leads to better results. A well-explained edit is less likely to be reverted. A big problem we are likely to face with this feature is spamming, and so there will be an inevitable increase in deletions of entries from edit histories. Hopefully we have enough people available with the right tools to handle the shift in problems that this feature will create. Not more or bigger problems, necessarily, but different ones. And of course, we will need new guidelines for edit summaries. Like not repeating huge summaries for multiple edits on the same page. Posting the explanation once should suffice. Huge edit summaries for mass edits over many pages should also be discouraged, with a preference for a pointer to a notice on a talk page, rather than such a notice being repeated over and over in watchlists. The biggest outcry will likely be from editors monitoring things via watchlists. It will be interesting to see how the community adapts this new feature into its culture, and I am confident that it will. Let's try this new feature out for awhile and see how it goes.     — The Transhumanist    17:09, 2 March 2018 (UTC)[reply]
  • Oppose Longer edit summaries are useful. We should have a way to truncate. I also endorse Legoktm's comment: when there's a feature change, we should try not to just shout "turn it off!" but talk to the developers calmly about how the change affects us so it can be improved. A bit more "Yes, and..." and a bit less blow it up and start over. —Tom Morris (talk) 17:27, 2 March 2018 (UTC)[reply]
  • Partial oppose: 1000 is overkill for legitimate usage. I'd recommend 512 with an option for truncation in the view, and that a filter be implemented for overly long edit summaries so that they may be monitored for abuse. ViperSnake151  Talk  17:31, 2 March 2018 (UTC)[reply]
  • Oppose. Smallchief (talk) 17:35, 2 March 2018 (UTC)[reply]
  • Support per Jytdog and Noyster - perhaps till 400 char but not more than that really Galobtter (pingó mió) 17:39, 2 March 2018 (UTC)[reply]
  • Oppose, per Unicode, IPv6, etc. There should probably be a watchlist option to only show the first n characters, though. Support Lego's solution now that I've actually found it. --SarekOfVulcan (talk) 17:41, 2 March 2018 (UTC)[reply]
  • Oppose does not matter. Alanscottwalker (talk) 17:49, 2 March 2018 (UTC)[reply]
What does this mean? Are you just voting without a reason to vote? — Preceding unsigned comment added by Natureium (talk • contribs)
Explanation: We call that a !!vote—pronounced not-not-vote—aka vote. ―Mandruss ☎ 19:13, 2 March 2018 (UTC)[reply]
Was I unclear, sorry -- the objections are silly (too much space! we don't want to read! I can't handle change! Other people will act bad!, I was not consulted! People play! etc.) and the expansion of space is fine. Alanscottwalker (talk) 19:18, 2 March 2018 (UTC)[reply]
No, objections include opening up abuse of watchlists, obfuscating issues that would normally be picked up, making admins and those who try to detect vandalism lives' more difficult. But hey. The Rambling Man (talk) 20:42, 2 March 2018 (UTC)[reply]
  • Support - What plank actually thought this was a great idea ? ....., 250(ish) was absolutely fine ..... Bumping it up to 1000 means more dumbass edit summaries like mine[2], If you want to post longer comments then use the bloody talkpage, I'm all for change and improvement but this improves nothing (if anything it gives trolls/vandals more opportunity to clog up my entire watchlist!). –Davey2010Talk 19:37, 2 March 2018 (UTC)[reply]
I feel I should add I didn't abuse the feature for the fun of it - I abused it to show how easy it is for it too be abused, I don't in any way, shape or form condone anyone following suit and I would hope for this specific case my edit summary isn't revdelled, Thanks, –Davey2010Talk 20:35, 2 March 2018 (UTC).[reply]
  • Support they are edit summaries, made specifically to include in a brief way the changes made. I’d be happy with a small increase, but as demonstrated this has major potential for abuse. In a rare occasion there’s not enough room, use the talk page to explain, where character usage is unlimited. Aiken D 19:43, 2 March 2018 (UTC)[reply]
  • Oppose: It's preferable to be able to paste the full url of the source for a copyvio edit removal into my edit summary, but sometimes with the old limit I have run out of space, particularly when I want to remove from multiple sources in one edit. See for example today's work at 2017 Mumbai stampede, where it was possible to include full urls and get the work done quicker in fewer edits while still leaving a good audit trail. Running out of space means I have to perform more edits to do the same amount of work (which is slower and also clutters up watch-lists), or leave a cut-off url (which makes later review of what I did difficult to impossible). 500 characters is prolly enough for 3-4 urls though. — Diannaa 🍁 (talk) 19:47, 2 March 2018 (UTC)[reply]
  • Support (a) if you can't _summarise_ your edit in 200 characters, something's wrong and (b) this is perfect for vandals to flood watchlists. Mine is already overwhelmed by people just trying it out. It's a joke and completely unnecessary. Just because Twitter doubled up, it doesn't mean we need this crap in our lives. REMOVE, allow me to demonstrate. Minor change. Another minor change. The Rambling Man (talk) 20:18, 2 March 2018 (UTC)[reply]
    Now then, hopefully no-one will block me, but the point is, now look at the edit history and try to work out what I did. This is a complete joke, a failure, a fad that needs checking. Perhaps those who are opposing this restriction in characters don't do a lot of work behind the scenes where quickly assimilating information from an edit summary is essential. Not to mention how easy it's going to be to destroy the ability to easily parse ones' watchlists. REMOVE. The Rambling Man (talk) 20:21, 2 March 2018 (UTC)[reply]
    Revdeled the second two as disruptive. Once was more than enough. --SarekOfVulcan (talk) 20:24, 2 March 2018 (UTC)[reply]
    That's bollocks. You're deliberately obfuscating the issue. We need to see what two or three edit summaries of this type look like back to back. But you've hidden it now. The Rambling Man (talk) 20:27, 2 March 2018 (UTC)[reply]
    If you want that iridiscent's talk history has enough of that Galobtter (pingó mió) 20:31, 2 March 2018 (UTC)[reply]
    Not at all, TRM. They have helpfully demonstrated the extra workload this will add for already-overworked admins. ―Mandruss ☎ 20:32, 2 March 2018 (UTC)[reply]
    It's not just admins, the rest of us who care about the integrity of Wikipedia are now concerned that we can't work out what the fuck people are doing. The Rambling Man (talk) 20:35, 2 March 2018 (UTC)[reply]
    That too. Don't worry, if this sticks it won't stick for long. Many of those !voting Oppose will be at the head of the line complaining about it, mark my words. ―Mandruss ☎ 20:37, 2 March 2018 (UTC)[reply]
  • Support turning it off. Yes, there are some potential benefits; yes, they're hugely outweighed by the disruption watchlist-flooding will cause. ‑ Iridescent 20:23, 2 March 2018 (UTC)[reply]
    So, because you don't want people being abusive with the new edit summaries, you used it abusively. If you didn't want them to be used that way, maybe you shouldn't have. --Jayron32 20:26, 2 March 2018 (UTC)[reply]
    Um, to demonstrate the problem, which is perfectly reasonable. Bonkers. The Rambling Man (talk) 20:40, 2 March 2018 (UTC)[reply]
    (edit conflict)If you want to demonstrate the problem, do it in your own sandbox and link to it, not a major discussion venue. --SarekOfVulcan (talk) 20:44, 2 March 2018 (UTC)[reply]
    I think the point is that this disruption can and will be caused on ANY WIKIPEDIA PAGE that's not fully protected. Demonstrating it in a sandbox is great, but it misses the salient point, which you are working so hard to obfuscate. Noted. The Rambling Man (talk) 20:47, 2 March 2018 (UTC)[reply]
    WP:POINT+WP:IAR. ―Mandruss ☎ 20:43, 2 March 2018 (UTC)[reply]
  • Oppose - While I agree that 1000 is too many quite often 255 was not enough. A compromise at 500 would be useful. BTW as I see it the real problem is those editors who copy paste their post into the edit summary line. Perhaps they could learn to type something that is a brief description summing up what they posted. MarnetteD|Talk 20:35, 2 March 2018 (UTC)[reply]
  • Support - Progress is great, and I think 1000, or even 10,000 character edit summaries might be OK, but only if their display is truncated by default. This should have been submitted to the community for discussion before being phabricated into our workflow. It has the potential to be quite disruptive unless implemented with finesse.- MrX 🖋 20:57, 2 March 2018 (UTC)[reply]
  • Support It's a summary. It's supposed to be brief. Learn to be brief. PaleCloudedWhite (talk) 21:00, 2 March 2018 (UTC)[reply]
  • Comment it's ironic that an admin has deemed two of my lengthy edit summaries to be so disruptive that they need to be rev-del'ed, and I was simply demonstrating the problem. So once the general population of vandals get to know this, how much time is going to be spent rev-del'ing such "disruptive" summaries? Although the principle I was demonstrating has been incorrectly obfuscated by this admin, it proves another very important point in favour of returning to shorter summaries. The Rambling Man (talk) 21:05, 2 March 2018 (UTC)[reply]
    Here is a great example of what this admin was trying to hide from you all. The Rambling Man (talk) 21:23, 2 March 2018 (UTC)[reply]
  • Support Long summaries discourage talk page discussion and, thus, interferes with dispute resolution. All main forms of dispute resolution — Third Opinion, Dispute Resolution Noticeboard, and Formal Mediation — have a prerequisite that they will not accept a case which has not had substantial talk page discussion and that they will not consider edit summaries in determining whether that discussion has occurred. Long edit summaries will cause more cases to be declined. — TransporterMan (TALK) 21:27, 2 March 2018 (UTC)[reply]
  • Oppose I think there's a real need for a longer edit summary field. That said, it is easy to imagine that problems can occur if people accidentally post a long edit summary. Can that be handled with an edit filter which would warn an editor that there edit summary exceeded say, 500 characters, and give them a chance to edit?--S Philbrick(Talk) 21:47, 2 March 2018 (UTC)[reply]

Discussion

  • For an example of what how potentially disruptive this could be, see Special:Diff/828335644. I'm not calling out the editor who made that post, since it's likely they didn't know about the change in limit, it was just what brought the issue to my attention. Primefac (talk) 23:53, 1 March 2018 (UTC)[reply]
  • You can name me. I am somewhat embarrassed, but no, I had not idea. I like to copy my entire post into the clipboard, in case of edit conflict or browser crash, but I see there will now be a big problem. Until today, the edit summary was limited to two lines. --SmokeyJoe (talk) 23:57, 1 March 2018 (UTC)[reply]
    Wow! I used to do this as well, until an editor complained about it. –xenotalk 18:53, 2 March 2018 (UTC)[reply]
  • Bad solution, but status quo ante sucks almost as much. Take for example the case of an undo of an edit made by an IPv6 editor. You have to remove the talk page link to have much room at all, and often even that's not enough to explain your revert adequately. Ideal solution would be a length that is variable depending on what's already there, always allowing for x number of additional characters. Surely that's do-able? ―Mandruss ☎ 00:08, 2 March 2018 (UTC)[reply]
  • I can see that this solution is going to be a problem at times, but I've been running into the too-short summary limit since we started seeing IPv6 addresses. By the time an automated summary links to both the IP address and the IP's talk page there isn't all that much room left over. Even just getting rid of the talk page link would be an improvement. Meters (talk) 00:17, 2 March 2018 (UTC)[reply]
    If you use tools like Twinkle for such things then the request can be made at WT:Twinkle or if you have a github account on their respective pages. If you are talking about the automatic "undo" summary then perhaps MediaWiki:Undo-summary is the change you are looking for? --Majora (talk) 00:22, 2 March 2018 (UTC)[reply]
    If one is more interested in the overall project than their own needs, they prefer site-wide solutions over single-user ones. (I don't use Twinkle for reverts.) ―Mandruss ☎ 00:37, 2 March 2018 (UTC)[reply]
    Changes to the tools people use and the site settings that dictate things would be site-wide. Now that I look at it more, it appears that the automated edit summary on undos was already changed to accommodate IPv6 address as well as long usernames. This change seems like a gross over correction. I'm of the opinion that it needs to go back to the drawing board and a more adequate solution needs to be worked out by the devs as to not hammer in a solution, globally, that could cause such problems like filling up histories and watchlists. --Majora (talk) 00:46, 2 March 2018 (UTC)[reply]
    For "undo" summaries I often just highlight and delete the "talk page link" portion if I need more room - occasionally I might just remove the whole "autogenerated" portion and replace with my own summary, but the need to do this has been very rare. -- Begoon 02:49, 2 March 2018 (UTC)[reply]
  • Just as a note, there's various Phab tasks related to the change. phab:T185948 is probably the most specific task, and phab:T6714 and phab:T6715 are also relevant. --AntiCompositeNumber (talk) 00:41, 2 March 2018 (UTC)[reply]
  • My edit summaries are annoying me everywhere I look. How about an edit summary checkbox "allow expanded summary", with its default state set in your preferences? --SmokeyJoe (talk) 00:48, 2 March 2018 (UTC)[reply]
  • The change probably cannot turned off in any meaningful sense. I would rather put something in WP:Edit summaries that people should tend toward shorter rather than longer summaries. SmokeyJoe (Headbomb does it too) probably shouldn't copy and paste entire messages into the edit summary box anymore but instead actually summarize his comment. --Izno (talk) 01:09, 2 March 2018 (UTC)[reply]
    I'm guessing that would have about as much effect as WP:SIGAPP - a Wikipedia policy. ―Mandruss ☎ 01:17, 2 March 2018 (UTC)[reply]
    I have seen SIGAPP required of persons (and blocks provided until compliance). --Izno (talk) 01:57, 2 March 2018 (UTC)[reply]
    Too rare to be significant. ―Mandruss ☎ 11:14, 2 March 2018 (UTC)[reply]
  • A possible solution would be after a certain length, that a dialog box prompt you that it's considered longer than average. I doubt most of the editors who appear to be abusing this are aware of the issue. A prompt, in these cases, would cause editors to be aware of the situation, and thus would prevent long summaries in most cases. I also like the idea of manually having to check a box to allow an extended summary. That said it probably should just disappear all together. --Deathawk (talk) 02:24, 2 March 2018 (UTC)[reply]
Tracked in Phabricator
Task T6717
  • We need to stop approaching every change with "ugh this is bad lets turn it off" and "clearly no one thought this through". This has been in the works for YEARS and is one of the most wanted requests from the global Wikimedia Community. Here's my proposal: Allow people to save the full length of edit summaries in the database. On places where vertical room is limited (history/watchlist/etc.), do truncation based on the visual length (not wikitext length), add a clickable "..." to the end that will do full expansion. That allows complex characters and fixes IPv6, etc, while hopefully preventing the problem of longer summaries. Legoktm (talk) 04:02, 2 March 2018 (UTC)[reply]
    Saying we should stop saying "no one thought this through" while simultaneously stating a potential fix that would have solved all of this before it started seems a tad ironic. --Majora (talk) 04:05, 2 March 2018 (UTC)[reply]
    I was referring to the rhetoric being used. Given the complexity required by this change I'm not surprised something got missed. And I wish people took a moment to think about how there might actually be a good rationale behind the change before immediately jumping on it for being bad. Legoktm (talk) 04:15, 2 March 2018 (UTC)[reply]
    I'm all for the truncated version. I also understand the rationale for doing it. I'm also still on the side of undoing the change until the fix you mentioned above is deployable at the same time for the reasons I started this RfC. --Majora (talk) 04:22, 2 March 2018 (UTC)[reply]
    • Support Truncating the display, with a clickable "..." to reveal the rest of it, I think is a fantastic idea. Then everyone wins :) Because it's true even on enwiki we do run into issues with the summary being too short, such as page protections and reverting IPv6. For the record, I'm not sure everyone is simply adverse to change, or questioning the merit of this feature. Rather, it was clear there could be problems with display like the example diff, and that it's possible the edit summary would become some new unwarranted venue for discussion, especially when edit warring. If the display is truncated, that'd be enough to discourage misuse, and we still get all the benefits. — MusikAnimal talk 04:18, 2 March 2018 (UTC)[reply]
    • I suggested this above (or similar) as well, so obviously support FACE WITH TEARS OF JOY [u+1F602] 11:14 pm, Today (UTC−5)
    • I'd support this, but I think the current rollout should be disabled until this can be fixed. It has too much potential for disruption (and not just with watchlists. The potential for fights when in content disputes are also a factor). I don't think the positives of the untruncated version outweigh the negatives at this time. TonyBallioni (talk) 04:17, 2 March 2018 (UTC)[reply]
    • Hmm, I think IPv6 thing could be more elegantly fixed with a limit to visual length or if not, then a limit of 400 characters or something should be enough, not sure we should encourage/allow over-long edit summaries, I could see them being annoying even if hidden. Any problems with summary length usually from links personally Galobtter (pingó mió) 07:08, 2 March 2018 (UTC)[reply]
    • FYI, Allow people to save the full length of edit summaries in the database is 65535 bytes. ;) Anomie⚔ 12:25, 2 March 2018 (UTC)[reply]

I have problems with this.

1. Some section names are long. This would clip the meaningful part of the edit summary, eg 

/* Question about using your image in my article about bananas */ replied to Longtailedlemur and Chad

2. This could be confusing for new users. I would recommend to have this as an opt-in (or at least opt-out) feature.

3. People who abuse long edit summaries would abuse short edit summaries too.

4. This needs to use JavaScript, so it would need to be written as a gadget. Without checking whether the user is viewing a relevant page (such as recent changes or diff preview etc), my codes are included below.

Like this (truncates to 300px width, does not look well with diff previews) 

// Shorten all edit summaries to 300px
$('.comment').prop('style','text-overflow: ellipsis;width:300px !important;overflow:hidden !important;display:block;white-space: nowrap;')

// Unshorten the edit summary when clicked
$('.comment').click(function(){
$(this).prop('style','width:auto;');
});

Or like this (truncates to n characters). 

var n = 80;
$('.comment').each(function(i){
	var original = $(this).text();
	var shortText = original.length > n ? $.trim(original).substring(0, n).trim(this) + " [...]" : original
	$(this).text(shortText);
	$(this).click(function(){
		$(this).text(original);
	});
});

5. When expanded, is it necessary to collapse the edit summary back on a second click? That's something I did not write above.

--Gryllida (talk) 05:19, 2 March 2018 (UTC)[reply]

  • I am not a member of English Wikipedia community, but since there is inherently more chance that they would listen to you than to other Wikimedia communities on this matter, I want to completely support this proposal (of reverting this change globally, to be completely sure) here. Seems like Russian Wikipedia community voted in 2016 on a good proposal to get our edit summaries up to your limit (since in Russian you could enter only 128 symbols in edit summary before), but it was turned into a complete travesty on global level. There was no consensus on 1000 symbol edit summaries, there is no consensus on 1000 symbol edit summaries, the fact that they did this is atrocious. Any hacks that are proposed here (hiding some parts of edit summary etc.) are just hacks to curb Wikimedia community opinion after not asking one (since Community Wishlist proposal was explicitly about non-Latin communities and their database-imposed limits to edit summary length). Saint Johann (ru) 10:53, 2 March 2018 (UTC)[reply]
  • Question for Legoktm, MusikAnimal, and others supporting the proposed solution — at the risk of spilling the WP:BEANS, wouldn't such a solution be the perfect place for vandalism? Make an edit, have a longish edit summary, but just beyond the cutoff for "show more" you can insert whatever insults. I suppose the answer is that folks will have it unhidden by default, but seems like it could make for a lot of extra clicking when checking diffs. Fixed pings, I need my tea ~ Amory (u • t • c) 11:27, 2 March 2018 (UTC)[reply]
    Hidden vandalism is better than not hidden, right? ;) I'd hope most of it would get caught by patrollers, but yes a simple user script/gadget could make it always show the full edit summary for those who want to. I doubt we'll introduce a preference, too many of those as it is. — MusikAnimal talk 16:35, 2 March 2018 (UTC)[reply]
  • @Majora: The phab ticket you mention in the suggestion (phab:T6714) was outdated (apologies for that). Although this was in the German-speaking 2013 survey, we have not been part in this change (be it good or bad). The reasoning behind the change seems to be explained here. Would it be possible to update the intro accordingly? Thanks, Lea Voget (WMDE) (talk) 12:49, 2 March 2018 (UTC)[reply]
    Please accept my apologies Lea Voget (WMDE). That was the phab ticket that I saw and the header stating that it was on the top 20 German Wikipedia wishlist along with a link to a dewiki thread caused me to jump to an incorrect conclusion. I do apologize for that and I have struck the part of the RfC that stated that it was a dewiki proposal. --Majora (talk) 21:17, 2 March 2018 (UTC)[reply]
  • By all means invite people to debate via edit summaries rather than the talk page and fill up watchlists as a result of this "solution". But if the result is my having to read through pages of waffle because this has left room for about half a dozen changes to the page on a perfectly reasonable laptop screen I, for one, will be finding another way to spend my time. Britmax (talk) 14:42, 2 March 2018 (UTC)[reply]
  • I cannot understand what the people who implemented this were thinking. Why in the world would they make such a dramatic change to the user experience and not get prior buy-in? Jytdog (talk) 15:49, 2 March 2018 (UTC)[reply]
  • This RfC is not neutral, nor does it attempt to express the situation in an even manner. Leading with declarations such as, "It will do nothing more than cause massive disruption in the histories of numerous pages." is not exactly assuming good faith. :) I really think we can, and should, do better in framing the situation so that all participants can have a clear and equal understanding of the facts before asking for community feedback. I suggest the creator work with interested parties to provide more context for the reason for the change (with references to existing discussions) and try again. As it stands now I can't in good conscious participate in such one-sided propaganda. Ckoerner (talk) 16:36, 2 March 2018 (UTC)[reply]
    • Addendum, as I wrote this I think I understand what people mean when they say the RfC process is broken. It's not necessary broken (nor is it perfect) but the glib way in which they are written leads to an oppositional argument easier than a congenial discussion. Ckoerner (talk) 16:39, 2 March 2018 (UTC)[reply]
    • Maybe WMF should try to explain their decisions beforehand, especially the decision to stump through from the original standpoint of ‘non-Latin communities want the same length of edit summaries as other communities’ right to ‘1000 characters for everyone, let’s write essays in edit summaries’. I feel like decision-makers in individual communities have a lot more responsibility and accountability in their communities than Wikimedia Foundation has in entire movement. And it really shouldn’t be like this. I was made more accountable over changing one template through a discussion in my home project than entire team that made this change without any discussion was made accountable over this. Something is entirely wrong not in the way communities respond to non-discussed changes, but in the way WMF is being dishonest and not upfront to their communities (not only English one, I want everyone to remember that, English Wikipedia gets it easy relative to others). stjn[ru] 17:45, 2 March 2018 (UTC)[reply]
      • I think part of the problem is that the WMF is outnumbered in the many voices of representation. It's entirely plausible that the folks who enacted this change were following the desires of a community - that of the folks who participated in the wishlist proposal. That group said please do this for us. The team went and did that work. Which I think is healthy and how most folks would like to operate. Now they turned it on, and part of another community, with some obvious overlap, is upset. This comes through in the tone and framing of the RfC and comments like one one succeeding yours. In this situation the folks from the WMF (obviously not the entire WMF as we are not monolithic as some might think) is stuck in a position of damned if we do, damned if we don't. I think there's an opportunity to learn how to make our relationship healthier - in both directions. My suggestion, if we continue the RfC process as a means to understand community consensus - particularly around software changes/updates/configs - is that said proposals should be drafted together, not as one side in opposition to the other. We're all on the same side. Ckoerner (talk) 21:06, 2 March 2018 (UTC)[reply]
        • @Ckoerner: the matter of the fact is, you can find my own vote in your link under #34. But the thing is, I am more than sure that both the proposer and the voters didn’t give the Foundation and its developers the opportunity to do whatever the hell they like by their vote. The people there wanted to have parity with English-speaking colleagues in the number of characters, no one was talking about increasing limit up to thousand characters.
          WMF even understood this as we see in ‘We don't want to encourage Latin languages to post 3x longer edit summaries, because edit summaries aren't intended to be a primary communication method’. But someone clicked along the way, someone thought it was good idea to seek consensus where there is none, and someone did this their own way instead of implementing wishes of communities that you are talking about. At this point it is pretty hypocritical to talk about the tone of discussion, because there was none prior.
          And the less discussions are happening, the less of the same side we are on. I want to believe in all the good work the Foundation does, but frankly WMF developers get to stump through with any changes they like without any hesitation or need to at least ask at some point in time. If we are on the same side, we both should act like we are on the same side. And the main responsibility for this is on the side of powerful, not on the side of weak (which, in this case, is the Wikimedia community). stjn[ru] 21:29, 2 March 2018 (UTC)[reply]
      • User:Ckoerner what is fucking broken is the way the WMF interacts with the editing communities. Jytdog (talk) 19:43, 2 March 2018 (UTC)[reply]
  • What would be helpful is an option to subdivide the edit summary and have 200 bytes for the edit summary you are writing in addition to the generated edit summary that lists the section name (which really should not be too long). But with long IP names reverting edits by one long IP name to another long IP name can generate a lot of bytes. The ability to add up to 200 bytes to such a generated edit summary would occasionally be useful. ϢereSpielChequers 20:31, 2 March 2018 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=828491976"