History

• Discussion at the Community Wishlist: Dealing with unsourced additions - "citation needed" button (one oppose, one neutral, ~40 support; Huggle and Twinkle communities were canvassed on their talk pages)
• Discussion of broadening it to other inline tags at Semi-automation of inline tagging.
• Constructive criticism, such as inline-tagging, correlates with higher editor retention (details and sources ).

Goals of the feature

• make inline tagging faster and easier by semi-automating it
• make inline tagging more common, as it was pre-2007, when editor retention rates were higher and vandalism rates lower (semi-automated tools were developed to respond to rising vandalism)
• improve newcomer editing skills more quickly, so that newcomers can fix their own early edits, reducing the burden on experienced editors
• give desirable new editors prompt, constructive criticism (there is evidence this improves editor recruitment)
• improve the retention of flawed but fixable edits by new editors (there is evidence this improves editor recruitment)
• reverse the post-2007 slow decline in the number of active editors, and return to exponential growth in the number of active editors

Basic design goals

• make it at least as quick to tag as to revert
• add to the functionality of existing and future automated tools
• Some editors have no use for such a tool at all; those dealing with vandals who add articles to odd categories as a joke, for instance. The tool should therefore be removable from the UI.
• Different editors will need different inline tags; to avoid cluttering the UI, the selection should be customizable.
• Both point and span inline tags should be usable (examples: "citation needed" and "citation needed span")
• New editors often make the same error repeatedly in multiple edits. It would be nice to have a way to group edits and inline-tag the lot with the same tag.
• The tool should not make a mess of articles by adding redundant tags. An entire uncited para only needs one cn tag, and three cn tags in a row is even more pointless

Basic design ideas

• Click to add a point/span tag to the end/around the new text created in the edit being reviewed. Default sensibly to ignoring contiguous segments of the new text which are single letters, punctuation, changes in grammar, and other things no-one wants to tag.
• For more complex edits adding many blocks of text, have drag-and-drop tags.
• Have sensible default edit comments which are very helpful to newcomers and link to all the needed context
• Have an undo, in case it makes a mess (probably already part of the tool)

I will try to implement this during this year's hackathon

@Petrb: Thank you! I understand plans being a bit disrupted this year, tho.

If inline tags are being applied to specific edit (as is usually the case) in a computer interface that can easily identify the edit (as here), there is an additional opportunity.

Wikipedia currently gives "Your edit has been reverted" notifications by default (with opt-out). It could similarly give "Your edit has been inline-tagged for improvement" notifications. For editors with less than ten edits or so, it could even post once to their talk page, telling them where to find their notifications. This might improve the chances of editors fixing their own problematic edits.