We decided that we would leave both the totals and month-over-month values rather than (a) add a whole new layer to the code in order to keep the totals without displaying them in the "finished" TSV files" or (b) drop the month-over-month values, which would make the spreadsheets a lot less useful.

@Pppery Data-Platform intentionally includes "NEW BUG REPORT" in task titles using their custom form. I believe this is so that new reports catch their attention better. (I agree it does look untidy 😁).

I just ran into this on MediaWiki.org (that's the permalink, but it's the current version of the page). There are actually several commented-out ranges on the page, which are all displaying incorrectly.

In T363125#9739948, @Tgr wrote:

Con (long-term): Existing value (if any) of the separation between Wikitech and Mediawiki.org would be lost. E.g. it might be less obvious which subset of the content to host on wikitech-static.

That value is probably well in the negative (two different places to look up technical documentation, unintuitive and hard to guess which one to use in a given case, templates etc. need to be duplicated, anti-abuse on wikitech is problematic). Static could be handled via a namespace or category.

In T363288#9741173, @BCornwall wrote:

Could we please add a new, separate ticket for @Hghani's access and remove mentions on this one? Thanks.

In T359696#9731204, @nshahquinn-wmf wrote:

In addition to re-doing the configuration change, @Hghani and I need to get permission to access the deployment server so we can deploy jobs.

@OSefu-WMF, @mpopov could you approve this access for @Hghani and me?

FYI: wikitech:Magru data center.

In T362839#9733501, @Mayakp.wiki wrote:

@nshahquinn-wmf , do you have permission to create the yellow project tags? or can we request to have that created in this task ?

In addition to re-doing the configuration change, @Hghani and I need to get permission to access the deployment server so we can deploy jobs.

In T252227#9655162, @dr0ptp4kt wrote:

Okay, if I understand correctly, then the idea would be to...

1. Continue "allowing" tagging of wprov for non-200 HTTP responses. It's mainly important people don't accidentally count those as pageviews when they're not pageviews (i.e., they should be using is_pageview or something similarly precise). It's useful to be able to quickly zoom in on these sorts of requests anyway, so even for a 30x response it is nice to have.

2. If there's a 30x response for a redirect from desktop to mobile web and the URL came bearing a wprov, add that same wprov parameter name-value pair and also add the parameter name-value pair of rprov=1 in the target redirect URL (that's the thing that will be emitted in the Location: header).

In T361764#9705338, @Mayakp.wiki wrote:

Can I add more scope to this?

Definitely add more potential data quality metrics and other ideas for the dashboard. If it's something beyond creating a dashboard (like, I don't know, using deequ to test our intermediate datasets), it's better to create a new task.

In T362839#9728838, @Peachey88 wrote:

Are you sure you need multiple projects?, a tag (yellow) project is a secondary tag that will already have other projects attached to the task and you can just just search based on both project tags.

Okay, sounds like we have broad support, so let's go ahead and create the tag!

FYI, based on the results of T337103, user_is_anonymous and its siblings should be false for temporary users.

This was actually done a while ago.

In T362839#9724921, @Mayakp.wiki wrote:

• I would like us to use this tag for data issues reported Community as well. Not sure if you already intended that but in the examples I saw tasks opened by WMF staff so wanted to make it explicit here.

Yes, I defintely agree.

One question is how we should handle issues where the data shows spikes or anomalies which are likely related to external factors (e.g. bot users) rather than a clear software bug on our end, like T355143 or T313114. My inclination is that such issues should also be included in this tag (rather than, for example, having a separate tag), but I'm interested in what others think.

I don't want this created yet. First, I'm looking for feedback on the idea (primarily from Foundation folks involved in the data governance work mentioned in the description, but of course it's open to everyone).

I'll track the documentation work in each individual task for generating a new table.

I will remove wmf_product.pageviews_corrected as part of T362593.

Since we will be changing the layout and locations of the intermediate tables as part of T333225, we wait and update the documentation afterward.

I consulted @Hghani and he agrees with the approach above.

The GitHub repo has been updated to point there.

The last thing I need to do I make arrangements to share the analytics_product Airflow instance while still having team-specific configuration (like the alert email address).