Community Wishlist Survey 2017/Editing

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Community Wishlist Survey 2017
Editing
25 proposals, 372 contributors



Provide easy interface for replacements in the Visual Editor

Edit proposal/discussion
  • Who would benefit: At least fawiki, hewiki, rowiki and ruwiki users, presumably many more
  • Proposed solution:
    What most of the scripts needs are:
    • A utility function for doing replacement (similar to ve.dm.Document.prototype.findText maybe ve.dm.Document.prototype.replaceText)
    • The replacement should be able to keep the annotations
    • Advance use: sometimes (as you can see in fawiki) replacements are context aware. It may be too far to support such complex replacements within ve itself, but providing documentation how to do it would be great.
  • More comments:
    • Moved from Bots and gadgets to Editing as we supposedly would want a general solution rather than a gadget on a few select wikis. Max Semenik (talk) 19:48, 8 November 2017 (UTC)Reply[reply]

Discussion[edit]

  • I support this request. I think this is a major blocker for advanced gadgets for VisualEditor, hence blocker for wider adaption of VE for experienced users. eranroz (talk) 10:36, 17 November 2017 (UTC)Reply[reply]

Voting[edit]

VisualEditor: Allow editing of auto-generated references before adding them

Edit proposal/discussion
  • Problem: It's only a small thing but one that bugs me. When you use the VE's ability to autogenerate a reference based on a URL, oftentimes there will be need to manually fix the generated ref. However, currently you have to first save the incorrect reference before editing it.
  • Who would benefit: Everyone using VE
  • Proposed solution: I propose another button "edit" on the autogenerated reference besides add to fix mistakes immediately.
  • More comments:

Discussion[edit]

Similar, yes, although that solution would skip the "insert" button which my proposal would keep. On a side note, people should really use better descriptions of their feature requests in Phabricator because when searching for previous proposals, I could not find that one. Regards SoWhy 16:39, 13 November 2017 (UTC)Reply[reply]
  • Note, you don't currently need to save, only to insert. After inserting you will get a preview, which has an Edit button. —TheDJ (talk • contribs) 17:38, 29 November 2017 (UTC)Reply[reply]
    In VE, but that doesn't work in WTE 2017. --Izno (talk) 19:04, 29 November 2017 (UTC)Reply[reply]
  • I have to edit references quite often, mostly to go from "cite news" to "cite web" (or whatever it's called in English). From what I understand, this wouldn't cover it? Exilexi (talk) 08:23, 21 December 2017 (UTC)Reply[reply]

Voting[edit]

Make it possible to format tables in VisualEditor

Edit proposal/discussion
  • Problem: Currently it's not possible to do many different things for tables using visual editor. You can add rows and columns, but you can't for example add background colours or set text alignment. You always need to change to the wikitext editor if you want to add background colours, and for newbies it may be very difficult to add html code.
  • Who would benefit: Table editors.
  • Proposed solution: Implement more tools for table editing.
  • More comments:
  • Phabricator tickets: phab:T54180, phab:T103276, phab:T99890
  • Proposer: Stryn (talk) 18:38, 16 November 2017 (UTC)Reply[reply]
  • Translations: none yet

Discussion[edit]

Inline styles are both technically inferior (they make it impossible to have different presentation for different devices, screen sizes etc) and result in poor readability and maintainability of the wikitext. We shouldn't encourage them. TemplateStyles should be the preferred solution for table styling. (That still requires the ability to edit classes of table cells, if not their other properties, though.) --Tgr (WMF) (talk) 12:22, 18 November 2017 (UTC)Reply[reply]

There are some pretty valid uses, such as aligning text right for number values as well as setting sort values on individual cells. (Though, I agree, the typical "PRETTY COLORS!" type is pretty obnoxious.) --Izno (talk) 03:53, 19 November 2017 (UTC)Reply[reply]
There are valid use cases for formatting table cells, but editing inline CSS is not the right implementation for them. Define the styles somewhere else and implement some kind of HTML class editor in VisualEditor. --Tgr (WMF) (talk) 06:27, 19 November 2017 (UTC)Reply[reply]

Don't get stuck on the discussion above as to what should be possible with tables in VE. Merging/separating cells, copy-pasting to/from excel/libreoffice and many more are possible.--Strainu (talk) 15:31, 26 November 2017 (UTC)Reply[reply]

Isn't this basically the same as the first one: Community Wishlist Survey 2017/Editing/More table types in editing section? Maybe they should be merged together. --Dvorapa (talk) 09:05, 28 November 2017 (UTC)Reply[reply]

I wonder whether this should include phab:T180867/phab:T169306. Whatamidoing (WMF) (talk) 19:24, 1 December 2017 (UTC)Reply[reply]

Voting[edit]

VisualEditor: Allow references to be named

Edit proposal/discussion
  • Problem: One cannot enter a name for a reference in the VisualEditor which will assign ":0", ":1" automatically to references used multiple times.
  • Who would benefit: Everyone using VE
  • Proposed solution: Allow editors to assign individual names to references when clicking on a reference in the VE
  • More comments: According to the Phab ticket, it was deemed too complicated for Q3 back in 2015 but since then there was no further updates. I'm certainly not a master coder but I don't see how this is really a complicated problem, considering that apparently this was once possible and has been removed.

Discussion[edit]

Endorse. A piece of code of type <ref name=":0"> is ugly and very unhelpful (especially when editing in wikitext mode). --Vachovec1 (talk) 10:48, 11 November 2017 (UTC)Reply[reply]

Agree with above. Maybe take the first authors last name and add the year of publication to it? Doc James (talk · contribs · email) 21:52, 13 November 2017 (UTC)Reply[reply]
Endorse. A user came into -help with this exact concern and some ideas were discussed around it, eluding to the auto-generation Doc James is mentioning. There seems to be some good suggestions in the comments of the phab tickets. Although it gets a bit iffy for online references. One person suggested domain, underscore, page name (If only a bare url is given) (e.g. bbc_magazine-23969607), which isn't horrible but not a ton better than just [domain]-[sequential number]. Either way, this is a vast improvement over the current system. Drewmutt (^ᴥ^) talk 03:37, 14 November 2017 (UTC)Reply[reply]

Endorse. If there's one thing I hate, it's reffing an article in VE then having to tediously go back through in source mode to rename all the refs. Premeditated Chaos (talk) 23:30, 14 November 2017 (UTC)Reply[reply]

There are two problems being conflated here:

  1. Allowing manual addition of reference names
  2. Automatically generating a reference name based on properties of the reference

The difficulty of solving the first problem depends on the class of user you're aiming the solution at. If you're aiming it at advanced users, it doesn't seem to difficult, for example, to add a reference name field to the dialogue shown when you edit a reference. I don't know exactly where it'd go, but that doesn't seem too complex to figure out. If you're aiming it at new users, it's significantly more complex. Newer users using visual editor probably won't understand what a "reference name" is given that it doesn't affect anything about the article layout in visual editing mode, so you'd need to explain it to them. Putting it in the edit dialogue is probably too late for them, so you'd need to add it earlier in the workflow, which would increase the complexity of the basic workflow of adding a citation, which does not seem like an acceptable tradeoff. So, designing it for newer users would involve a lot of time and thought, since the risks of disrupting their workflows are much higher.

The second problem isn't too complicated in principle, but the devil is in the details. The biggest issues are hash collisions and incorrect assumptions about the structure of references, see phab:T169841#3411881 for more details on that. A fallback would be necessary, which would likely be the numerical system. These problems can be mitigated of course, but we might end up with a situation that isn't much better than the current one. That could be acceptable if the current situation is suboptimal enough.

A combination of these two solutions might be nice; use some automated system to generate nice(ish) reference names to solve the problem with newer users, and add a reference name field to the edit reference dialogue for advanced users. That means the workflows of new users are not changed at all, and advanced users have nice ways of changing things in the visual editing environment.

For the record, since I've often had people quote thinking-out-loud brainstorming like this like it's some form of immutable truth, I want to point out quite clearly that brainstorming is exactly what this post was. Things could turn out to be more simpler or more complex than I imagine, or the solutions I brainstormed here might not be the ones that are worked on, if the item is worked on at all. :-)

--Dan Garry, Wikimedia Foundation (talk) 12:55, 17 November 2017 (UTC)Reply[reply]

@Deskana (WMF): My post was about the first one, which should be easy. Useful autogenerated names would be neat but it would usually be sufficient to be able to name them manually. I do think the auto-generate problem should be a separate post here to avoid said conflating. Regards SoWhy 18:06, 18 November 2017 (UTC)Reply[reply]
I'd use a manual field myself, but a simple automatic one shouldn't be difficult--such as the first character of the title field if present followed by a number, or the year field similarly. DGG (talk) 02:13, 20 November 2017 (UTC)Reply[reply]
Hi, Deskana (WMF). There is no conflatulence. We mortal editors are not permitted to create named references that are numerical only, and nor should VE be allowed to do it with a colonic workaround. Having fun! Cheers! Checkingfax (talk) 21:05, 4 December 2017 (UTC)Reply[reply]

Voting[edit]

Review individual edits

Edit proposal/discussion
  • Problem: Revisions may persist for long periods of time because they're good edits and no one has a problem with them, or they may persist for long periods of time while being bad edits, simply because no one has noticed them and reverted them. Editors waste time verifying revisions that have already (silently) been verified by other people, while not noticing ones that haven't been reviewed.
  • Who would benefit: Editors, everyone
  • Proposed solution: Have an "upvote" or "reviewed" button next to revisions that indicates that you've looked through the diff and verified that it's a good change. A number on the revision history log will indicate how many people have reviewed it.
  • More comments: This would have no bearing on what revision is shown to viewers or anything like that. It would just be a helpful way to see at a glance which revisions have been checked by real human beings and are considered trustworthy/valid, and which diffs have not been viewed, and may need more attention to catch vandalism or poor quality changes. It's also psychologically similar to the "Thanks" feature, in that people can see that their edits were approved/appreciated by others and they aren't laboring in vain. It would also show editors that the revisions they're undoing were approved by multiple other people, making them think twice before wholesale revert warring. It would also help in finding the original source of subtle vandalism that has gone unnoticed for a while, so it can be reverted.
  • Phabricator tickets:

Discussion[edit]

mw:Help:Patrolled_edits exists. Not sure if what you're asking for is covered at least partially by https://phabricator.wikimedia.org/T25792, https://phabricator.wikimedia.org/T147012, https://phabricator.wikimedia.org/T19237, or other tasks that exist on the subject. Elitre (WMF) (talk) 15:31, 13 November 2017 (UTC)Reply[reply]

FlaggedRevs can be configured to work like that. --Tgr (WMF) (talk) 12:13, 18 November 2017 (UTC)Reply[reply]

@Omegatron: There are already technical solutions to this (as mentioned above). Do either of those meet your requirements? Kaldari (talk) 19:28, 20 November 2017 (UTC)Reply[reply]
Those look similar, but no, not the same. This would not "set those revisions as the default revision to show upon normal page view" or require "a 'patrol' permission", and multiple people could approve the same revision, not a binary approved/unapproved state. — Omegatron (talk) 01:41, 21 November 2017 (UTC)Reply[reply]

I agree completely with @Omegatron: that users need a way to know whether edits have or have not been reviewed by someone. A solution for this does exist already—it’s called the RCPatrol flag. Almost 100 wikis use RCPatrol today, but it was turned off on English Wikipedia and many others. @Quiddity: researched this situation recently and assembled a very clear analysis, along with recommendations. It’s an enlightening read.

I strongly recommend that RCPatrol be turned on for English and all other wikis. Once it is on, it will be a simple matter to, for example, implement a filter for Patrolled/Unpatrolled on Recent Changes and Watchlist. The various issues that people had with RCPatrol (such as the ! symbol on Recent Changes, which displeased many) can be addressed easily, in my opinion.

The fact that a technological solution exists already for this will help tremendously with getting it done, but it does not negate the value of this proposal. There are technological, design and community issues that must be worked through in order to turn RCPatrol on. Having community behind such a proposal would make success much more likely.

Omegatron, would RCPatrol solve your problem? If it does, perhaps it might be a good idea to rephrase the Solution section somewhat, to make it more about the general goal, and to retitle the proposal along similar lines. E.g., Have a way for editors to know if an edit has been reviewed. JMatazzoni (WMF) (talk) 20:51, 22 November 2017 (UTC)Reply[reply]

Both patrolling and FlaggedRevs can be used coordinate one review per revision (without necessarily changing what revision the reader sees) and both are integrated with the existing patrol/review tools. Neither really supports multiple reviews though. Patrolling can't even store them (it's just a per-revision boolean flag); FlaggedRevs allows multiple reviews (with comments, optionally) per revision but only the last one is exposed in the UI, the rest only show up on Special:Logs. Also since English Wikipedia uses FlaggedRevs for flagged protection already, if you want to allow anyone to review revisions without interfering with that, you'd have to introduce a new review level which would make the configuration and UI more convoluted.

OTOH the requirement to have multiple reviews per revision seems somewhat disconnected from the problem statement. --Tgr (WMF) (talk) 00:12, 24 November 2017 (UTC)Reply[reply]

Voting[edit]

  • Support Support --Liuxinyu970226 (talk) 13:04, 28 November 2017 (UTC)Reply[reply]
  • Support Support Also allows to view the list of reviewers and make a comment? --YFdyh000 (talk) 14:06, 28 November 2017 (UTC)Reply[reply]
  • Support Support Thomas Obermair 4 (talk) 21:46, 28 November 2017 (UTC)Reply[reply]
  • Support Support Support what I believe is the principle, noting that in the discussion are hints to several implementations, some using existing infrastructure. The main principle to me, is to enhance cooperation and collective assessment. Currently we have mostly a sequence of individual decisions (one editor writes, one editor patrols, one editor(admin) blocks, and so on. We need more "collective" tools. (Lots of work that-a-way, I'll add no more now) Nabla (talk) 21:22, 30 November 2017 (UTC)Reply[reply]
  • Support Support User Risk Engineer, (talk) 21:22, 30 November 2017 (UTC)Reply[reply]
  • Support Support Braveheidi (talk) 07:11, 1 December 2017 (UTC)Reply[reply]
  • Support Support Krinkle (talk) 19:31, 1 December 2017 (UTC)Reply[reply]
  • Support Support If it's determining whether an edit constitutes vandalism or not, then really anyone could review it and the old tools could work just fine. But most of the edits that require reviewing (at least in my topic area) are good-faith edits that are more or less subtly misinformed, incompetent or biased, and there is only a small number of editors whose judgement I would trust to spot these flaws. Who has reviewed the edit matters a lot. Uanfala (talk) 01:47, 2 December 2017 (UTC)Reply[reply]
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 14:22, 2 December 2017 (UTC)Reply[reply]
  • Support Support Emir of Wikipedia (talk) 16:04, 2 December 2017 (UTC)Reply[reply]
  • Support Support Joshualouie711 (talk) 02:17, 3 December 2017 (UTC)Reply[reply]
  • Support Support -- seth (talk) 11:09, 3 December 2017 (UTC)Reply[reply]
  • Oppose Oppose Plays into the hands of article owners, making it easier for a person to act as gatekeeper of an article, rejecting any change from an outsider with which he disagrees. Giraffedata (talk) 22:18, 3 December 2017 (UTC)Reply[reply]
  • Support Support Ciao • Bestoernesto • ✉ 02:51, 4 December 2017 (UTC)Reply[reply]
  • Support Support This could also be useful for AI. Doc James (talk · contribs · email) 02:23, 5 December 2017 (UTC)Reply[reply]
  • Support Support Great idea: perhaps aletter R (or blue thumb up emoji resp. red thumb down) with a number  Klaas `Z4␟` V:  21:39, 6 December 2017 (UTC)Reply[reply]
  • Support Support Ahm masum (talk) 08:45, 7 December 2017 (UTC)Reply[reply]
  • Neutral Neutral Don't like the thumbs-down option; we have enough negative feedback channels that scare new editors already. But I'd like to edit an article without feeling that I'm tacitly approving all the past edits unseen. Is "So-and-so thought this edit useful" then just going to be a milder version of thanking? Would making the thanks record visible on the history page be similar? HLHJ (talk) 06:28, 8 December 2017 (UTC)Reply[reply]
  • Support Support — J.S.talk 15:34, 8 December 2017 (UTC)Reply[reply]
  • Support Support I like upvoting things! RandomDSdevel (talk) 01:46, 9 December 2017 (UTC)Reply[reply]
  • Oppose Oppose, please do not create one more edit patrolling/reviewing system, develop existing ones instead. I think this is feasible with some customised configuration of FlaggedRevisions — NickK (talk) 16:23, 11 December 2017 (UTC)Reply[reply]

Ping users from the edit summary

Edit proposal/discussion
  • Problem: I recently saw a person wondering how to notify someone of a change, without necessarily leaving a message on the chat page.
  • Who would benefit: Every editor
  • Proposed solution: The solution would be to allow notifications when a user page is linked in a change summary.
  • More comments: A recurrent subject, which has not yet been resolved. It doesn't seem so complicated to implement. There would surely be some details to review, such as revert messages that send useless pings.

Discussion[edit]

I agree it is very time consuming to try and communicate with every editor/user one encounters. Even sending thanks can be cumbersome. There are also other reasons users are reluctant to post on a talkpage. Ottawahitech (talk) 14:50, 18 November 2017 (UTC) Please ping meReply[reply]

There was a similar request on the huwiki village pump (where we were collecting ideas for the wishlist) for pinging users from the FlaggedRevs review summary (the optional comment field when you mark an edit as reviewed). --Tgr (talk) 06:40, 20 November 2017 (UTC)Reply[reply]

@Framawiki: do you have any idea how this should work? The summary field is already short and I am hesitant to support a proposal which can shorten it even more. Perhaps a secondary field for names of pinged users? --Vachovec1 (talk) 21:32, 27 November 2017 (UTC)Reply[reply]

"The summary field is already short" It is planned to deploy allowing for longer comments very soon (this was worked as part of a previous year wish), so that should not be a large concern. --JCrespo (WMF) (talk) 15:40, 28 November 2017 (UTC)::to propose a new field, why not. I don't really see the benefit.Reply[reply]
Vachovec1: To propose a new field, why not. But I don't really see the benefit to add something else to this well complicated system. For how to implement this, it is also possible to manage this after the vote, or let the team decide :)
The only problem I see with the implementation of this idea, which has already been written somewhere, is the risk of edits escalating, which would be a means of discussion. But it seems fair enough to me. --Framawiki (talk) 21:08, 28 November 2017 (UTC)Reply[reply]

Since one of the comments below mention this, I would suggest that we integrate this with the way in which we have proposed support of "hashtags" as well in edit summaries: https://phabricator.wikimedia.org/T123529 . The idea being that edit summaries could be a tool for tracking both relationships to individuals activities (hence the ping suggested here), or to larger campaigns of activity (i.e. a WikiProject, event, or editing campaign in the vein of WikiProject Women in Red). Making the edit summaries more "connected" with the activities throughout the ecosystem -- would make it much easier to build tracking and coordination tools, to help folks feel like their work is part of larger efforts. Sadads (talk) 13:52, 1 December 2017 (UTC)Reply[reply]

  • Note that some projects has banned polemic in the summary field, and allowing discussions with other users in the summary field would go against this. That said I believe this is a bad idea in general, as notifying other users should be part of the general notification structure. A small number of predefined notifications could be sent to other users that has the page on their watchlist. They should be predefined, otherwise the total workload increase as the messages must be wetted. — Jeblad 23:17, 10 December 2017 (UTC)Reply[reply]

Voting[edit]

Wikitext substitutions should work in ref and gallery blocks

Edit proposal/discussion
  • Problem: Links ending in |]], substitutions with {{subst: and tilde-timestamps (~~~~~) don't behave as expected within <ref> and <gallery> blocks. (Amongst others.)
  • Who would benefit: Article wikitext editors.
  • Proposed solution: Resolve that substitution and pipe tricks work inside other mediawiki tag extensions
  • More comments: More generally speaking: common wikitext substitutions that editors would expect to work in all reader-visible places, do not work in some contexts.

    mw:Extension:Cite has not evolved with other components of wikiediting. Substitution (subst:) and pipe tricks from inside custom tags like <ref> fail unless one pushes with more complicated use of {{#tag:}}. Such use can be problematic due to the misinterpretation of | and {{!}}. To note that the identified problem also applies to use of <poem>.

  • Phabricator tickets: T4700: Pre-save transform skips extensions using wikitext (gallery, references, footnotes, Cite, status indicators, pipe trick, subst, signatures)
  • Proposer: bdijkstra (talk) 16:49, 8 November 2017 (UTC)Reply[reply]

Discussion[edit]

Voting[edit]

Find & Replace feature

Edit proposal/discussion
  • Problem: It is hard to observe wrong punctuation
  • Who would benefit: every Visual Editor user
  • Proposed solution: Create a button in the Visual Editor in the Find & Replace dialogue to mark non-typographic Quotation marks, non-typographic apostrophes, wrong dashes and double spaces etc and then the editor can decide whether it has to be changed or not.
  • More comments:
  • Phabricator tickets:
  • Proposer: Dexxor (talk) 10:12, 18 November 2017 (UTC)Reply[reply]
  • Translations: none yet

Discussion[edit]

Voting[edit]