Proposal: Deprioritization of subsequent rollbacks/mod PRs - Min. 60 days wait

[dnsguru]

I propose we deprioritize rollback requests that come within 60 days of a PR to place them at the absolute back of the line.

One of the lead contributions to wasted volunteer cycles and requestor frustration generally is where there is a request made to add an entry, and then iterations of updates or rollbacks when the request does not behave as expected.

The rollbacks or updates typically take many cycles (can sometimes be months/years/never) to propogate and flow out to whatever is using the PSL on the timeframe that they flow at - which the PSL volunteers have no control over. (See Propagation / Expectations for better understanding).

Sure, casual requests work the willing and abuse volunteer cycles, which seem free to the requestors, but request/rollbacks are rude and wasteful as they rob productive cycles from other PR or things the project generally needs that slack time can sometimes allow us to accomplish.

In order to ensure that the requestor on a PR has really taken a sober and careful review of the impact that their change will have, it is important to understand that there will be a lower priority given to rollbacks against current add requests.

This is a necessity and consequence of the increase in volunteer cycles lost to casual requests. The majority of those have been triggered by changes to some interop between tracking vendors and operating systems' privacy handling altering some projects.

[dnsguru]

Revised.

tl;dr: Rollbacks will have +60days waiting period, minimum.

With the thundering herd of higher effort requests that IOS 14.5 has granted the volunteers on the PSL, and the iteration overhead of all the workaround guidance in the wild that is wrong and needs interaction with angry affected folk, the resource burden on folks donating their time is out of hand. In order to help folks not casually request workarounds after lengthy interactions only to subsequently submit rollbacks, there is a need to impose a 60 day wait on rollbacks of PRs.

Get it right in the first inquiry. Get help from your Facebook rep or provider if you are not sure.

[bedfordsean]

Facebook will be standing up an inbound process very shortly, which should be your first port of call (not GitHub). I'll update here with a link to our documentation on how to go about raising a PSL request where Facebook will validate that request soon

[dnsguru]

Facebook will be standing up an inbound process very shortly.

Excellent. Vetting the customers/client's requests (vs dead-ending w hint advisory, which seems like it is being gradually remedied) will help ensure that requests which were reactive or not well thought through seeking to fix their facebook stuff are appropriate, and don't break something else or otherwise need to roll back the change. It would be unfortunate for sites to have to remedy their main site or other key resources during this 60 day cooling off period and back-of-the-line prioritization, and then the unpredictable propogation timing.

[sleevi]

Do you have some example PRs? My worry is this may feel punitive, and actively breaking a site seems bad.

That said, I agree we are currently resource bound due to trying to prevent exponential growth, and so ultimately, whether formalized or not, volunteers will prioritize what is important to them (… and which doesn’t unduly frustrate them).

[dnsguru]

It is not intended as punative at all. This is just a task/time management thing. The secondary objective is to help improve the quality of the PRs coming through - so that submitters carefully review their use case and understand the implications and do take them seriously on self-breaking their stuff in a way that wasted a bunch of any of the volunteers' time here.

Yes, the theme of cutting down on requestors wasting our time is a factor pervasive in the motivation here, because a PR and then a rollback = net waste of volunteer cycles, but the primary objective would be to focus help for the newer requests that are queued up.

Gratefully, I suspect that our efforts in documentation of the impacts of a change, better awareness of the 'we have no control over downstream propogation' challenge, along with some of the PR discussion triage on the consequenes in dialog with a lot of the requests frozen for #1245 are gating there being a larger list of examples.

Because of the current (as of May 18, 2021) pause on letting through FB / IOS workaround requests, we're not seeing a larger quantity of these happening, but there will no doubt be rollback requests triggered by those.

Examples of recent "quickflip" submissions are

1071 -> #1132

1193 -> #1211

1238, #1251, #1252 -> #1318

[dnsguru]

Adding #1290 and #1335 into the example cases.