I'm not sure we need a whole separate tag for HTTP/2.

I'm sceptical as well. What existing tasks would go into this project?

I think all new(ly used) technologies deserve tag since they may be buggy or cause issues (typically compatibility). For this cases we have i.e. [DO NOT USE] NewPHP Also, we have HTTPS too...

ATM for instance:

• T96848: Support HTTP/2
• T134817: HTTP/2 Issue with OkHttp/nginx (inspiration for this tag since tracking tasks are discouraged)
• T134758: [BUG] Unable to load Edit preview, and thus unable to save edit.
• T134759: [BUG] Unable to log into the app.

Also since Phabricator search is... weird... it's not possible to search for http/2...

HTTPS is a little different: that transition is a huge, long-term effort spanning years.

HTTP/2 is only a slight change from the SPDY/3 that we supported for quite a while before it. The tickets you list are (a) The ticket to turn it on and (b) 3x tickets about the exact same issue (which the author is aware of) due to a bug in the OkHttp library that our apps use. We don't generally label things like protocols, we label things that are functional areas of responsibility, or are significant projects, etc. See also T119944.

OK, another: T117682: Analyze the win/loss of stop combining assets with HTTP/2

There is bunch of tasks regarding SPDY, so maybe #HTTP2-SPDY then?

SPDY is dead. It was an experimental protocol that predated HTTP/2, and HTTP/2 was derived from it. We dropped support for SPDY when we turned on HTTP/2 last week. Chrome's dropping support on May 15th (and they invented it).

I know...

The deal is, that whatever task intended for SPDY will most probably be valid even for HTTP/2.

I think maybe some of the confusion here is about the various roles of tags here. Most of our tags are more about management of teams and projects. This is very different from the traditional sense of 'tags' in most software, which is basically as a searching aid which can have any random meaning: just a descriptive label for some technology, software, or other component that people are likely to be thinking about when they write a ticket or search for a ticket. To quote T119944:

Move away from technology-specific tags that are often misused or may become legacy (what does "Puppet" mean? what are we going to do with the "Varnish" tag if we switch to another software for our caching proxies?)

We don't have an HTTP2 or SPDY team or project. It's just one of many technologies or protocols we can use in various places. On the client-facing edge anything to do with HTTP2 or SPDY falls under Traffic. At some point it may see use for making internal service<->service or cache<->service traffic more efficient. At some point there will probably be talk about integrated use of HTTP2 features for performance reasons (e.g. having MediaWiki and/or Services send preload/push indicators with some content, causing the Traffic edge layer to pre-push resources at HTTP2 clients). All of the things we may do with HTTP2 here will involve different software implementations, different goals, different projects, different teams. There's no unifying theme around an HTTP2 task tag other than HTTP2 being a specific protocol we can use in lots of ways (or not).

Agreed. There is no added value from a tag here. If there is an issue with HTTP2, it should be filed under the relevant component. Usually Traffic or Operations.

If the filer is unsure where to file it, a generic HTTP2 tag isn't going to make things better. If anything, it'll make it worse by creating a false sense of the task appearing triaged. Might we well use WMF-General-or-Unknown or simply leave the tags field empty until Andre or someone else can help triage it.

Proposing to decline as per last two comments.