Grants:IdeaLab/Edit annotation

status: idea

IdeaLab	meet more people	visit more ideas
join other ideas

project:

Edit annotation

idea creator:

Gryllida

project contact:

WikimediaEditMetadatagryllida.fastmail.fm

participants:

join this idea!

summary:

Want to thank for an edit? Want to undo but too lazy to add comment? Vandalism warning templates and WikiLove too dry and generic? Too much anti-vandalism manual work? Do it server-side.

created on: 10:44, 9 December 2013

Note: You can comment at the talk page.

Project idea

Interface

Post-thank and post-undo reminders

Edit of Example was undone. Annotate it?

Example has been thanked for this edit. Annotate it?

Edit annotate dialog

Figure 2. Annotate dialog

Diff viewer interface changes (outdated idea per feedback at the talk page)

Note: The idea author questioned need in of this section after getting feedback, and it is no longer a part of the idea draft. It is kept for historical and brainstorming purpose only.

Add an annotate link.

Latest revision as of 00:04, 1 January 2014 (edit) (undo) (thanked; annotate?)
Gryllida (talk , contribs)
(→Edit annotate dialog: update)

Latest revision as of 00:04, 1 January 2014 (edit) (undo) (thank) (annotate)
Gryllida (talk , contribs)
(→‎Edit annotate dialog: update)

Message shown to contributor

As Flow appears to let messages be attached to multiple objects, a new thread «Discussion of [Revision_1234 My Article (2013-12-27T02:28:33)]» would be created attached to

user talk who made the edit
the article talk
a specific edit, so the thread is visible in diff viewer

Shows:

Article name.
WikiProject the article belongs to, suggesting to join.
Comment from the person who annotated the edit — important!
Links to relevant policies, as it's currently done now.

Does not show:

Threats to block.

Problems it tries to solve

Need in more human interaction with new contributors.
Things like templates at Wikipedia:Recent changes patrol, edit-thank function, and Wikipedia:WikiLove, often come without a personal comment, occasionally frustrate or anger contributors, rather frequently leave impression of «clogged» talk pages.

2. Recent Changes Patrol automation (outdated idea per feedback at the talk page)

Note: The relevancy of this section has been questioned on the talk page, and it is no longer a part of the idea draft. It is kept for historical and brainstorming purpose only.

Note: Making Recent Patrollers life easier was proposed by automation, but considered redundant.

Need in automating manual routine Recent Changes Patrollers work.
Their work involves manual or scripted read of contributor's history, required to access warning level for a destructive contributor edit.

(This need is debatable, as mentioned at the talk page. More human interaction already eases the patrollers work and user experience.)

Project goals

Automated anti vandalism (outdated idea per feedback at the talk page)

Note: The relevancy of this section has been questioned on the talk page, and it is no longer a part of the idea draft. It is kept for historical and brainstorming purpose only.

A lot of the recent changes patrollers valuable time goes to manual scanning, be that scripted or not, of previous edits of a contributor to determine how fatal a warning to dispatch. In short, the current patroller's workflow is like follows:

Undo an edit. Enter comment at the end of the standard undo line (often skipped due to unsurprising laziness).
Read user's talk page and contributions to determine how much a trouble he had been before.
Add a warning of the required level of severity (manually or scripted) as a template without human note.
Enjoy frustrated, angered contributors who don't feel human approach.

In this idea it is proposed that server-side work is carried out to access the contributor's previous history and set a warning level automatically. (The Rate field of the annotate dialog is used to evaluate contributor's edits, and if an edit is rated negatively the personal comment is shown to the user with corresponding pointers to policies; after a few negative rates, contributor is brought to attention of sysops.)

Feedback to contributors: better user experience

Due to the current wording of warning templates and the busy time the patrollers get trying to access the level of severity of the desired warning, troublemakers get warning templates on their talk pages which create a «oh, my talk page is clogged» experience more than a desire to look at anything useful to do. Such warning templates most frequently contain invites to sandbox (and sometimes threats to be blocked but the templates tone and being generic is a larger problem at low warning levels).

A focus of this idea is the ability to add notes when undoing and thanking which are visible to the contributor who made an edit. These notes would be shown to the contributor in his talk page or notification centre or some like. Such flow would have an impact on feedback newcomers get on their first edits and significantly improve their initial experience getting started.

Apart from improving the user experience with warnings, such flow could come as a change from the current system where undoing comes with an edit summary the contributor has to manually view in history or diff viewer, and thanking comes with no comment by default ('thank' button doesn't have a comment option while WikiLove's interface involves many clicks and does not appear to encourage personal comments, leaving the comment field empty by default and not many people use it).

This project does not aim to be a tool for reviewers or authors only. It's a readers' tool to access edits too if they like.
- This idea may be implemented as an on-by-default gadget or a wiki feature to target an average contributor.
- This idea may not be implemented as a part of Twinkle or other advanced tools an average contributor does not use.

Miscellaneous

Make this tool available for all users, logged in or not.

Not project goals (outdated idea per talk page feedback)

Note: The relevancy of this section has been questioned on the talk page, and it is no longer a part of the idea draft. It is kept for historical and brainstorming purpose only.

This project does not aim to introduce badges, karma, rank for contributors. It's easy to do so, but not user profile nor article history should be concerned. Such function is not necessary to meet project goals and may be harmful; a careful multi-language multi-project attention is necessary before making steps forward. This would have to be separate project.
- Edit rate is only shown for the specific edit. User «rank» used by the anti-vandalism module of this idea should be private, or only visible to sysops.

Integration with existing tools and projects

This tool may integrate with Diff preview, most notably. Contributors can add comments for the edit and rate it. If rating is negative, the edit may be undone. There may be multiple comments per edit.

Integrates with these tools:

Flow — this idea may integrate with Flow to attach a thread to an edit rather than, or together with, attaching it to an article: such thread will be visible to the edit author, edit reviewer(s) (depending on whether they chose to watch this edit discussion).

Unimportantly, Edit annotation may weakly affect or be weakly integrated with work of these tools:

FlaggedRevs — FlaggedRevs extension attaches very basic information about an edit from a Reviewer, such as whether it is approved and what its quality is.
It may also go with edit thanking.
WikiLove — This idea could do what WikiLove does in a more friendly way, encouraging a human comment with it.
Twinkle and its brothers — this tool may encourage more interaction with new contributors while using this tool.
Echo — the notifications about edit annotation would already appear on user talk via Flow mechanisms, and as such, they would already appear in the Notifications centre provided by Echo. Notably no development effort will be necessary in Echo itself other than perhaps work on sufficiently detailed and accurate wording of the notifications of this type.

This tool may also fit within the Research:Post-edit feedback project scope.

Get involved

I understand this is some SQL and PHP work to add this functionality to MediaWiki.

Welcome, everybody! Your feedback on this idea is welcome. Please discuss on the talk page, which is also included below. Thanks.

Support

Add a * and your signature as desired if you'd not like to write a comment. Otherwise just use the talk page at leisure. Thanks!

Public comments?

Hello. Would the ratings be public or private? If multiple people rate one edit, will their scores be added? Can the rating be changed? PiRSquared17 (talk) 04:42, 30 December 2013 (UTC)

PiRSquared17, public. Gryllida (talk) 07:25, 31 December 2013 (UTC)
Yes (mean, or sum, it's an open question). Gryllida (talk) 07:25, 31 December 2013 (UTC)
Only by providing new rating, similarly to how if you warn a vandal but later realize his edit was constructive, you don't remove the previous warning. Gryllida (talk) 07:25, 31 December 2013 (UTC)

Possibly related ideas

Just throwing a couple of things I found related. We might be able to learn something from them, especially regarding the technical implementations and discussed but unrealised ideas there.

Wikiquality#Revision tagging talks about quite a similar idea. Some parts of it were realized as Flagged Revisions, where edits are assigned by a reviewer with a couple of labels (minimal, good, etc), or rejected.
Revision tagging (mailing list discussion) talks about mostly simple metadata (which device/tool/script was used to make the edit, etc), and technical requirements on the server-side. Possibility to allow editors change tags assigned by AbuseFiler has been discussed (bugzilla:28213).

--whym (talk) 06:00, 30 December 2013 (UTC)

Thank you. ☺ I have added a mention of the first of these two in the text of the idea. Gryllida (talk) 08:37, 30 December 2013 (UTC)

General feedback

It's unclear when and how the "Message shown to contributor" appears. You need a diagram of it. Your bullet list of "Message shown to contributor" is garbled, it ends with "Informati". You use passive voice for "edit may be undone", how would that work?

I think it's a non-starter to have these messages in a new system. We have talk pages and notifications and watch lists, adding another list is too much. Speaking of additional systems, Article Feedback Tool v5 has an entire moderation system for article feedback comments. This proposal should acknowledge that and learn lessons from it. I think one lesson from AFTv5 and Flow is whenever you let someone create a message on a wiki, it has to be public, it has to hook into all the functionality of watch list/recent changes/user contributions/blacklist and antispam, and it has to provide moderation facilities. Just saying "users can dismiss annotations" is nowhere near sufficient.

I'm not involved with Wiki disputes, but creating a private backchannel through which editors can spam and harass each other seems prone to abuse. So again the comments have to be public, which is what I'd expect an "annotate" system to do. One way it could work is comments live in the diff view and the author of the revision is notified of them in Echo. When a third party reviews the diff, she sees there's been an annotation. That could work at a first level, but then how does the author or a third-party respond to a comment with "Addressed in my new edit?" or "I disagree, perezhilton is an authoritative source"? Does all that go in the diff view? You're now rebuilding mw:Gerrit in revision history; I'm sure someone has proposed such a thing for MediaWiki edits :-)

The obvious Talk page integration (whether current talk page or a Flow board) would be an easy way from the Annotate dialog to create a new thread "Discussion of revision of 2013-12-27T02:28:33". This would provide a place for discuss annotations, make the conversation visible, etc. (note there's a Flow use case for some day allowing voting and achieving consensus on a thread, e.g. for an Undo decision) Maybe there's already a gadget for this. But then why don't we build this Talk integration first, and only then see if we need either the direct user-to-user feedback in this proposal or my variation that puts the annotation feedback with the diff? You mention "Talk pages: not clogged" as a benefit of a dismissable message to a user, but creating a new message system just spreads the clogging out.

Cheers, I'm sorry my thoughts aren't more coherent. -- S Page (WMF) (talk) 20:19, 30 December 2013 (UTC)

S Page (WMF), thank you for the detailed feedback. Gryllida (talk) 06:08, 31 December 2013 (UTC)
«I think it's a non-starter to have these messages in a new system.» — right, this proposal is not for real work. It is in Idea to evolve. ☺ Gryllida (talk) 06:08, 31 December 2013 (UTC)
«Just saying "users can dismiss annotations" is nowhere near sufficient.» — I have seen many many times when a generic template, such as «!! DO NOT HARRASS OTHERS OR YOU WILL BE BLOCKED», caused very adverse reactions of contributors who were only a bit unstable otherwise. Originally when writing I thought they should be allowed to hide them similarly to how they can do to fundraising banners. … You are right, this thought is clumsy and redundant for this idea, where feedback is already interactive and human.
«So again the comments have to be public» — absolutely. If you see a way to make this more clear in the text, go ahead; I have added a few bits about that. Gryllida (talk) 06:08, 31 December 2013 (UTC)
«But then why don't we build this Talk integration first, and only then see if we need either the direct user-to-user feedback in this proposal or my variation that puts the annotation feedback with the diff?» — good question. I claified that my original idea was to attach the new thread to 3 things — edit author talk, article talk, and the diff — in each of which it could be visible. Gryllida (talk) 06:08, 31 December 2013 (UTC)
I might expect some of this idea to be integrated in, in the first place, Flow (and new bits to Echo as people would have a new item to be notified of, feedback to their edits). I apologize for being unclear in the original documentation and hope that my answers have helped understanding. Gryllida (talk) 06:11, 31 December 2013 (UTC)

PiRSquared17, S Page (WMF), I have rewritten the idea in an attempt to improve its readability, coherency, and clearness. Please take a look and share your thoughts, if you like. ☺ Gryllida (talk) 16:24, 31 December 2013 (UTC)

Questions

Granular thanks

Non-granular thanks

The thank feature is mainly there to keep note of useful edits by a contributor who vandalized in the past, to account for them when he vandalizes a second time. Such tool behaviour has abuse potential (vandals making edits that could be considered useful to get away with future vandalism). Gryllida (talk) 16:26, 31 December 2013 (UTC)

Thank granularity

Should there be only one button without 'undo'? Gryllida (talk) 16:26, 31 December 2013 (UTC)
Or should there be a scale ('do not undo', 'thank', 'thank much')? Gryllida (talk) 16:26, 31 December 2013 (UTC)

Need to utilise the thank count for the vandal functionality of this tool

Probably there is no such need? Gryllida (talk) 16:26, 31 December 2013 (UTC)
If there is a need, how exactly would the contributor's edit counts add up? Gryllida (talk) 16:27, 31 December 2013 (UTC)

Need in thank feature

Should the thank feature be there at all? Gryllida (talk) 16:26, 31 December 2013 (UTC)

Vandalism warnings

Version 2

Version 3

I oppose making vandalism warnings this automated. English Wikipedia already has issues with people being too aggressive in warning new users which may hurt editor retention. I think retention is a higher priority problem than vandalism at this time. --Pine^✉ 22:16, 31 December 2013 (UTC)

Acknowledged, and I will try to refocus the idea on comments more than on automating anti-vandalism; more people having their say in this section could be useful. Gryllida (talk) 23:52, 31 December 2013 (UTC)

I have rewritten some of the text and changed the interface sketch accordingly. --Gryllida (talk) 01:08, 1 January 2014 (UTC)

Thanks, that is an improvement. I suggest asking the WMF editor engagement team for their input. --Pine^✉ 01:04, 2 January 2014 (UTC)
- A useful idea. ☺ How do I do that? Gryllida (talk) 02:16, 2 January 2014 (UTC)

Complexity

This tool makes the editing interface more complex. I have reservations about increasing complexity unless there's a significant benefit, and in this case I think the cost of complexity outweighs the benefits from the improvements. We could think about how to get benefits similar to what's proposed here if there's a way to do it while limiting complexity. --Pine^✉ 22:16, 31 December 2013 (UTC)
- After a rewrite there is not as much complexity in this revision. It appears to mostly do existing things and serve as a bridge between diff viewer and user talk page. Gryllida (talk) 01:09, 1 January 2014 (UTC)
  - Thanks, the simplification is also good although I remain cautious about adding this tool. --Pine^✉ 01:06, 2 January 2014 (UTC)
    - Thank you. Please feel free to read it "in a few days" and criticize in more detail. Healthy criticism is encouraged. ☺ Gryllida (talk) 02:16, 2 January 2014 (UTC)

Does this idea need funding? Learn more about WMF grantmaking. Or, expand to turn this idea into an Individual Engagement Grant proposal
Step 1. Change your infobox from IdeaLab to IEG: Step 2. Create the rest of your IEG proposal: Ready to create the rest of your proposal? Use the button below just once to create the remaining sections you'll need! Need more help? Guidelines for IEG proposals Kit of parts for IEG proposals Contact us