^^ yuh?

I think the primary use case for this UI is editing the value (that's what I'm trying to do about 98% of the time I end up here, at least), so it seems weird to bury that control. On some pages, like differential.fields, it would be buried very deeply if we moved it after the table.

For locked stuff we should probably just not show the "Value" control for most controls. (I think we show it because it's useful for some config that has special controls, but I'm not sure; could also just be something I missed.)

That stuff will deploy on ~Saturday, new UX is roughly this:

(This should deploy in the cluster on Saturday, give or take.)

It's very hard for us to prioritize work which doesn't actually solve real problems, or where we don't understand the greater need. This is why we ask users to describe problems and avoid hypotheticals in the guide describing how to file good feature requests.

What are you trying to accomplish?

RECIPIENTS
cspeckmim (Christopher Speck)

• Self Mail: This recipient is the user whose actions caused delivery of this message, but they have set preferences so they do not receive mail about their own actions (Settings > Email Preferences > Self Actions).
• Forced by Herald: This recipient was added by a "Send me an Email" rule in Herald, which overrides some delivery settings.

Now complete, although not fully deployed in all cases:

I think the automated export flow probably looks something like this:

This should be ready to go now, although I'll wait until we're actually ready to act on it to promote and deploy it.

The biggest remaining issue on this workflow is that the pre-verification workflow is a confusing mess, per T7173.

In particular, T9263 may have motivated development of a local patch.

We haven't made any changes to this in the upstream recently that I can recall or find in git log, so if this behavior really has changed my best guess is that there's a local patch affecting it. The last upstream change which was expected to affect this was rPbcb957b (April 27).

Thanks for the report! I'll take a look at this.

V and Q with a single digit are ignored because of conflation with "Version" and "Quarter" in common usage, respectively.

I suppose we can version detect and just drop this flag. It only matters if the user also has local pre-push hooks which prevent the push, which are presumably/hopefully very rare.

I'm worried it may intimidate users who are worried they can not live up to the requisite level of professionalism.

It looks like some other activity also occurred in the same transaction set. Does the email reveal what it is? That is, do the first two lines look like this?

Older versions of an image are available in the table below. For example, this shows iterations to a high quality professional picture of a cat:

Can you show me the mail headers for the mail you received but did not expect to receive? In particular, the X-Phabricator-Mail-Tags header?