We're OK leaving this open to understand impact to other installs or similar needs in customizing user profiles, but to date no other requests have happened.

I don't see a compelling reason to add a link to every Phabricator install for a single user.

So, what's the word on this?

I don't see anything here worth moving forward. I don't think the bar needs to cover more advanced topics and more advanced users should be OK with reading documentation.

Fair point, there was a bit of overlap, and the end result of a revision is super important (the commit).

Yeah we had both "commits" and "revisions", which had a bit of overlap. My main concern was if you were using this information to learn about a person, actual commits should hold more weight over temporal information like revisions.

Interesting, that decision makes sense to me.

(Commit-date ordering would also mean that forward-dated commits would be stuck to the top forever.)

That is, we order things by discovery date (when we learned about the existence of the commit), which is tamper-proof, rather than author date or committer date, which are freely mutable by the client.

If you just updated after more than a year, you are probably seeing imports from the change in T6878. Once those finish, things will settle down and "commits" will begin reflecting what you expect.

I believe there are plans to update it more than once a year at least

I'll take a look at the commits bug here shortly. Do you expect your install to keep more up to date?

Sure, apologies for the lack of clarity.

Or more specifically, I don't intend to add this back without spending more time thinking about the problem it solves. There are other possible solutions (including allowing installations to customize a user's sidebar) but in the context of doing a code review, I can't think of any benefit here. It's helpful for us to understand the entire problem you're looking to solve. If knowing a user's current revisions is important in the context of performing another code review, we'd like to know what that information is and why. What information do you get from it, and what decisions do you make differently because of it.

@epriestley my apologies for this. I had sent out a memo previously asking for everyone to file tasks on our Phabricator so that I could co-ordinate things from there. It seems some folks have missed that, so i've now resent it to a wider audience.

I'm going to merge this into T5029. This is an extremely low priority for this upstream because this workflow is virtually unheard of among full-time software development professionals (see "Target Audience" in Contributing Feature Requests) because it is inherently error-prone.

How do you make guarantee that unrelated, simultaneous, uncommitted changes in the same working copy do not interfere with each other?

Maybe a better way to explain Phabricator's philosophy is that it's build on code quality. That is, if we have to equally choose between developer efficiency and code quality, code quality will win because we feel code quality leads to greater long-term efficiency. It means less likelihood of wasting reviewers time, or chasing bugs, or missing issues because of easily catchable programmatic mistakes. Is it a great workflow if you're just fixing a typo in a document file? Not at all. But 99% of revisions are not typo fixes. With a commit, we can run builds, show reviewers full context diffs, allow for arc to patch diffs, allow for chain of custody and so on.

How do you make guarantee that unrelated, simultaneous, uncommitted changes in the same working copy do not interfere with each other?

The problem to be solved is that workflows as I've tried to describe aren't possible. Workflows where there is no official policy that changes first have to be committed, signed off or whatever before they can be considered for inclusion upstream. Or if you want, workflows in a more relaxed community with smaller and larger contributions coming in from a wide variety of users and developers not all of whom are experts in using git, svn or what have you.

I guess this is pre pre-commit review?

We want to know the problem you feel that feature solves specifically, not just that you want it. You can run patches manually or run arc diff --preview to just preview changes. But offhand I don't see any workflow benefit to reviewing non committed changes and don't recall any requests for such a feature.

Sorry, the Root Problem was clear enough in my head but apparently not explicit enough in the OP. I hope to have addressed that now.

Ok, then feel free to dismiss this one… I didn't expect those kind of complexities behind this :)

Yeah any typeahead dialog now that I think about it.

(I think I've used this workflow fewer than 5 times outside of testing, and although similar workflows like "Award Badge" and "Add Project Members" have the same issue, I think they're similarly rare.)

This is also nontrivial: when we display a dialog, we already attempt to focus the first input. But the first input here is a tokenizer, not a real input, and naively focusing it fails because it hasn't activated or rendered yet.

What for is "audit.can-author-close-audit" then?

You may be able to use Projects or Owners to create groups. Any member of a Project or Package auditor can accept on behalf of the project or package.

You could also add a condition like this to your rules which trigger audits:

he has to remove the group and add himself as Auditor

Standard workflow is:

• Herald adds a group of people responsible for the audit to every commit.
• An Auditor picks several commits (he has to remove the group and add himself as Auditor, so no other auditors pick the same commit at the same time)
• Then Auditor accepts a commit or raises a concern.
• When the concern is raised, the Author prepares a new commit fixing this concern with commit message "Depends on ..."
• Then the Author has to go to the Phabricator and change the state to "Needs Verification"; also he should assign this fixing commit to the same Auditor (unfortunately, I don't know how to do this automatically, via commit message or Herald).
• Now the Auditor can see both commits and can accept them.

Closing for lack of feedback. You can make custom dashboard panels for whatever query / state you want to track.

See also T4144#175505

Slack has some nice color blind themes, which I use as my normal theme.

What color scheme would the user prefer?