I think my vote is to collapse the bugzilla project into one HTTPS label project since SSL does not assume any particular team this seems analogous to LDAP or Mail to me.

I propose to 1) kill T29946 (it once was about secure.wikimedia.org and then its scope got incorrectly broadened) and 2) rename "Wikimedia-SSL-related" to "HTTPS". Plus for both cases, when people say SSL they mostly mean TLS nowadays.

1. T29946 has 11 open dependency tasks. 7 of them already have the "Wikimedia-SSL-related" project associated. For the remaining four, would that "new" HTTPS project refer to server configurations only, or also to e.g. codebases that do not have or support protocol-relative links (but only hardcoded http links)?
2. For those 27 open tasks in "Wikimedia-SSL-related", do they all look sane when it comes to priorities (feel free to decrease for the sake of reality) and actually belonging into that project?

In T86063#963357, @Aklapper wrote:

I propose to 1) kill T29946 (it once was about secure.wikimedia.org and then its scope got incorrectly broadened) and 2) rename "Wikimedia-SSL-related" to "HTTPS". Plus for both cases, when people say SSL they mostly mean TLS nowadays.

Wholeheartedly agreed.

1. T29946 has 11 open dependency tasks. 7 of them already have the "Wikimedia-SSL-related" project associated. For the remaining four, would that "new" HTTPS project refer to server configurations only, or also to e.g. codebases that do not have or support protocol-relative links (but only hardcoded http links)?

I think this is the same discussion we were having about Mail and similar labels. I think tagging everything relating to HTTPS with HTTPS would be the intuitive to do. HTTPS being a yellow tag means that we'll have to tag those with additional projects, so that they can go to their respective team and we can filter them properly.

2. For those 27 open tasks in "Wikimedia-SSL-related", do they all look sane when it comes to priorities (feel free to decrease for the sake of reality) and actually belonging into that project?

I gave it a quick look. They look okay so far but we'll need to do another round of triaging.

Andre, thanks for going over stuff thoroughly. I looked through and indeed a HTTPS tag seems like it will cover this and invalidates the need for T29946

So...I'm going for it.

There is also a 'goal' one outside of sprint. Preference?

What about HTTPS-by-default as a "goal". This the same color as "sprint" but obviously goals would be different in context, but a sprint is a type of goal..? I think spreading the color green thinner over this is warranted.

@Aklapper?

talked to andre about this idea and he said he would sleep on it :)

So is there any vague ETA when "HTTPS by default" will be finished? Because my differentiation to a standard "component" tag would be "can and will this project realistically ever be defined as finished?".

But yeah, let's go for the green project style here for the time being.

If people want to discuss/finegrain/differentiate https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects I won't stop anybody, but in the end it should be about getting work organized and done while trying to stick to guidelines and interpreting them on the way. :)

Well, the ops-y parts of the "HTTPS by default" goal, i.e. scalability, performance & monitoring work is expected to be finished this quarter, so yes, there is an ETA. However, the actual switchover and the choices surroundng it (exceptions, relations with Zero etc.) is fundamentally a product decision and depending on the product choices made there it may result in more tasks needed besides the ones that we've already planned within ops.

That said, even if there is no ETA for this product decision, the project can be definitely realistically be defined as finished at some point: it will be the point where we redirect everyone from HTTP to HTTPS. It's as well-defined as it can get.

So I think we are done here (two projects created) and we can close this as resolved? Or anything left to sort out?