Page MenuHomePhabricator

Add support for hashtags (URL parameter -> edit summary) in VisualEditor, WikiEditor, and ?? other editors
Open, NormalPublic

Tokens
"Love" token, awarded by Liuxinyu970226."Dislike" token, awarded by Ricordisamoa."Love" token, awarded by leila."Love" token, awarded by mahmoud."Love" token, awarded by Sadads."Like" token, awarded by Slaporte.
Assigned To
None
Authored By
DarTar, Jan 13 2016

Description

As an editor, I want to be able to:

  1. follow a link to a Wikipedia article from a todo list (say an editathon or a campaign page, a tweet, an invitation to edit by email) that includes a campaign hashtag as a parameter, e.g. https://en.wikipedia.org/wiki/Kate_Beath?ht=wikiD
  2. start editing the target page and have the campaign hashtag pre-filled in the edit summary, e.g. /* Biography */ Some text here #wikiD
  3. store the hashtag in the edit summary when I save the revision
  4. apply the above to any other edit I make during the same browser session

Who else will benefit from this change

  • As an editathon or campaign organizer or a program manager, I'll be able to easily retrieve a feed of users and edits that are part of a specific initiative (e.g. #wikiD) and obtain metrics about the impact of this initiative.
  • As a researcher, I'll be able to run experiments or analyze contribution trends as a function of the initiatives driving them.

See also

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@Jdforrester-WMF I believe the two are complementary, hashtags can be used informally and with 0 overheads by anyone (including off-site), Campaign tracking is IMO for more structured, on-site initiatives.

Where can I read more about what Campaigns currently supports?

Sadads added a subscriber: Sadads.Jan 13 2016, 7:06 PM

We are beginning to use the hashtag for #1lib1ref . From what I am seeing, we are missing something like 1/3-1/2 of the edits in the campaign, because the editors forget to add the hashtag to edit summaries -- or its not intuitive. See http://tools.wmflabs.org/hashtags/search/1lib1ref as compared to the communication of edits at https://twitter.com/search?q=%231Lib1Ref

@Slaporte's tool is working well for a bot http://tools.wmflabs.org/hashtags/search/iabot. We ought to be promoting this with tools as well (could be more useful than tags, because it could be developed on the fly by volunteers).

@Jdforrester-WMF I believe the two are complementary, hashtags can be used informally and with 0 overheads by anyone (including off-site), Campaign tracking is IMO for more structured, on-site initiatives.
Where can I read more about what Campaigns currently supports?

No idea. I thought you were involved in building it. :-)

How is this VE-specific? Sounds like something that should be going into the wikitext editor before VE...

DarTar added subscribers: AndyRussG, Ragesoss.EditedJan 13 2016, 8:29 PM

Where can I read more about what Campaigns currently supports?

No idea. I thought you were involved in building it. :-)

oh that Campaign tool. A little bit of history:

  • the account creation form had at some point (and I believe still has) built-in support for user signup campaigns (via Extension:Campaigns). This was introduced as part of the former Growth team's account creation UX tests. These tags are different from the current proposal in 4 ways: 1) they apply to users, not individual revisions (see usertagging for the difference) 2) they are set at the time of registration once and for all 3) as a consequence of this, they can't represent an editor as participating in multiple campaigns (1-to-many) or an editor joining a campaign after signing up but only a newly registered user as permanently associated with a signup campaign (1-to-1) 4) data generated by this extension is collected via EventLogging (schema) and, as a result, it is not made publicly available, which means it will be useless for parties outside of WMF, whereas edit hashtags would be released as public data as part of the edit summary.
  • there was an attempt to build a more sophisticated editor campaign management tool @AndyRussG contributed to and I believe this might have been taken over by the folks at WikiEdu (cc @Ragesoss), however this was primarily designed as a fairly heavyweight system to create and manage campaigns.

hashtags fulfill a pretty different purpose, but I'd be happy to hear if that is not the case.

@Krenair wrote:
How is this VE-specific? Sounds like something that should be going into the wikitext editor before VE...

you are correct that it is not VE-specific but I expect the implementation might be quite different in VE vs ther legacy wikitext editor. I flagged this as a VE request given that editathons are likely to send new contributors to VE as the more newbie-friendly editing interface. If it's trivial to make this work in a way that is interface-agnostic, that's even better.

per @DarTar and @Krenair I want to +1 the idea that Hashtags seem like a minimally invasive project, that could support a whole range of assessment strategies, that don't need significant overhead -- and could serve our programs communities, our developer communities and the larger editing community quite well.

@Jdforrester-WMF & @Neil_P._Quinn_WMF How do we get this prioritized at some point? @DannyH is this something that Community tech could integrate into one of the watchlist asks?

per @DarTar and @Krenair I want to +1 the idea

I'm not +1ing the idea, I'm questioning the idea of supporting it in VE before core developers consider accepting it for the wikitext editor.

DarTar updated the task description. (Show Details)Jan 14 2016, 8:48 PM
DarTar set Security to None.

@Jdforrester-WMF who is the right person to determine if this proposal would be best implemented as a VE feature or an interface-independent one?

DarTar, thanks for inviting me to take a look at this proposal. I actually saw it in action at the IWD2015 event at Kadist.[1] Parker (at least I think it was Parker) told us about the hashtag campaign, and we were using it in every Edit Summary. It was cool to hear all the "pings" whenever someone clicked Save. Aside from that "coolness" factor, I think it's a GREAT idea. Women in Red[2] has run 6 event campaigns/editathons since launching July 2015 and will be running at least one per month in 2016.[3] These are virtual editathons over many days sometimes with and sometimes without a sponsoring GLAM org which is simultaneously hosing in-person event(s). An auto-populated hashtage would certainly help us with our event's Outcomes list (metrics).

[1] https://en.wikipedia.org/wiki/Wikipedia:Meetup/San_Francisco/ArtandFeminism_2015
[2] https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Women/Women_in_Red
[3] https://en.wikipedia.org/wiki/Wikipedia:Meetup/Women_in_Red/Events

Hey all! Glad to see this discussion made some good progress without me, so thanks to everyone for getting the ball rolling.

I just wanted to chime in and of course give my +1 (or +3 if we're counting the other Hatnote contributors I consulted), and mostly say that this would be making a world of difference for a growing segment of Wikipedia contributors.

These days we're seeing more and more editathons. Really the tooling could see a lot more support than it has so far. I feel that Dario's proposal to add a semi-persistent hashtag for the editing session strikes a good, actionable balance that represents the lowest hanging fruit we can offer these groups. It would just mean a lot if we could show these new editors something from within MediaWiki that speaks to these purposes.

Anyways, @Krenair, if there's anything else I can do to make this happen, please let me know. I'll be more active on this thread in the future, all my contact info is in my profile :)

Jdforrester-WMF changed the task status from Open to Stalled.Feb 2 2016, 8:17 PM

Is there a proposed design here to be implemented? I'm unconvinced of the value, but if there's a clean design we could look at it.

Oh, sure, so the design as I understand it is to make it so that editathon coordinators can distribute a special link that would associate the clicking user to an editing group. Users associated with that group would, for the duration of the browser session, have a hashtag prepopulated in their edit summary.

In a sense it's like ecommerce-style referral links. When you click on a site's/friend's referral link, they stay associated with your shopping session so that they get a small portion as a finder's fee. Of course in our case there's no money (though I wouldn't be surprised if referral links for donations were already a thing for analytics), and the editor also has the last say, as they can add/remove hashtags from the edit summary field manually.

So in short, a URL parameter goes into a browser-session cookie which is then used to prepopulate the edit summary. The lowest-hanging, least-invasive feature we can build for editathon coordinators. :)

DarTar triaged this task as Normal priority.Feb 2 2016, 11:33 PM
Ocaasi added a subscriber: Ocaasi.Feb 5 2016, 6:24 PM
Ocaasi removed a subscriber: Ocaasi.
Ocaasi added a subscriber: Ocaasi.

So, did we make it onto the backlog? The #artandfeminism editathon is back again this year and their efforts reminded me. Hope we can have something for the next editathon organizers!

leila awarded a token.Mar 9 2016, 6:30 AM
leila added a subscriber: leila.

background: @Jdforrester-WMF I had some conversations with Stephen about this as this is a feature we can benefit from in article recommender system now that we are ready to start testing the system via campaigns. :)

Is there a proposed design here to be implemented? I'm unconvinced of the value, but if there's a clean design we could look at it.

What do you mean by design, James? Do the 4 steps described in Description address your question? If not, can you expand what we will need to provide?

@Jdforrester-WMF This could be also something that we build into the Education-Program-Dashboard -- as it becomes the Programs and Events Dashboard for other forms of organization. @Ragesoss @FloorKoudijs . Also, the recent update to allow export of the data into CSV at http://tools.wmflabs.org/hashtags/search/1lib1ref allows for quite sophisticated analysis of the impact of the data, which would be really important as we grow the impact of hashtags. I think Mahmoud's strategy would be the best way to do it.

To expand on @Jdforrester-WMF's question: there is no design / UX need for this that I am aware of, the task description still has the most accurate scope for this request.

Regarding the value of this proposed change: this will allow us to answer questions such as where edits come from, which is currently impossible to answer without some complex consolidation of data from different tagging/tracking systems.

We still don't know, at a purely descriptive level, how monthly edits and active editor trends break down in terms of programmatic efforts. This additional data point will allow us to settle the question of what drives these numbers and if we need to pay closer attention to any of these initiatives.

ggellerman moved this task from Backlog to Radar on the Research-Backlog board.Mar 17 2016, 10:27 PM

FYI, just put out a blog post on the Wikimedia Blog with some case studies: http://blog.wikimedia.org/2016/03/23/hashtags-expanding-outreach-wikipedia/#comment-26308

What's interesting about the case studies: is that we still have a significant section of editors participating who don't intuitvely use the hashtags. I think this is matter of socializing and making it simple in terms of not having to be proactive for including the hashtag.

Also, this is probably something that will be on the long term plans for the international version of Education-Program-Dashboard as it ramps up for broader programs use.

Stryn added a subscriber: Stryn.Mar 26 2016, 3:01 PM
Jdforrester-WMF renamed this task from Add support for hashtags (URL parameter -> edit summary) to Add support for hashtags (URL parameter -> edit summary) in VisualEditor, WikiEditor, and ?? other editors.Apr 2 2016, 10:36 AM
Quiddity updated the task description. (Show Details)Apr 7 2016, 7:01 PM
Quiddity added a subscriber: Quiddity.
Quiddity added a comment.EditedApr 7 2016, 7:37 PM

We do already have the &summary= parameter when editing, e.g.
https://www.mediawiki.org/w/index.php?action=edit&summary=%23banana&title=Project%3ASandbox (see a saved example edit)
So we need a way to get to that URL from
https://www.mediawiki.org/wiki/Project:Sandbox?ht=banana
and for it to work with both page-edits and section-edits (without being overwritten by the /* section heading */ autosummary), in all editors (visual editor, wikitext editor, and any others).

Jdforrester-WMF reopened this task as Open.Apr 7 2016, 8:13 PM

This isn't a dupe of T109032: Support tags from editing form; that's about MediaWiki tags, this is about adding "hashtags" (i.e. #hellomum) to the summary from the GET string.

eranroz added a subscriber: eranroz.Apr 7 2016, 8:18 PM

(Sorry for the merge, I meant to do the other way round)
I think we can use MediaWiki tags to serve not only developers/extensions but also for "community tags" such as edithons. This way we can benefit from the nice infrastracture of mediawiki tags which tags revisions in easy way to locate and filter in the recent changes

I think we can use MediaWiki tags to serve not only developers/extensions but also for "community tags" such as edithons. This way we can benefit from the nice infrastracture of mediawiki tags which tags revisions in easy way to locate and filter in the recent changes

I'd be worried about:

adding complexity to the interface for anyone who didn't need it (we'd need either a text-field for freeform hashtags (and to hook that into the usual moderation tools such as oversight), or a dropdown menu for predefined hashtags (and then a guideline on how to decide what gets added/removed/shuffled));

plus adding complexity to the instructions given to the editathon participants ("Put an edit summary in this box, and then put your hashtag in this separate box").

It sounds simple to us wikiholics, but every additional step adds to the learning curve and thus drop-off rate.
Also, re-using the edit summary for this, encourages newcomers (often the target demographic) to understand and use edit-summaries in the first place.

I agree with @Quiddity, reusing the existing edit summary box is nice and simple, and users are already doing it for programs like #artandfeminism (for example).

The design here doesn't require adding any additional text fields or menus.

Change 282456 had a related patch set uploaded (by Eranroz):
Allow tags in summary

https://gerrit.wikimedia.org/r/282456

Patch https://gerrit.wikimedia.org/r/282456 mainly address T109032 by allowing user to assign change tag to their edit from the edit form, without need of new/complex UI.

This patch is by no mean fully address this feature request, which requires a major redesign of ChangeTags (as it currently assumes listExplicitlyDefinedTags is a small list kept in cache). It also doesn't address the UI side or API side which is tightly coupled with such re-design. I imagine that a full support will require UI to autocomplete tags for users and require API support for querying tags by prefix so when user type # TAG_NAME it will search for all tags starting with TAG_NAME.
Having saying that, it should give at least a simple yet powerful support for tagging edits to some general pre defined tags such as "Edithon" (but not "Edithon 1-4-2016").

Ricordisamoa added a subscriber: Ricordisamoa.

@Ricordisamoa Can I ask why you gave this a thumbs down? What about the proposal is problematic?

@Ricordisamoa Can I ask why you gave this a thumbs down? What about the proposal is problematic?

I think this would be a very unexpected use of edit summaries; they're also permanent, therefore they're not suitable for ephemeral and risky experiments.
Real edit tags would be a lot more efficient.

  1. apply the above to any other edit I make during the same browser session

every edit? what about user talk page edits? or what if I go home and start editing other stuff, how do I clear this persistent auto-hashtag?

Sadads added a comment.EditedApr 12 2016, 3:54 PM

Thanks @Ricordisamoa!

Its not that unexpected-- there are tons of uses of edit summaries which point folks to Wiki-pages or editors use odd or obscure policies to justify edits. I am not sure if I understand what you mean by "risky experiments".

As for "real edit tags" -- at the moment, its incredibly bearacractic to use them, and they don't really allow for "social and decentralized" uses of them-- in that an organizer for an event, wouldn't be able to create one without considerable effort. Also, having a set of well defined tags is important for current uses -- https://en.wikipedia.org/wiki/Wikipedia:Tags .

Sadads added a comment.EditedApr 12 2016, 3:56 PM
  1. apply the above to any other edit I make during the same browser session

every edit? what about user talk page edits? or what if I go home and start editing other stuff, how do I clear this persistent auto-hashtag?

Thats a good engineering design question -- I think you would have to be able to remove a hashtag once from an edit summary and it not appear again-- we also might want a time limit on the persistence of the tag within someones browser. For most use cases for a "campaign hashtag", you are mostly working with editors that only participate in a particular window of time and/or around the event and/or campaign.

Have a special page to turn an editing campaign on for the current user, and/or augment the "Create account" form with ?campaign=foo to automatically sign new users into the campaign.
Once a user has confirmed the membership, their edits are tagged by default, but they can unselect the relevant checkbox just like they select the "minor edit" one.
Automatically once the campaign expires, manually on logout and/or via the aforementioned special page, users are signed off the campaign.

Like reserved tags, and unlike 'hashtags' in the edit summary, campaign tags are only enabled via their own UI and therefore are reliable.

Cookies have expiration times built right in, so you can easily set a sane default of, say, 48 hours. Hashtags are also short, clear, and trivially deletable. Ideally we get this launched, and if there are reports or if it seems to cause confusion, a priority can be set for additional UIs.

I think there are many reasons to think that this will just work, provided sane defaults, like the ones outlined above. Given the number of edits expected and the users involved, the risk is fundamentally very low.

TheDJ moved this task from Backlog to Doing on the WikiEditor board.Apr 15 2016, 8:04 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 7:18 PM

Might be dependent, in part, on T60698

Adding hashtags as a URL parameter would also be useful for campaigns involving projects other than Wikipedia - I'm particularly interested in Wikidata, where most edits are done in a way that does not allow users to add hashtags to the edit summaries.

  1. apply the above to any other edit I make during the same browser session

every edit? what about user talk page edits? or what if I go home and start editing other stuff, how do I clear this persistent auto-hashtag?

Thats a good engineering design question -- I think you would have to be able to remove a hashtag once from an edit summary and it not appear again-- we also might want a time limit on the persistence of the tag within someones browser. For most use cases for a "campaign hashtag", you are mostly working with editors that only participate in a particular window of time and/or around the event and/or campaign.

Another possibility would be to pre-fill the tag the first time (when the cause-effect connection is clear after landing into editing from a campaign-related link), and make it easy for users to add the tag themselves on upcoming edits. If we provide a tag selector that surfaces recent tags, a user may just need to type "#" and hit enter to select the most recent tag (probably about the campaign they are participating in).

In this way, the user discovers the tag the first time and we make it easy to use repeatedly when needed (both in terms of adding it quickly, and not requiring to recall the exact tag name). This approach eliminates the risk of forgetting to remove the tag when it is not appropriate, but introduces the risk of the user to forgetting adding it.

Sadads added a comment.Sep 8 2016, 9:36 PM
  1. apply the above to any other edit I make during the same browser session

every edit? what about user talk page edits? or what if I go home and start editing other stuff, how do I clear this persistent auto-hashtag?

Thats a good engineering design question -- I think you would have to be able to remove a hashtag once from an edit summary and it not appear again-- we also might want a time limit on the persistence of the tag within someones browser. For most use cases for a "campaign hashtag", you are mostly working with editors that only participate in a particular window of time and/or around the event and/or campaign.

Another possibility would be to pre-fill the tag the first time (when the cause-effect connection is clear after landing into editing from a campaign-related link), and make it easy for users to add the tag themselves on upcoming edits. If we provide a tag selector that surfaces recent tags, a user may just need to type "#" and hit enter to select the most recent tag (probably about the campaign they are participating in).
In this way, the user discovers the tag the first time and we make it easy to use repeatedly when needed (both in terms of adding it quickly, and not requiring to recall the exact tag name). This approach eliminates the risk of forgetting to remove the tag when it is not appropriate, but introduces the risk of the user to forgetting adding it.

I was thinking a tag selector, would definitely be a Value-added feature, but is not MVP. Probably would also require, surfacing recently popular tags, or tags that the editor recently used in their edit summaries, would help alot in drawing viral attention to editing campaigns among experienced editors.

Astinson updated the task description. (Show Details)Jul 24 2017, 2:14 PM
He7d3r added a subscriber: He7d3r.Dec 29 2017, 6:49 PM