+1, let's revisit after T11451/T8250 and us shipping that to our users.

It's not optional. It's important to not confuse the fact that pressing the button is optional with the fact that a new decision has to be made with every comment.

A few thoughts.

Thanks! That is exactly what we had, and I was not aware of it. And yes, we have this on purpose because of there being a load balancing (trusted) proxy in front of Phabricator. For whatever reason, I assumed Phabricator had it's own X-Forwarded-For handling. Mainly my mistake here was jumping to the assumption that Phabricator was looking at X-Forwarded-For based on the value - even though the error message never indicated that it was.

Closed as "invalid". I apologize for the noise. This was an undocumented Twitter specific patch.

@eadler Did you have enough insight/recollection as to whether all our reported cases were due to users editing in the web UI?

Is there a lack of a git remote prune origin or similar?

Yeah. I just wanted to make sure whether mark-reachable was safe to run without fear of accidentally marking something unreachable that isn't (i.e., if the command were to imply "mark everything in the import queue as unreachable no matter what"). Sorry it was probably a bit of a lazy question since a more careful re-reading of the rest of the ticket would probably have answered it for me.

If the mark-reachable command is used, is it subject to races in the sense that in-flight legit newly importing commits may be marked unreachable, or does it just trigger the process of going back and re-evaluating true reachability of all commits?

In the "final look before publishing" use case, the best value for "Reviewers" is probably the final, effective set of reviewers (i.e., including reviewers from Herald and Owners), so you can see exactly who the revision will be published to. In the competing "share with a few people" use case, the best value for "Reviewers" is only explicit reviewers (you don't want to notify or involve others).

+1 to what Eitan said. The first two of those for sure. The first means we have this horrendous patch in place today in order to make it happen so we don't flood everyone with email :)

That's a lot more clear, thanks!

The user story most important to us is:

I tried it out. One thing I realized was that without having the context of this ticket, during the pop-up after you click the notification, it's not obvious whether the timezone being shown is the *current* setting or the *new setting based on your browser*. That could cause confusion, so would suggest a slight phrasing change there.

To further elaborate:

Yes - my comments were meandering in nature. Sorry, should have made that
clear.

Something somewhat related potentially depending on the implementation you'd imagine is "bulletins". Where you have a user base, and as the operator of the system you want to communicate something to folks in the tool where it's relevant (for example, to aid discovery of a new feature that was added that we think people want to use, or strongly suggest a best practice etc).

Sounds good (including your last comment). I think that from our perspective, we're it seems likely that we'll end up realizing a few problematic edge cases or details once we start integrating fully and it's probably best to wait until then than to try to gain perfect confidence ahead of time. The work done so far and what you outline in your last comment seems sufficient to start doing the integration work and we can surface issues as they arise.

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.

Reading through this discussion, it seems like we've gotten to a point where we have a reasonable simple yet general mechanism that allows us to express what we want in terms of the owners themselves.

Overall it looks a *lot* better now :)

Ah, sorry about that!

My gut feeling is that our users will feel that arc browse --the-revision-for HEAD is too verbose for something that to them is a common and "should be simple" operation. However, if combined with the default behavior as you suggest, such that just arc browse defaults appropriately it would avoid that being a problem while keeping the meaning of the --the-revision-for HEAD option clear.

Makes sense!

FWIW, from our perspective we really want the time zone to be correct (for our users) by default without any manual intervention. From the discussion above, it seems like this ticket is leaning towards a scheme were the user is expected to set their time zone in Phabricator, but displaying a recon dialog if it mismatches the browser.

To be clear, the Community work-around is totally fine for us. This ticket was filed just to call attention to it. We don't have a case where this matters directly for us (we're not using Phabricator for ticketing and thus won't have these workboards; this was just us encountering it when working on this installation of Phabricator).

Definitely open to this being a user expectation bug.

@epriestley Thanks! Sorry about our screw-up with the settings. Looks like we had an internal communication problem. I'll follow up and make sure we're exhausting what settings we have available to us (starting with default options) and return to this and the tickets you linked after that.

This is almost certainly something that is only confusing to entirely new users who aren't yet familiar. I'm not surprised you're not confused if you've used phabricator for a non-trivial amount of time.

That would be more clear. Even better would probably be to say what is is in fact *in*. Such as: