- Note: You can comment at the talk page.
Post-thank and post-undo remindersEdit
Edit annotate dialogEdit
- Figure 2. Annotate dialog
Diff viewer interface changes (outdated idea per feedback at the talk page)
Add an annotate link.
Message shown to contributorEdit
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
- 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 solveEdit
- Need in more human interaction with new contributors.
2. Recent Changes Patrol automation (outdated idea per feedback at the talk page)
Automated anti vandalism (outdated idea per feedback at the talk page)
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:
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 experienceEdit
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.
- Make this tool available for all users, logged in or not.
Not project goals (outdated idea per talk page feedback)
Integration with existing tools and projectsEdit
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.
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.
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!
- 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)
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).
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.
- 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)
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)
- 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 toolEdit
- 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 featureEdit
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)
- 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)