I mostly have T8887 working, but there's currently no way for a package to be rendered unambiguously in Reviewers: ... or Subscribers: ... from the command line in a plain text commit message, so this may be a little more involved than I'd hoped. Everything works fine until you try to interact with a revision that has package relationships, then you get into trouble:

Moving this to "Paused" since we're waiting on feedback / deployment / bug reports / things to catch on fire.

• Patches from metamta.differential.inline-patches should be formatted more nicely in HTML mail at HEAD.
• metamta.differential.unified-comment-context has been removed and we now raise setup guidance about it.
• The View Revision button is functional locally, but waiting on design once @chad gets back from vacation next week, since my version of it looks a lot like I designed it (D15884).
• Swapping HTML mail to become the default is ready (D15885) but waiting on the button and maybe a few other designey tweaks we want to consider.
• There's an hour or so of time across all of that which I haven't tabulated yet, but I'll settle it up once those changes actually land.

We're prioritizing the research to estimate how much work this is so we can possibly eventually prioritize it, so this is going into the queue, but don't read too much into it.

In T10694#174693, @jcarrillo7 wrote:

@epriestley Thats good to know. Also, will this change include formatting the Change Details section of emails? That one is currently a blob of visually unparseable text even in HTML emails.

(I'm just getting this into the preflight column for communication purposes since there's a slot reserved, we won't start work on this until we have an explicit confirmation.)

I think this is the current state of the world. I'm planning to tackle the three major issues noted below (observed repository versioning, repository lock granularity, device enrollment behavior) and then try to wind down this phase, move all this followup work to a new "make clustering more powerful" sort of task, and then plan where to go from there based on which goals are most important (scalability vs multi-region vs read-only vs hg/svn vs drydock vs whatever crops up as installs actually deploy this stuff).

T10748 is wrapping up, and repositories now show cluster status in the new "Storage" panel of the new UI:

I think this is substantially complete now. There will probably still be a trickle of issues as this gets more use and T10923 has some stuff that didn't get fully addressed here, but everything I've been tracking is in reasonable shape as far as I'm aware.

The problem is that a user will not read the entire email from top to bottom. There is far too much information to do that on every email that gets sent, and most of it is essentially boiler plate.

I'm not sure what the story behind T10283 is, since it configures a lot of options which modify how mail is laid out, but the expectation is that mail is already organized in the best order for making triaging decisions easy. But the triage flow is to read the whole mail from the beginning, top to bottom, starting with the subject and ending with a link to the object.

@epriestley Thats good to know. Also, will this change include formatting the Change Details section of emails? That one is currently a blob of visually unparseable text even in HTML emails.

In T10694#174460, @epriestley wrote:

Would putting a large clickable "view thing" button in HTML email like the mock in T6600 potentially help address points (1) and (2) -- something like this?

Would putting a large clickable "view thing" button in HTML email like the mock in T6600 potentially help address points (1) and (2) -- something like this?

I'm one of the users whose feedback Peter has been relaying, so let me explain my situation.

This is great, thank you! :-D

T10748, which provides the new cluster management UI for repositories, is nearing completion. This makes cluster setup more manageable and at least provides a pathway forward for Almanac stuff in the future, although it does not yet make Almanac / service management explicitly selectable when creating a repository (for now, new repositories allocate on a random open service).

We hit a couple of minor issues (e.g. D15856, D15865) in the last few days, but this seems to be working in production.

A very specific example of my confusion is the decision to place the link to the revision first in the mockup on T10283, and how it contrasts with the stated problem of triage efficiency:

(I think this is broadly similar to the original discussion on T10283, which also framed problems in terms of efficiency but also appeared to enable every inefficient/low-signal option available.)

As a thought experiment, if we sent one email per inline comment like GitHub does (and just repeated the author information several times in the body or something), I think that would technically satisfy all the points you raise:

This feedback is also sort of hard for me to understand.

The "epriestley added a comment" and/or "epriestly added inline comments" while technically having the appropriate information, is pretty much visual noise that as a reader of a huge number of these emails you just sift over and want to jump straight to the meat of the matter. These changes will make said meat of the matter a lot more prominent and trivial to jump to, but it means you want the identity to be *right there* as well.

Is metamta.can-send-as-user not configured in your environment? My expectation is that the mail comes "From" the user writing all the text in the mail, which makes it clear who they are. I expect that this information is normally prominent in the UI of most mail clients.

Overall it looks a *lot* better now :)

We iterated on the design a bit and ended up here:

@jcarrillo7, something in that vein will split out of T1460 eventually but we don't have a specific plan for it yet. I don't intend to address it as part of this task.

@epriestley This is kind of random but this looks like it will look really cool in email. Is there any chance of bringing these snippets into the discussion view on a review instead of just the links to the inline comments? Kind of like how github does this?

This isn't the most thrilling UI but seems to get the job done. T10912 covers one minor followup issue.

This is getting somewhere functionally; we're going to iterate on the design a bit more internally.

Spacing/padding is definitely pretty iffy in Mail.app, at least.

That seems to be doing something fairly reasonable in my client, yell if it looks funky somewhere else:

I think this isn't really too bad. The major issue is that we can't use stylesheets in email because Gmail doesn't support them, so we need to emit markup with inline style attributes.

This is now live in HEAD of master, and deployed to secure. Here's phabricator/ on this install:

(☞ﾟヮﾟ)☞ Prioritized ☜(ﾟヮﾟ☜)

This is now mostly built as a new "shadow UI" and we're nearly ready to cut over and start having it affect repository behavior.

Great, I'm glad to hear things are working for you. Thanks for your help testing this out!