Wikipedia:Village pump (proposals): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 01:44, 5 March 2018

Table of contents
First discussion
End of page
New post

Shortcuts

New ideas and proposals are discussed here. Before submitting:

Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
Consider developing your proposal at Village pump (idea lab).
Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
Proposed policy changes belong at Village pump (policy).
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

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. ZipcodeZoo.com@gmail.com[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]

Is Wikipedia:WikiProject Tree of Life still active? If so, members of that project may have some useful input to this discussion. --Jayron 32 14:48, 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]

Might not Wikispecies be a more relevant place for this information? —Tom Morris (talk) 11:32, 2 March 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]

Comment: I see some comments about keeping or replacing pages. On French Wikipedia, we had pages like Wikipedia:Tutorial and Wikipedia:Introduction. They were equally read. So we have decided not to merge or replace them, but to create a new simple launch page that would give choices to the user. That page is now linked from quite everywhere (sidebar, welcome messages...) as the unique starting page and has a lot of views with an acceptable ratio of people going to each pages. HTH, Trizek ^{from fr:} 08:25, 22 February 2018 (UTC)[reply]
Support — The visual editor is much better than the wikitext editor for most of the basic things, I still use it for minutiates. The new tutorial too, is much better for a beginner than the old ones. However, the old tutorials should still be kept in some shape or form, but as far as this RfC is concerned, they should absolutely be replaced by Help: Introduction.
Regards, SshibumXZ (Talk) (Contributions). 21:11, 22 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.

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.
are overused in the headings.
If both Markup and VE are taught together, I think that introducing VE first in each page makes more sense for new users.
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
The second tab of WP:I largely overlaps with the final wrap-up, and could sensibly be merged there.
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).
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?
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.
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.
WP:Tutorial/Wikipedia links doesn't mention VE at all in this case, but otherwise ok
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.
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).
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]

Really consider here that the proposal takes us from 7 tabs to all this . Not a good way to keep readers Why people online don’t read to the end..--Moxy (talk) 16:53, 25 February 2018 (UTC)[reply]
Oppose per above. Visual Editor is still not ready for prime time, in my opinion, and shouldn't be the default editor for anyone. I don't think learning wiki markup is that high of a bar for anyone. Changing up or removing the help files hardly seems worthwhile. You could always create new pages for VE and route editors according to their editor preference. Dennis Brown - 2¢ 01:53, 2 March 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]

For newcomers, VisualEditor is far superior to the classic wikitext editor. Its limitations are only relevant to editors trying to do more complicated things, and at least 90% of new contributors [a conservative estimate] aren't ever going to get to those complicated things. (Here's a thought experiment: use the wikitext editor to open an article with an infobox, and put yourself in the mind of someone who has never worked with raw HTML - are you going to be sufficiently intimidated to simply quit trying to edit? I'd say "clearly yes" for - again - at least 90% of those who are inclined to contribute.)

That means that when a newcomer looks for help, that help should assume that the newcomer is using VisualEditor. It's fine to provide links to relevant pages for those using the wikitext editor (hatnotes are good), but help/information pages for the wikitext editor shouldn't be the default.-- John Broughton (♫♫) 18:31, 3 March 2018 (UTC)[reply]

@John Broughton: Here is a little thought experiment:- if VisualEditor is far superior to the classic wikitext editor- get a new editor to post a message on my talk page using VE. To me that is a severe limitation that justifies saying that VE is in beta. VE is prefered by users who have come to WP through the mobile phone route- but gets in the way of the editing process (Type in a fact, type in where you found it, now tell others what you have done) for those who were computer active pre-iphone. --ClemRutter (talk) 19:44, 3 March 2018 (UTC)[reply]

I own only a car; it's not capable of hauling large packages or materials, like a truck. I'm not going to replace it with a truck just because once or twice a year I'd prefer to have a truck. Most newcomers to Wikipedia don't post to talk pages, whether they edit with VE or the wikitext editor; in fact, most experienced editors don't post to article talk pages very often. So no, I don't support newcomers using a difficult-to-learn UI for most of their work because it avoids their having to use a different UI for occasional posting. (And, to be blunt, it's not that difficult to learn how to post to a talk page: click "New section", type, add four tildes, add an explanation, save. And yes, inserting a comment into an existing section is a little more difficult, but so is understanding the right way to use a talk page.) -- John Broughton (♫♫) 21:01, 3 March 2018 (UTC)[reply]

What is more serious is the changing UI, that prevents us from writing tutorials and documentation. VE needs to become stable. --ClemRutter (talk) 19:44, 3 March 2018 (UTC)[reply]

VE is stable. It can't currently be used to edit pages in the Talk or Wikipedia namespaces (but it works for Help namespace pages). It's too bad that more of the experienced editors of Wikipedia don't use VE for editing articles - it's faster and easier, though there is a small amount of learning for the new UI; so yes, there aren't enough people who know VE well enough to write and update tutorials and documentation, though I'm sure I could point to lots of tutorials and documentation involving the wikitext editor which are seriously out of date. -- John Broughton (♫♫) 21:01, 3 March 2018 (UTC)[reply]

RFC: Autopopulate Category:Infobox templates when we can

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

Wikipedia technical issues and templates
Wikipedia proposals
WikiProjects and collaborations

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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

Category:Infobox templates
- Category:Arts and culture infobox templates
  - Category:Publishing infobox templates

or

Category:Infobox templates
- Category:Society and social science infobox templates
  - Category:Organization infobox templates

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):

All infoboxes would conveniently be listed directly there. If you're looking for something ABL related, you just browse the category and look for ABL. If you're looking for {{Infobox magazine}}, you go in the M section and look for magazine.
The category could then be easily searched with an :incategory call in Special:Search. If you're looking for a retail-related infobox, you could just search for 'retail', and you'd find {{Infobox retail market}} quite easily.
The category could then be used to easily monitor recent changes/vandalism via Special:RecentChangesLinked/Category:Infobox templates.
The category could then be used by WP:AALERTS to create article alerts for WP:WikiProject Infoboxes.

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

Category:Infobox templates
- Category:Science and nature infobox templates
  - Category:Chemistry infobox templates
    - Category:Periodic table infobox templates

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

!Vote (Infobox categorization)

Support, as proposer. Headbomb {t · c · p · b} 12:44, 21 February 2018 (UTC)[reply]
~~Currently neutral.~~ Changing to support after Headbomb's comment. Jc86035 (talk) 14:39, 21 February 2018 (UTC) There are at least 100 infoboxes which don't use Module:Infobox but use class="infobox" (1,107 templates total), so the tracking would have to manually account for those and possibly others which don't use the infobox CSS class. This example PetScan query lists every template in Category:Infobox templates whose title contains the word "box". The vandalism/article alerts points seem mildly useful, although Special:RecentChanges with the new filters (template namespace, excluding 500/30 editors) is probably sufficient for finding vandalism since there's not much editing activity in the Template namespace anyway. Jc86035 (talk) 13:25, 21 February 2018 (UTC)[reply]
That's a limitation of the 'automatic' part, but those cases can be manually handled quite easily. They're actually better handled manually, since not everything with an infobox class is actually an infobox (e.g. {{Year nav topic}} [a navbox], {{RFA}} [which includes a navbox section], {{Poland Labelled Map Small}} [a map], etc.). The RecentChanges thing also applies to more than just monitoring vandalism though, and there are other benefits to this beyond a more useful RecentChanges log for infoboxes. What motivated me personally is I want to set up WP:AALERTS for WikiProject Infoboxes, and this would be a hugely more efficient way of doing that than anything else we have. Headbomb {t · c · p · b} 13:42, 21 February 2018 (UTC)[reply]
Support — Per nominator.
Regards, SshibumXZ (Talk) (Contributions). 20:39, 21 February 2018 (UTC)[reply]
Support — Multiple positives, no negatives afaict. ~ Tom.Reding (talk ⋅dgaf) 00:38, 22 February 2018 (UTC)[reply]
Support - Per nominator. ∰Bellezzasolo✡ Discuss 11:44, 22 February 2018 (UTC)[reply]
Support - This seems like a very good idea with little-to-no downside.- Mr X 🖋 13:27, 22 February 2018 (UTC)[reply]
Support Considering the absolute nightmare it is to do new page categorization - searching hither and yon to figure out how some one categorized the categories, or even what categories there are - I would support anything that makes that easier. If the best we can do is a single group to Crtl-F through, well, I'll take what I can get. Jbh ^Talk 23:29, 23 February 2018 (UTC)[reply]
Support Well argued, clearly beneficial, no apparent down-side. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:09, 24 February 2018 (UTC)[reply]
Oppose in this form. Fundamental objections: still missing the central definition to include/exclude (proposal does not say: "all templates that use class=infobox", or otherwise). There is no provision to add/remove "cornercases" *, which could best be handled beforehand at definition stage (that is: here & now). Also, the category will change its definition without providing any process of cleaning up/adjusting the subcategories; these are left to die without care (for this too, starting a new category would be a better solution, evading conflicting definitions).

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)

Comment: Sub-categories Category:Infobox templates by ..., to group infobox hierarchies by different facets, might also be useful. Jheald (talk) 13:12, 21 February 2018 (UTC)[reply]
Comment: It is probably better to create a new tracking category but not to change existing categories. Ruslik_Zero 20:32, 23 February 2018 (UTC)[reply]

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]

Autocategorization seems like a means to an end given that the objective is to set up article alerts. Another solution would be simply to add the category manually. Another alternative would be to monitor Special:Recentchangeslinked for Template:Infobox (lots of protections today by Primefac), considering these templates are not changed a lot, like you might need for article alerts for a generic WikiProject (to sift out the noise from the important page events like XFD). Checks for new infoboxes using {{infobox}} without the category can be made from Special:Search.
Regardless of the implementation of an "all infoboxes" category, support Ruslik's comment: It should be Category:All infobox templates. --Izno (talk) 21:21, 23 February 2018 (UTC)[reply]
@Headbomb: Can you follow through with your example of {{Infobox journal}} and describe how that template's categorization would change following the changes you are proposing? Blue Rasberry (talk) 21:45, 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. --Jayron 32 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]

@Pbsouthwood: "bots" include the autopatrol permission, all pages created by bots are already patrolled. — xaosflux ^Talk 19:35, 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]
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]
...which they could do if the articles were created directly in mainspace, too, with the added advantage that no "disinterested" volunteers (the people proposing this approach have specified that only "disinterested" editors with both multiple advanced user rights and knowledge of the subject matter should be able review these articles and move them to the mainspace) would risk carpal tunnel problems from manually moving thousands of articles.
BTW, I believe that if you check, you'll see that very little leaves draftspace without the involvement of AFC folks. The idea that there are a bunch of volunteers who regularly check the draftspace for promising articles is a myth. The research shows that draftspace is where articles go to die: fewer readers, fewer editors, less attention, and fewer improvements. WhatamIdoing (talk) 23:52, 2 March 2018 (UTC)[reply]

Let's be clear about what is being recommended here. Even if we actually find this hypothetical volunteer – someone who is simultaneously disinterested but still well-informed, and who has the specified combination of user rights – we are talking about an enormous amount of tedious work. If that volunteer only spends a mere 10 seconds to both review and move each article, we're talking about asking this person to spend more than 40 hours of very tedious work. The alleged payoff is that there might be some problem that a person whose brain is fried by hours of tedious work might catch, and which normal editing somehow wouldn't catch (or wouldn't catch as quickly). I think that everything we know about occupational psychology tells us that our hypothetical volunteer won't catch any such hypothetical errors (but who will probably accidentally introduce the occasional typo into the article titles or click the wrong namespace; humans do that kind of thing), and everything we know from looking at the sample articles indicates that every single one of them will instantly meet all of the criteria for being moved out of draftspace (the criteria are all about deletion-worthiness), including any that, by some unfortunate chance, happen to contain a problem. So from where I sit, this is more than 40 hours of pointless make-work for no discernible benefit and with no realistic chance of actually improving the articles. WhatamIdoing (talk) 01:07, 3 March 2018 (UTC)[reply]
@WhatamIdoing: Unless somebody puts an AfC template on the drafts, AfC will have nothing to do with this, full stop. I'm also in favour of putting these straight into mainspace as autopatrolled, but if the consensus is that a manual review is required, creating them in draftspace at least makes those reviews an optional task with no time limit, rather than adding to a critical project backlog (NPP). – Joe (talk) 20:00, 3 March 2018 (UTC)[reply]
I am confident that NPPers would figure out very quickly how to ignore these, or that they would just start clicking the patrol button to dump them back out of their collective queue (which is much faster than making someone WP:MOVE the page out of draftspace). I agree that there is no need for NPP to be involved, as we already know that none of the articles will meet NPP's core requirements (=delete-able, especially speedy delete-able). Draftspace means that average readers can't find the pages – unless and until some dedicated person manually changes its status. Dumping the articles in the NPP queue means that their numbers will artificially increase (as will the percentage of good articles that they see), but after 90 days, it has no effect at all, except to keep them listed in the NPP queue. So for me, the question is: How do we get this bit of the "the sum of all human knowledge" actually "available to every person in the world", e.g., a student who's supposed to write a paper for school? The answer to my question is not "dump it in draftspace until someone volunteers to spend days and days and days manually moving them back out". WhatamIdoing (talk) 22:21, 4 March 2018 (UTC)[reply]
~~Neutral~~ Support: 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:

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)
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)
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)
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)
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]

On point #1, Wikipedia:General references are not banned, nor even discouraged (especially for very short articles), so that's not actually a problem. WhatamIdoing (talk) 01:17, 3 March 2018 (UTC)[reply]

Thanks for the good suggestions. These have now been implemented, number 4 partially. See Nitidulinae, Paragnetina, Tabanus americanus. There will be a photo caption if the bug has a common name (except in the infobox), and a photo caption on all photos in genus or higher pages. Number 1 was already done. Even though general references are allowed, two or three people had recommended getting rid of them so I moved them to Further Reading. Bob Webster (talk) 07:11, 3 March 2018 (UTC)[reply]

Great, Bob Webster, I'm very happy to support this bot. I think we are very close to the best result we can get from an article creation bot of this kind. – Finnusertop (talk ⋅ contribs) 16:29, 3 March 2018 (UTC)[reply]

Support - actually a very cool concept. Let's make it happen. Swarm ♠ 12:23, 3 March 2018 (UTC)[reply]
Support As long as the bot paces itself, this seems like a worthwhile project to fill in gaps in our content. I don't think NPP is going to get flooded by 50-100 more articles a day, especially since these are likely going to be easy articles to review. TheCatalyst31 ^{Reaction•Creation} 17:33, 4 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. --Jayron 32 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]

This seems like a waste of time. Also what Iri said. TonyBallioni (talk) 19:15, 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.

Add link for search on Wikidata

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

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia policies and guidelines

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

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

Support as proposer --Majora (talk) 23:51, 1 March 2018 (UTC)[reply]
Support. Yes, please turn it off. --SmokeyJoe (talk) 23:55, 1 March 2018 (UTC) Maybe not turn it off, but make it adjustable by the user.[reply]
Support somebody must not have thought this change through. Lepricavark (talk) 23:59, 1 March 2018 (UTC)[reply]
Support per...do I really need this part? But I'll add a comment in Discussion. ―Mandruss ☎ 00:08, 2 March 2018 (UTC)[reply]
Support but it would be nice if the limit applied only to characters that actually display in watchlists, rather than the source of the edit summary. When you're adding extra text to an auto-generated summary that includes pipes, you can run out of space pretty fast. Whether that's technically feasible I wouldn't know. --Trovatore (talk) 00:27, 2 March 2018 (UTC)[reply]
Support 1000 is too much; if the limit is tuneable I wouldn't be opposed to something around the 400-500 range due to IPv6-related concerns. power~enwiki (π, ν) 00:48, 2 March 2018 (UTC)[reply]
@Power~enwiki: The proposal above that you're supporting is to reduce it back to 255 characters, so your vote should actually be "oppose". -- intgr [talk] 10:24, 2 March 2018 (UTC)[reply]
Support: You don't need 1,000 characters for an edit summary. 255 is sufficient. — MRD2014 ^Talk 01:37, 2 March 2018 (UTC)[reply]
Support: The old limit was sufficient. It was also useful. Very occasionally the situation seems to require a summary longer than the normal 5 or 6 words. On these occasions the limit prevented me from using an over-long summary by "forcing" me to pare it down to something appropriately concise. If there is still a need to say more I should be using the summary to point to a talk page discussion. Summaries should be concise and not bloat the history/watchlist entries. -- Begoon 02:45, 2 March 2018 (UTC)[reply]

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 - T P 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]
There's very little mystery, the goal was to increase the edit summary length, very specifically to accommodate Russian and other non-latin langages, seemeta:Community Tech/Edit summary length for non-Latin languages in particular. Headbomb {t · c · p · b} 01:01, 3 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]
I never said you don't understand Wikipedia. I said you didn't understand this proposal. But hey, you've been around longer than I have (with far fewer edits), so you must be right! Lepricavark (talk) 22:58, 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. --Jayron 32 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]
- As this day has gone on my watchlist has become an un-useable jumble of clutter. Jytdog (talk) 20:03, 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]

Come on, now. Apart from those trying to make a rhetorical, uhm, point, there has not even been a breakout of all these suppossed "problems" in this very discussion. Alanscottwalker (talk) 16:30, 3 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!). –Davey2010^Talk 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, –Davey2010^Talk 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. --Jayron 32 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.- Mr X 🖋 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]
- I think MedCom does a fine enough job rejecting cases on its own anyway ;-) FACE WITH TEARS OF JOY ^[u+1F602] 21:54, 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]
Oppose I don't see the examples cited as disruptive. They are on an order or magnitude less problematic than walls of text I see on discussion pages. Cas Liber (talk · contribs) 23:41, 2 March 2018 (UTC)[reply]

But that's what talk pages are for. The edit summary is meant to be a quick summary of what change you made. Natureium (talk) 23:43, 2 March 2018 (UTC)[reply]

Support 1000 is too much, even for IPv6 and things like that, noone needs more than 500 signs in any case. Furthermore, I don't think making the summaries much longer isn't what's needed here, but making the autogenerated parts of the summary machine-readable is. This solves the problem without causing this mess, and is a way better solution in general, as it is localizable as well. --MGChecker (talk) 00:02, 3 March 2018 (UTC)[reply]
Oppose (tho I support legotm's suggestion) --Terra ^(talk) 00:15, 3 March 2018 (UTC)[reply]
Support - it was a terrible idea in the first place, and has done nothing but harm from the beginning. --Orange Mike | Talk 00:42, 3 March 2018 (UTC)[reply]
Oppose Nobody needs to use an edit summary at all, but any number of characters is an arbitrary limit. Why not err on the high side? — Malik Shabazz ^Talk/_Stalk 02:16, 3 March 2018 (UTC)[reply]
Oppose. We'll get used to it soon enough. – Joe (talk) 03:00, 3 March 2018 (UTC)[reply]
Oppose There is no evidence yet of real trouble. Remember admins can hide edit summaries if there are serious problems (eg this is now big enough for copyvio, and not just for outing and harrassment). We also have the option of edit filters if you want to get a handle on stupid things happening. Graeme Bartlett (talk) 03:19, 3 March 2018 (UTC)[reply]
Oppose in light of alternative solutions, such as truncation. My main concern with lengthy edit summaries is that it might enable more editors to "discuss" things via the edit summary, which invites more edit warring behavior. However, I also think reverting all the way back to the previous limit is an oversimplified solution. More space in the edit summary in general is an improvement, especially considering how internal links and IPv6 addresses can sometimes clog it up. Mz7 (talk) 03:39, 3 March 2018 (UTC)[reply]
Support 1000 is too many. ~Awilley (talk) 04:31, 3 March 2018 (UTC)[reply]
Support 1000 is too many, and as someone else said: 'If you can't say it in 255 characters you should be pointing to a talk page'. Edit summaries are supposed to be just that: an edit summary. Turning edit summaries into yet another form of dialog is nonsense. In my experience, ES are hardly ever read anyway (due the number of clicks needed to get to them). Many less experienced users probably still don't even know what an ES is. Kudpung กุดผึ้ง (talk) 05:23, 3 March 2018 (UTC)[reply]
Oppose per MarnetteD. Double sharp (talk) 05:42, 3 March 2018 (UTC)[reply]
Oppose – The previous edit summaries limit was too restrictive, in my opinion. I do like the idea of having particularly long edit summaries auto-collapse, though. Master of Time (talk) 06:28, 3 March 2018 (UTC)[reply]
Strong Oppose - Say, for example, one wants to link to this discussion in an edit summary. Wikipedia:Village pump (proposals)#Turn off extended edit summaries takes up 71 characters, but with piping it may only display as a few, e.g. "see here". This change is extremely beneficial both for those who like to provide links to specific policies and guidelines that are being implemented within their edits and due to the fact that section headings without shortcut(s) (or those with only obscure, unknown ones) can take up a lot of space. Sure, some will leave 1000 displayed character edit summaries, but the benefit outweighs what is a small downside. If people are being foolish with edit summaries, leave them a kind note; if people are abusing edit summaries, leave them a warning. I can envision even a 1000 displayed character edit summary that is purely descriptive of a large copyedit; in other words, something due within an edit summary that would not be necessary or appropriate for a talk page. — Godsy^(TALK_CONT) 08:41, 3 March 2018 (UTC)[reply]
Support 1000 characters is far too long- if you need that much detail on an edit/revert, then there's a talkpage for that (as others have highlighted). Maybe 1000 characters is needed in German where individual words are much longer, but here on English wiki it's ridiculously excessive. Joseph2302 (talk) 11:28, 3 March 2018 (UTC)[reply]
Oppose 1000 is too long but 250 is too short. 500 would be nice. Or make it so only EC30/500 can use the full mount, nonEC and IPs have to stick with 250. L3X1 ◊distænt write◊ 12:28, 3 March 2018 (UTC)[reply]
Support I do not see the need to replace the talkpage by an edit summary The Banner talk 13:04, 3 March 2018 (UTC)[reply]
Oppose: 500 characters for experinced editors is enough, IP/newbies should be stuck with 250. KGirl ^{(Wanna chat?)} 15:46, 3 March 2018 (UTC)[reply]
Oppose I sometimes want more than 250. Agree it was too short before. Doc James (talk · contribs · email) 16:25, 3 March 2018 (UTC)[reply]
Support The community wishlist proposal was intended to benefit users of non-English languages who could only use about 30% of the available space because each of their text characters counted as 2-4 as compared to English. I do not remember the proposal being about a demand to make more text possible for English writing, or for writing in any language being longer than the equivalent amount of text and information as compared to English. The proposer highlighted what to me is obviously a major problem - the change has broken the status quo of English Wikipedia edit logs and this major disruptive change has happened without discussion. The solution is to put things back to the way they were before then start a conversation about the extent to which we should change the status quo. Many of the oppose votes here are out of order, because when anyone makes a major change to user experience in wiki and there is not community consensus for that, the start of the discussion is status quo, and not claiming to negotiate with the change as the new way and negotiating back to the established norm from that. WP:BRD applies here - the change was bold but challenged so now we revert and discuss from there. I agree that we need the ability to post links in the edit summary but exposing human readers to long URLs should never be allowed anyway. Expanding the edit summary for the sake of making humans read computer code in the edit summary is not a solution. Blue Rasberry (talk) 16:27, 3 March 2018 (UTC)[reply]

Actually, no. By policy software changes fall outside BRD. Alanscottwalker (talk) 16:53, 3 March 2018 (UTC)[reply]

@Alanscottwalker: Yes, in usual cases project wide software changes are not subject to BRD. I still claim that it applies in this case because WMF decisions beyond community review are valid when they make some attempt to acknowledge major problems which they would cause. The problematic outcome we are experiencing was never a consideration so reverting and talking it thought is more reasonable than alternatives. Obviously someone would have raised the issue if anyone imagined it; no one did. This problem is an oversight and not intentional. Also this action was supposed to benefit the community at the community's own request. The community has stake in the outcome of its own requests so enforcing this experimental new way of doing things is not an urgent indisputable need. Blue Rasberry (talk) 15:13, 4 March 2018 (UTC)[reply]

Urgent, what? It's clear the "community" went to the devs and said we do not like this arbitrary limit, so they, wholly within our policy, changed it to another arbitrary limit -- now, another part of the community is saying we like the old arbitrary limit and yet another part of the community is saying, the old arbitrary limit sucked, but there is and remains a limit. The arguments against the new limit all center around 'people act in bad faith' (which is generally not in fact, the case, and we, at any rate assume that it's not) or the peculiar case of the few who regularly pasted their entire comments instead of ever providing a summary (which, if that bothers the community, the community knows how to regulate, or practice will just change - or the community will just ignore it and go on) -- either way, as years of practice has seen (and common sense and human nature would expect), almost all people do not want to write more than they have to (which is a much greater controller than any arbitrary limit) -- as seen, if they write edits summaries, at all, they have either done a short summary or a very few have pasted what they already wrote. Alanscottwalker (talk) 16:00, 4 March 2018 (UTC)[reply]

The arguments against the new limit all center around 'people act in bad faith'... Simply not true. Poor judgment is not bad faith, and there is no WP:AGJ. ―Mandruss ☎ 16:04, 4 March 2018 (UTC)[reply]

So, we should now assume you have bad judgement, is your argument, or you oddly claim to know how to rescue people from their bad judgement. But no, the arguments are, people will abuse (bad faith) people will vandalize (bad faith) people can't control themselves (bad faith) -- they all center around bad faith - as for the people who can't improve their judgment to community standards, there have always been some, and the remedies for that have not changed, one iota. Alanscottwalker (talk) 16:15, 4 March 2018 (UTC)[reply]

So, we should now assume you have bad judgement, is your argument. Simply not true. You should not assume I have bad judgment, nor should you assume I have good judgment. Regardless, the AGF concept applies to how we regard each other individually; it does not mean that we have to apply a general "people are good" worldview in decisions like this. To whatever extent the Support arguments do consider that bad faith exists (far less than all, which is what you hyperbolically stated), I think we need to live in the environment that exists, not the environment that we wish existed. Anybody who says bad faith is too rare to factor into this decision needs to extract their head out of the sand. ―Mandruss ☎ 16:29, 4 March 2018 (UTC)[reply]

Get your head out of the sand of the imaginary world where you pretend to protect people from their bad judgment, (Wikipedia has a whole ethos on not doing that, called ROPE). No, there is actually no reason why half the people discussing here, should defer to your judgement. AGF is not a 'rule of social space' because it's imaginary, it's actually because people 'try to do the right thing' -- if people did not try to do the right thing, Wikipedia cannot exist. -- Alanscottwalker (talk) 16:49, 4 March 2018 (UTC)[reply]

Support. Discussion is for talk pages; edit summaries need only contain a very brief summary of what the edit does. If other languages need more space, then limit this change to the wikis in those languages. Kablammo (talk) 17:11, 3 March 2018 (UTC)[reply]
Support. Unlike projects with non-Latin writing, we have no need for so many characters in general; a 1000-Latin-character summary causes problems because of its length (it's 2/3 long enough for a WP:DYK article!), and it's virtually never necessary. I understand that there can be exceptions, but people like Doc James can use the gadget that expands the maximum length of the edit summary. Nyttend (talk) 20:27, 3 March 2018 (UTC)[reply]
Support per this edit summary. Unless rules are developed to ~~punish~~ prevent abuse and only specific needs for overrun are allowed, longer edit summaries are bad for the project. Chris Troutman (talk) 21:56, 3 March 2018 (UTC)[reply]

I don't think using an edit summary made by someone deliberately being WP:POINTy is good qualification for supporting the reinstatement of the very restrictive edit summary limit. Master of Time (talk) 23:26, 3 March 2018 (UTC)[reply]

I kinda disagree that is was POINTY behavior, as it was my own talk page, and rather than typing gibberish or unicode I wrote something constructive. For those who didn't click I wrote believes that rules should be written so that serial abusers who post hundreds of unicode characters and nonsense, and who specifically disrupt the histories, should receive sanctions ranging from receiving a personal limit of 250 characters to indefinite blocks for NOTHERE/CIR/trollish behavior. Another thing the I wish to note, if making it so EC30/500s get the 1000max is hard, make it so admins get access to the longer ES function, as Diaanna pointed out in the survey, URLs for copyright violations can be long themselves, and when you through multiple attack locations, you can run out of room quickly. In the TP use/abuse policies, clarify that communication is to take place on TP, not in the histories, and that NPA/CIVIL…. And Chris troutman, do I correctly interpret your above vote as "Until technical restrictions as to who gets to use long ES and/or polices are enacted, the edit summary length for the en.wiki should returned to its prior max of 250"? Thanks, L3X1 ◊distænt write◊ 22:02, 4 March 2018 (UTC)[reply]

@L3X1: Yes, that's it exactly. Chris Troutman (talk) 22:15, 4 March 2018 (UTC)[reply]

Oppose. How about 500? Kevin (aka L235 · t · c) 00:05, 4 March 2018 (UTC)[reply]
Support. Please turn this off. It's making a mess of watchlists and contribution histories. Frankly, it's annoying enough when people routinely used the full 255 limit. If there's a need to say more, "see talk" and a brief note there is better than filling up watchlists. SarahSV ^(talk) 00:12, 4 March 2018 (UTC)[reply]
- Odd, I have thousands of pages on my watchlist and it looks absolutely fine. Master of Time (talk) 00:40, 4 March 2018 (UTC)[reply]
Oppose (well partially anyway). I think it should be truncated a bit to 500 characters, as there's no way the full 1000 character summary is needed. But long summaries (such as undo of IPv6 users) will get chopped off if this is reverted completely. epicgenius (talk) 00:54, 4 March 2018 (UTC)[reply]
Oppose because the higher limit is useful for things like copyvio cleanup and reverting Ipv6 editors. I tend to be wordy in edit summaries because I like to explain what I did and why and having that extra limit (which I very much doubt I'd ever reach) is good for me. With respect to editors who copy their entire edit into the edit summary field, I found this practice to be annoying even before the increased character limit, as in this case the edit summary isn't actually a summary of the edit. I also don't need to see the same text twice (once in the edit summary and again on the page). I do support truncating the display of edit summaries in watchlists, etc, as discussed below. Ca2james (talk) 04:28, 4 March 2018 (UTC)[reply]
Oppose we should just be stricter about people misusing longer edit summaries eg. [3] [4] [5] [6] [7] [8] ·addshore· ^{talk to me!} 17:55, 4 March 2018 (UTC)[reply]
Oppose/leaning conditional Support As a page mover, I often come around when the 240ish limit is not enough. I generally pipe the links in summary so it becomes readable/accessible later while being seen in page history, and watchlist. An example would be special:diff/827568706. On a few instances, I had to use edit summary "moved per consensus on talkpage", as the link (without being piped) was taking a lot of characters. If there could be a workaround that, then I would support it completely. —usernamekiran(talk) 18:11, 4 March 2018 (UTC)[reply]
Support. By definition it is an edit summary. Surely those who call themselves "editors" should be able to summarize something in roughly 250 words. Readers can be directed to the talk page for longer explanations. [Which, I believe, is the function of talk pages]. Sunray (talk) 20:08, 4 March 2018 (UTC)[reply]
Oppose Actually, it is bytes not unicode characters. A UTF-8 character may contain up to four bytes. I've frequently been frustrated by the short edit summary limit, especially when much of it is taken up by auto-generated text. Hawkeye7 (discuss) 20:23, 4 March 2018 (UTC)[reply]
Support trimming it back to 255 or something like that. As noted above, long edit summaries enable editors to think that they have engaged in discussion when they have not. Robert McClenon (talk) 20:27, 4 March 2018 (UTC)[reply]
Oppose, since there's a JS fix below. Enterprisey (talk!) 21:47, 4 March 2018 (UTC)[reply]
Oppose a return to 255. I might support a limit of ~400 or 500, but 255 was often too short. --BrownHairedGirl (talk) • (contribs) 22:24, 4 March 2018 (UTC)[reply]
Oppose. There are a variety of situations where the capability of having a longer edit summary is useful, and all the disruption seems to be coming from the small number of metapedian editors who've developed the habit of copying the entire content of their post to a discussion page into the edit summary. Once these editors become aware of the issue, I don't think the issues are likely to continue. – Uanfala (talk) 23:53, 4 March 2018 (UTC)[reply]
Support—it's an edit summary, not an edit recapitulation. The unilateral, unsolicited change is a solution to a mispercieved problem. Including IVP6 twice in IP edit listings is the problem—solvable by a short place-holder link (an IP address summary). That is a task suitable to a simple algorithm. Condensing an edit summary is not easily done by Wikipedia software—it is a task for editors. If an editor can not summarize an edit enough enough for easy identification and justification, then perhaps the edit should be reconsidered. — Neonorange (talk) 00:21, 5 March 2018 (UTC)[reply]
Oppose More space can be useful for many tasks, as it has been noted by several editors. If clutter is a problem, just truncate at 255 the display, with a link to show the full comment, as it has been suggested above.--cyclopia ^speak! 00:27, 5 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. –xeno^talk 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]
- Seems useful, so as to not break workflows of people like you who paste in their comments.. Galobtter (pingó mió) 07:23, 2 March 2018 (UTC)[reply]
  - There used to be such a feature, but then edit summaries were increased to 255 characters for all users. oknazevad (talk) 19:00, 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]
  - I can't think of any genuine needs for edit summary visually longer than 255 chars or with a total length > 400 Galobtter (pingó mió) 07:11, 2 March 2018 (UTC)[reply]
  - I'm also wondering if long edit summaries will break any tools like huggle/stiki, or at-least not work well for them Galobtter (pingó mió) 07:11, 2 March 2018 (UTC)[reply]
  - I also support atleast temporarily disabling until this is fixed; also wondering if forcing short edit summaries may force people to the talk page atleast occassionally.. Galobtter (pingó mió) 07:19, 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]
      - I'm sorry my attempt to have a conversation with regards to how we can all improve is met with more finger pointing and stress than I care to engage with. I appreciate your feedback, but am ending my part in this conversation. Thank you. Ckoerner (talk) 23:10, 2 March 2018 (UTC)[reply]
        Sorry my attempts to get information out of people who defend making change this way were perceived that way. Of course, you are in your own right to not respond to WMF-related criticism over this situation, but the fact is that someone should. stjn^[ru] 10:21, 3 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]

WMF interacts with the editing communities? ^{[citation needed]}. Kablammo (talk) 00:46, 3 March 2018 (UTC)[reply]

- - - @Jytdog: - cause getting irrationally angry and all up in someones face like that with swearing is gonna help. Seddon ^talk 22:45, 2 March 2018 (UTC)[reply]
      - Yes anger is irrational. So is relentless fuckwittery from the WMF. Are you aware that Ckoerner is their fucking liaison person? Their comment above is probably the most incompetent piece of liaisoning I have ever seen. wtf. really. Jytdog (talk) 22:55, 2 March 2018 (UTC)[reply]
        Yikes. Yeah, that was quite a tone deaf response for a liaison. Lepricavark (talk) 23:02, 2 March 2018 (UTC)[reply]
        My comments here are in my role as a volunteer. If anyone has an issue with my performance as a staff member you are welcome to bring it to the attention of my supervisor. I'm stepping away from this...well, not quite a conversation, to enjoy my weekend. I hope you enjoy yours as well. Ckoerner (talk) 23:10, 2 March 2018 (UTC)[reply]
        
        @Lepricavark:Ckoerner made his post under his personal account, something that is perfectly reasonable and fine. So is calling for rational discussion and debate. What is not reasonable and fine is Jytdog's reaction. Our policies dictate that one remain respectful, even when one is upset. I would hope that you don't think that is behavior to be emulated. Keegan (talk) 23:18, 2 March 2018 (UTC)[reply]
        Yes, it's fair point to point out that Ckoerner was posting under his personal account. As he has walked away from the discussion, I'll leave it at that. Lepricavark (talk) 23:32, 2 March 2018 (UTC)[reply]
        I think WMF employees should be more aware that most people aren't going to see the distinction, and that it can cause frustrations with community members, but I also think that Legoktm's proposal to fix is a good one, and I understand Keegan's frustrations about how they are sometimes treated by the community (as one of the people most involved in implementing ACTRIAL from a community perspective, I am well aware that the WMF actually does want to do their best to help support the projects, and I appreciate that dealing with volunteers who think the worst of them can be frustrating and make them not even want to engage).
        I think this was a bad idea to rollout in the current form on en.wiki, but I get why it was done, and I am grateful that we have people thinking about other language groups who also should have access to a free content encyclopedia in their language of choice. They should be treated with respect in all circumstances, even when there is disagreement with actions of the foundation. TonyBallioni (talk) 01:10, 3 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. Ϣere SpielChequers 20:31, 2 March 2018 (UTC)[reply]

Community Wishlist team response

Hi everyone — I’m Trevor, a product manager at the Wikimedia Foundation with the Wishlist team. I’ve just read up on this entire thread and have conferred with some colleagues about this change. I’d like to start off with an apology — we’re sorry this caught you by surprise and we’re sorry for the interruptions it’s causing. We knew that this has been a big problem for non-Latin languages. We should have communicated more about the trade-off for English.

We agree that edit summaries should be brief updates to inform others about what an edit contains. It’s not an appropriate place to rant, converse, or ramble. We want to help alleviate potential abuse. The current suggestions we find most promising are:

Lego and 😂’s idea to truncate long summaries on Recent Changes, history, and other log pages with an an ellipsis that expands on click. This is very quick for us to build, test, and release.
Truncate long summaries on Recent Changes, history, and other log pages with an ellipsis that does not expand. To view the full summary, the diff page must be viewed.
Deathawk’s idea of displaying a warning when an edit summary is longer than average. This is a larger amount of work to support in all major editing tools and will take more time to build, test, and release.
ViperSnake’s idea of setting up an edit filter to monitor summaries so we can all gain a better understanding of how these long summaries are actually used in the wild.
Any others?

We propose truncating the summaries on history pages, etc. and exploring an edit filter to monitor the situation. We believe these will address the most common problems highlighted in the survey and discussion above. What do you think? — Trevor Bolliger, WMF Product Manager (t) 23:40, 2 March 2018 (UTC)[reply]

@TBolliger (WMF): I think there's a very strong consensus to truncate everywhere. There's somewhat of a debate between expandable or non-expandable, but if the information is stored, then it has to be accessible in someway, so expandable seems to make the most sense. No opinion on the edit filter, but that doesn't sound silly, so why not? Headbomb {t · c · p · b} 01:08, 3 March 2018 (UTC)[reply]

Hi Headbomb. Thanks for suggesting that expanding ellipsis is better. I agree. Do you want to test the expandable ellipsis JavaScript code I gave above? I believe if you put it in Special:MyPage/common.js then it would work. (I have also put it to User:Gryllida/js/truncateEditSummaryWithClickableEllipsis.js.) --Gryllida (talk) 01:22, 3 March 2018 (UTC)[reply]

@Gryllida: This is great, thanks for making this and sharing with us! When our team explores phab:T6717 next week we'll look into your script. I think the ellipsis could potentially be visually differentiated so it doesn't look like it's part of the summary. Also, on hover the cursor should be a clicky-hand so it's apparent an action occurs on click. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)[reply]

Added. --Gryllida (talk) 01:44, 5 March 2018 (UTC)[reply]

Hi Trevor Bolliger, WMF Product Manager. My opinions:

1. "truncate long summaries on Recent Changes, history, and other log pages with an an ellipsis that expands on click" COULD be opt-in: any interested contributor can enable this, and only for wikis which request this feature.

2. "Truncate long summaries on Recent Changes, history, and other log pages with an ellipsis that does not expand. To view the full summary, the diff page must be viewed." MUST be opt-in. A contributor making a long and legitimate edit summary probably wants it to be visible to others straight away.

3. You said, "Deathawk’s idea of displaying a warning when an edit summary is longer than average. This is a larger amount of work to support in all major editing tools". What are these major editing tools? Visual Editor already clips the edit summary to 255 characters anyway. (This is inconsistent, I would probably fix it?)

Codes for Wiki Editor, or users of no enhanced editing toolbars, with a threshold of 10 characters as this makes testing the code easier and quicker (you may adjust the threshold as needed):

shows long edit summary warnings from a javascript

Version 1: shows the warning as a text below the edit summary: [9]

Version 2: marks the counter in orange: [10]

Version 3: marks the counter in orange and draws an orange border around the edit summary box: [11]

Version 4: marks the counter in orange and draws an orange border around the edit summary box and shows a warning as a text below the edit summary: [12]

4. "setting up an edit filter to monitor summaries so we can all gain a better understanding of how these long summaries are actually used in the wild." this MIGHT be interesting. I do not find this terribly useful, but I do not mind this as long as it does not prevent the editor from saving the page. I would say such filters should vary per-wiki rather than being global.

--Gryllida (talk) 01:17, 3 March 2018 (UTC)[reply]

@Gryllida: Oh, correct. VisualEditor (and the 2017 Wikitext editor) already truncate at 250. In this case, we'd just need to change the behavior of the 2010 wikitext editor. On my first (Saturday morning) glance, I think I prefer version 1, but they could all be viable treatments. Another option would be like Twitter, where all characters after 140 (280?) are marked in red as a warning. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)[reply]

FYI, VE is still applying the old limit because the update for VE didn't make it into 1.31.0-wmf.23. It should be coming this week in 1.31.0-wmf.24; you should be able to test it now on the Beta Cluster. As for "highlighting in red like Twitter", might that confuse Twitter-using Wikipedians into thinking the summary can't be submitted? Anomie ⚔ 05:29, 4 March 2018 (UTC)[reply]

I know this would be more complex, but I still support a solution that doesn't care about byte limits and such stuff. In my opinion, there should be a limit of characters, and not of bytes, in the summary, that could be at something like 400. This resembles the spirit of the summary more as it isn't alphabet dependent anymore (except for east-asian languages with their exterme information per symbol ratio), and links wouldn't take away summary space anymore, while still the summary a summary instead of half an essay. Trunctating in the frontend at around 250 characters would still be useful in this case. Furthermore, in the long-term the IPv6-revert-like problems should be solved in my opinion by not prepending this to the saved summary anymore. This information should be stored in machine readable format (so it can be localized as well). I think this proposal would provide a solution for most of the problems outlined here, while I can't find any downsides right now except for its complexity.

However, I want to point out my disagreement to Legoktms point of view about the nature of this change. There was never any discussion how the additional database space should be used after it was provided. What's happening now wasn't really planned by anyone, it just happened. And it it's neither really elegant nor prepared. --MGChecker (talk) 02:28, 3 March 2018 (UTC)[reply]

@TBolliger (WMF):, thanks for these suggestions. One of the major concerns expressed by those preferring a longer edit summary limit is that IPv6 addresses can take up much of the previous limit. Is it technically possible to exclude the username (or IP for anons) from the character limit? This would let us specify a reasonable but concise limit for the actual content. Shock Brigade Harvester Boris (talk) 04:13, 3 March 2018 (UTC)[reply]

If the truncation can be done on displayed characters, that shouldn't much of an issue. Headbomb {t · c · p · b} 04:39, 3 March 2018 (UTC)[reply]

Maybe, but I'm not convinced truncation is a solution. The important part of the edit summary may or may not be within the non-truncated portion. It would be better to prevent people from writing essay-length edit summaries (by removing the opportunity to do so) than to truncate them arbitrarily. But I understand that may not be possible. Shock Brigade Harvester Boris (talk) 05:04, 3 March 2018 (UTC)[reply]

@Shock Brigade Harvester Boris: We would have to spend some time to determine the best way to design and implement this idea, but it would be possible to exclude usernames (and potentially other links) from the the edit summary length. I think we can find a simpler solution as an alternative, though. I'm really curious to see what the results of the edit filter are to understand which types are surpassing the 255. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)[reply]

No matter what angle we view this issue from, I think a filter to track long edit summary usage is helpful. I've created one at Special:AbuseFilter/904. — MusikAnimal ^talk 07:38, 3 March 2018 (UTC)[reply]
- @MusikAnimal: Thank you! Let's keep an eye on it and perform some analysis on Monday. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)[reply]
- Several editors have pointed out that long IP addresses can fill up much of the edit summary box, making it difficult to fit in anything else within a limited character field. My approach to this, when it occurs, is to manually delete the auto-generated bit of the summary, and replace it with something like "reverted previous IP edit/s", which is very readable and short enough to allow quite a lot of explanation afterwards, should that be necessary. PaleCloudedWhite (talk) 08:46, 3 March 2018 (UTC)[reply]
  - @PaleCloudedWhite: The revert and undo auto-generated messages are easily customizable via MediaWiki message. I think it'd be valid to have a separate discussion outside this RFC (there's already a lot going on here) if you wanted to propose such changes. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)[reply]

I don't understand what you're saying, as I haven't proposed any changes. I only said that my way of dealing with overly long auto-generated edit summaries is to manually remove them, and add my own instead. PaleCloudedWhite (talk) 18:15, 3 March 2018 (UTC)[reply]

@TBolliger (WMF): the thing is, are these suggestions permanent or temporary? You don’t say anything about this in your comment. If they are permanent, then sure there is no convenience at all in having some parts of edit summary cut off by default and not displayed until you click on it. But if they are temporary, then it doesn’t matter and we can put any bandaid to it. This is an important distinction, since we can’t discuss this without acknowledging first and foremost whether or not this 1000 characters long edit summary stays or not. stjn^[ru] 10:21, 3 March 2018 (UTC)[reply]

@TBolliger (WMF): It'd be better if edit summaries were capable of being expanded and viewed no matter what page you're on, rather than truncating them on some pages without the possibility of viewing the full summary. Viewing lots of edit summaries is a common action for administrators, checkusers, and oversighters, and having to load a diff page to view the full summaries will make that job considerably more tedious. There's quite a bit of mental overhead if you have to load an entirely new page to view the longer edit summary, especially if you need to see a lot of summaries. There's also the literal bandwidth overhead, since the longer edit summaries on those pages represents only a few kB of extra data, whereas loading the diff page is several orders of magnitude more than that; this is exacerbated if the truncation is performed on the client, since all the data would be transmitted anyway. I remain thoroughly unconvinced that the longer summaries can cause "massive disruption", but collapsing longer summaries seems to be a good improvement to the user experience regardless. --Deskana (talk) 20:03, 3 March 2018 (UTC)[reply]

I'd support an expandable summary on all pages - but the diff page should probably show the full summary by default. ∰Bellezzasolo✡ Discuss 20:15, 3 March 2018 (UTC)[reply]

Yeah, that makes sense. It could be collapsible everywhere with it expanded by default on the diff page and collapsed by default everywhere else, or maybe just not collapsible at all on the diff page but collapsible everywhere else. The former is probably a more consistent experience. I don't really know what I'd prefer. Either would be fine. --Deskana (talk) 20:29, 3 March 2018 (UTC)[reply]
This change makes the code apply only outside of diff viewers. --Gryllida (talk) 03:43, 4 March 2018 (UTC)[reply]

I'd prefer along with truncating, reducing the level to 6 or 700 for non admins, and 1000 for admins. Also, I'd suggest a policy implemented to the tune of Any editor who makes what would generally be accepted as an useless, POINTY, or otherwise excessively long ES regardless of content or length will be warned and if they continue, blocked for disruption. Exceptions are for those who have made 3 or less long ES, even if they are all gibberish {because not everyone will have discovered it, or known that policy was enacted, and through Good Faith may we wanting to test it out}, or for anyoen who copies and pastes their edit into the ES box, whether it is for a TP or any other page. While the practice of copy/pasting your edit into the dit summary box is discouraged and frowned upon, the ban of the practice would be impractical and despotic. Any non AC account typing MORE THAN 250b of gibberish to accompany a blank or so-so edit may be blocked per admins discretion for disruption. Howzaboudat? L3X1 ◊distænt write◊ 22:16, 4 March 2018 (UTC)[reply]

Also the word be spread regarding RD policy:

users may request oversized summaries to be redacted on their UP and TPs,
for normal articles and talk pages, they may be redacted at admin discretion IF there a plethora of them, ill intent is SUSPECTED (I know I know, but AGF is not a suicide pact), or they are mere gibberish/otherwise obviously unconstructive,
same for the Wikispace, and on the userspaces of banned of blocked users.
I do not recommend action to be taken against anyone who may have abused or otherwise experimented with the bug/feature, as some of it was very much POINTY, to illustrate a point to the WMF. The WMF, not being either a Living Person, not part of the en.wiki, is not protected under POINT. :)

TLDR If Iridescent wished to revdel all the huge ES on her page, she could. Basically re-iterating that RD3 and RD6 apply, because my read through of them doesn't convince me that they apply. L3X1 ◊distænt write◊ 22:26, 4 March 2018 (UTC)[reply]

I'd say that sanctions for these edit summaries fall under disrruptive editing, we don't need a new policy (perhaps just comment on DISRUPT that this includes edit summaries). POINT is about disrupting WP to make a point. It clearly doesn't matter that the recipient of the point is the WMF. ∰Bellezzasolo✡ Discuss 23:13, 4 March 2018 (UTC)[reply]

@@ Line 668: / Line 668: @@
 :Hi [[User:Headbomb|Headbomb]]. Thanks for suggesting that expanding ellipsis is better. I agree. Do you want to test the expandable ellipsis JavaScript code I gave above? I believe if you put it in [[Special:MyPage/common.js]] then it would work. (I have also put it to [[User:Gryllida/js/truncateEditSummaryWithClickableEllipsis.js]].) --[[User:Gryllida|Gryllida]] ([[User talk:Gryllida|talk]]) 01:22, 3 March 2018 (UTC)
 ::{{ping|Gryllida}} This is great, thanks for making this and sharing with us! When our team explores [[phab:T6717]] next week we'll look into your script. I think the ellipsis could potentially be visually differentiated so it doesn't look like it's part of the summary. Also, on hover the cursor should be a clicky-hand so it's apparent an action occurs on click.  — [[User:TBolliger (WMF)|Trevor Bolliger, WMF Product Manager]] ([[User_talk:TBolliger (WMF)|t]])   18:05, 3 March 2018 (UTC)
+:::[https://en.wikipedia.org/w/index.php?diff=828837334&oldid=828687338&title=User%3AGryllida%2Fjs%2FtruncateEditSummaryWithClickableEllipsis.js&type=revision Added]. --[[User:Gryllida|Gryllida]] ([[User talk:Gryllida|talk]]) 01:44, 5 March 2018 (UTC)
 ::Hi [[User:TBolliger (WMF)|Trevor Bolliger, WMF Product Manager]]. My opinions:
 ::1. "truncate long summaries on Recent Changes, history, and other log pages with an an ellipsis that expands on click" COULD be opt-in: any interested contributor can enable this, and only for wikis which request this feature.