Wording on this feed story isn't quite right, not sure if that's new or not:

@angie, I added you to Community so you should have sweeping powers on this install now.

"Close" makes sense to me. And, yeah, I agree that long-term some kind of "All Badges" link that leads to, like:

If you know you had three badges yesterday and then visit your profile and see only two badges, there's no way to figure out what happened (without examining the edit history of every badge), if we completely hide them, is there?

The Git issues have been resolved (see T9657).

This has been live for about a month without any major issues cropping up.

Resolved by D14420.

Broad update here after T9132:

No problem -- it's easier for us to merge duplicates than split tasks apart, so it's not bad to err on the side of filing new tasks.

I'm going to close this out since the infrastructure work it describes is now substantially complete, although a great deal of work remains to be done to bring this infrastructure to all applications and implement the full set of features it enables (mostly described in tasks blocked by this one).

I'm going to merge this into T9491, since that's the existing task covering the primary issue here.

First approaches that come to mind, for whatever that's worth:

To clarify, you want Phabricator to turn you into a sandwich?

I ultimately expanded the scope here into a lot of adjacent work in T9132, but a rough version of "better templating" is now available in HEAD and deployed and configured on this server. There's documentation here:

I think this is probably not something we're going to fix.

Ah, okay. I'm not sure what's going on there. I can't immediately reproduce that.

Nothing happened (was added to the text area)

Tech changes out of T9132 (see also T9905) put this on a relatively short timetable and this stuff is no longer active on the major edit workflows so I'm going to land T9860. We probably won't cut a stable this week, and will continue issuing guidance on upgrading smoothly through these changes.

Specifically, the rule is that the lesser of:

I couldn't include F1018337 in the original post?

Additional errata:

"Create Subtask" is a shortcut for "Create Task, then add it as a blocker for this one".

T7661 is also similar.

Actually, that report is already fixed.

Actually, that report is already fixed. For completeness, the behavior adapters should have is:

See also T7961, which is another modular behavior adapters should have.

• You can now technically write this as an extension by extending HeraldAction, although mail is quite complicated and this extension may be challenging to write.
• You could use an extension like the one in P1895 to add a comment instead, although I think this will be caught by notification preferences.
• You can use the action above (reject commit unless they bypass).
• You could use "Add Projects" and then just manually email the offenders who got hit at the end of the week to warn them.

Offhand, I'm inclined to still publish "Herald closed the task." in the "subscribe + close" hypothetical, which I think is the current behavior.

This behavior is "correct" in some sense (Herald really did perform the "strongest" action in the transaction group) but the sorting on tiebreakers is likely wrong (see D14680 for a similar case) and we should sort actions by real users over actions by Herald at the same strength.

The build for Dyyyy should not fail. They do not fail in the upstream.

Related, the test console has a big if ($x instanceof ...) mess that should be pushed down into Adapters. A reasonable flow might be:

The new tools from T9132 are now in HEAD (see D14718 for documentation, which will land shortly).