Poke -- is this happening next week, or do we need to bump it to April?

This was scheduled for March, is this happening next week or should we bump it to April?

Deployment was reverted, moved to next week in roadmap.

This has been added to Roadmap, per roadmap policy please move it to the appropriate column in the roadmap within the next couple of weeks. Thanks!

This has been added to Roadmap, per roadmap policy please move it to the appropriate column in the roadmap within the next couple of weeks. Thanks!

Seems to work fine on mediawiki.org, please close if resolved :)

Scheduled for Catalan Wikipedia today (3/19).

Congrats for getting jessie into prod! Can we project an ETA yet for the remaining tuning tasks? Thanks.

No finger-pointing intended and my apologies for any misunderstanding to that effect, thanks to @MZMcBride for taking a crack at the summary. The point here was simply to make clear that this was a significant UX change that was merged as part of routine code review, and if anything, should have received greater scrutiny from us from us as part of the process.

Please revert and SWAT deploy. FYI, this also affects Amazon.com extracts and other cases it shouldn't.

Since this is tagged Roadmap, standard roadmap questions apply, see T92874#1124163.

Since this is tagged Roadmap, standard roadmap questions apply, see T92874#1124163.

Do we have an ETA for this? Please note that "Roadmap" tasks should not be in "Unscheduled" state for more than two weeks per roadmap policy (see roadmap project summary page). Also, please ensure that "Roadmap" tasks have a task description that is meaningful outside the context of the "Flow" team, i.e. the project should at least be mentioned in the task title. Thanks!

Please add brief summary of user impact to the task itself. Thanks!

This task is purely for maintenance of a legacy dataset that will be replaced with Hadoop-generated data soon. So I would prefer to avoid adding new requirements, unless there's an urgent request that we can only answer in this manner. @kevinator what's your take based on the understanding of the request?

I'll take it. Thanks!

That's great - thank you. Last question for now: What's that in absolute numbers per month?

(Removing from master roadmap for now -- we can add specific major deliverables as tasks per roadmap policy)

You write: this is about 3.3% of our global traffic under the existing definition (which we know is overcounting. So, the actual proportion is likely to be much higher).

Thanks, Oliver! It doesn't redirect - it's responsive.

What is the intended behavior on mobile screen sizes?

Great, thanks for the offer to help. Oliver should be able to start poking at this as soon as we've completed some more urgent data requests.

@DannyH let's make sure we include this in our Q4 roadmap -- as we expand Flow usage we have to ensure the data is publicly available.

Per roadmap policy, please provide a rough ETA no later than two weeks from now or remove this project from the roadmap if you think it will remain unscheduled until then.

Per roadmap policy, please provide a rough ETA no later than two weeks from now or remove this project from the roadmap if you think it will remain unscheduled until then.

I recommend checking out https://perma.cc/ as well which is specifically designed for this purpose and backed by DPLA, Internet Archive and others. @Yana

Can we measure how many successes/failure we're currently getting? If the failure rate is too high, I think we need to disable the feature altogether until the root cause is resolved rather than putting in stopgap error pages.

(simplified description for roadmap readability)

I have slow and unstable and limited by quota connection to Internet. And no, it's not going to improve because of where I live. HTTPS has additional payload and uses precious time and bandwidth up, can't be cached by proxy servers or compressed by Opera Turbo. Enough? So, please, don't forget your promises, and keep my ability to use HTTP intact, and fix this bug. Thanks for attention and understanding.

Tentatively suggesting Oliver and perhaps Leila (if she has bandwidth to help) work on this project.

Nice demo for reference: https://tools.wmflabs.org/hay/wdskim/

Please clarify ship date as soon as you can - thanks :)

Can we project a "week of" for this test yet?

A Russian Wikipedia community member implemented a JavaScript redirect to send Russian Wikipedia traffic to HTTPS in August 2014, so most Russian Wikipedia traffic has been going over HTTPS since last year. A similar hack was in place in Russian Wikinews. The resulting configuration was vulnerable to man-in-the-middle attacks, as it depended on users first loading the insecure version. It also caused a major performance hit for users due to the double-loading. In consultation with Russian Wikimedia community members, consistent with our long term HTTPS rollout objectives, and consistent with the pre-existing request to participate in the HTTPS beta, we superseded the hack with a server-side redirect and HSTS as a secure and consistent default configuration for all Russian language projects.

Per discussion, tentatively targeted for next quarter. Called out in the roadmap because it's considered a top "user delight" issue that will make table editing a lot smoother.

This is this week, is this still scheduled to happen?

Do we have a "week of" ETA for this yet?

Thanks Lydia. Does it sound reasonable to you to schedule arbitrary access tentatively for the April-June quarter for now, or do you still want to see if you can hit a March deployment goal?

@KPu3uC_B_Poccuu: You cannot use Russian Wikimedia projects without HTTPS at this time; the cookie will not have any effect. Resolving as invalid unless you can reproduce the issue in other projects.

As for Android, do we have a projected "week of" ETA yet?

Do we have a projected "week of" ETA yet?

@tstarling any near term fix would be great as this impacts a lot of users and we will have to temporarily disable PDF generation altogether if we can't get it under control soon. flagging to @bd808 as well -- would be good if this could be prioritized as a critical issue.

When is this expected to land?

Let's discuss in our next weekly team meeting on Wednesday.

I suggest we prioritize the following for now:

• HIGH: Show % of total traffic (for the view I'm in) as a separate column
• MEDIUM: Switches to group platform, browser version (if I group "platform" I still get all Chrome versions, if I group "browser version" I still get the OS breakdown, if I group both I just get "Chrome", "Firefox" etc.)

Can we project a "week of" deployment ETA?

Yep, and we've decided to not limit ourselves to users who start the tour for the initial test. Thanks for checking in.