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

In T123529#1931971, @Jdforrester-WMF wrote:

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?

In T123529#1934450, @Sadads wrote:

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.

@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 :)

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. :)

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!

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. :)

In T123529#1991325, @Jdforrester-WMF wrote:

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.

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.

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).

(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

In T123529#2188061, @eranroz wrote:

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 Can I ask why you gave this a thumbs down? What about the proposal is problematic?

In T123529#2195172, @Sadads wrote:

@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.

4. 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?

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 .

In T123529#2199315, @Esanders wrote:

4. 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.

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.

In T123529#2199342, @Sadads wrote:

In T123529#2199315, @Esanders wrote:

4. 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.

In T123529#2618881, @Pginer-WMF wrote:

In T123529#2199342, @Sadads wrote:

In T123529#2199315, @Esanders wrote:

4. 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.