This is likely the same as T5030, but I haven't observed it myself and haven't spent the time to try to reproduce it.

This is a fairly huge amount of complexity for a very niche use case, which makes me hesitant to pursue it in the upstream. I expect the number of installs which would use this feature is on the order of 1, and that it essentially amounts to custom development.

We don't understand this use case, so we aren't sure how to proceed here.

This is fairly straightforward but blocked on T9132, which is prioritized elsewhere. This is likely to be completed adjacently with T9132 anyway.

We're aware of requests in this vein but unlikely to implement the specific suggestions here, for a variety of reasons. The product pathway forward here is generally a murky one. We will likely need to resolve T1460 (itself, murky) before having more clarity here. Resolving it may also introduce satisfactory threading.

This is technically straightforward but probably needs some design work. I'd guess it's on the order of 2-4 hours depending how messy application/customfield stuff ends up, although that may happen in a technical block and a separate design block. This can be slipped in if approved.

This is easy to change but I'm not really convinced it's better, even though it is inconsistent.

I plan to try to collect the above into documentation to try to better explain this, but I don't think that has any specific impact on anyone. I don't plan to make any behavioral changes. I'm open to suggestions here, but we can't write a bin/time rewind and can not fully redact data which has been committed to the system and published to email and other external channels.

Presuming this is a problem with extensions since there's a warning in the upstream.

This should probably wait for T3980 and be reevaluated after that.

In particular, I think we're going to hit cases like this:

Well, there's an unrelated bug.

(Just creating an example via email for my next reply.)

I do this routinely without errors and am not sure how to reproduce it.

This is straightforward and probably <1 hour of work. It can be squeezed in if approved for prioritization.

This probably now also blocks on T9132.

This is not blocked, but large and not adjacent to other prioritized work. I've included it in "Projects v3" (T9378).

We don't have enough information to reproduce this or otherwise move forward on it.

This is reasonable and straightforward, and I have some adjacent UI adjustments I'd like to try making concurrently. This is <1 hour and can slip in somewhere if approved for prioritization.

This isn't blocked on anything but not adjacent to other planned work in the near future. It likely makes sense as part of a "Projects v3" with T3670. I'll see what else is in queue and tentatively organize anything projects-related if there's some more of it.

Presuming this is just related to bucketing errors since we're aware of bucketing assignment occasionally being surprising, see T9372 for some discussion.

T4100 is complete and this is technically unblocked, but needs significant planning work. I intend to wait until we're closer to being able to act on it to do that planning, since things are likely to change at least somewhat between now and then.

This is blocked by T8783 (building Nuance to initial release quality) and T5307 (taking actions with search results).

I want to resolve T8588 before pursuing this to make sure the issues aren't conflated, although I think this isn't related.

I ideally want to resolve T8588 before pursuing this since it's the more fundamental performance issue, even though this isn't particularly entwined with that.

(We can cache actual image objects in the browser, although this may create other problems, and is generally a mess that needs to be individually hard-coded in every case where we show images.)

This is largely because of specific requirements from WMF, see T5685. We can reduce the number of redirects, but per requirements in that task we can not reuse URIs and can not make these resources cacheable.

I expect the general shape of the code to survive, but a lot of the particulars to churn. There are lot of issues with state handling, error handling, locks, which things are responsible for what, etc., right now.

Yeah, I think that's probably the cleanest way to approach this today. That mostly works around the management mess, too.

I left this open because I think the information in the description is useful for us in eventually crafting setup checks and possibly including in the documentation.

The described behavior is working as expected, I think.

Now done:

I think changing the proposed behavior (making subscribers inherited in some form) is possibly reasonable, in that this is probably a common desire, although it seems like users might also reasonably want to subscribe to /x/ without subscribing to /x/*. We could let you "subscribe (this page only)" vs "subscribe (this page and all sub-pages)" but Subscriptions would need to expand substantially to accommodate that and there are no other use cases in other applications that I can think of (except sort-of Projects).

Another workaround involves working with remote offices. The reviewer prefer not to block the author, so they resign as a reviewer and suggest someone from the author’s office as reviewer. This has two big issues. First, the commit message will not have the original reviewer on it, so if there’s a prod issue, or someone is just going through git log for context, they wouldn’t see who the actual reviewer was. Second, the diff doesn’t appear in the author’s queue but in the new reviewer’s queue. And the next action should be taken by the author.

This is UI oddness, you're doing everything right.

The core of this should work now. These things aren't happening yet:

Whoops, fixed. Thanks.

Just jotting these down here to make sure they don't get lost: