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?

Okay, after some tests, looks like the user has deuteranopia. Consistent with what you have there.

http://www.color-blindness.com/deuteranopia-red-green-color-blindness/

Of the four, this is the only type that's difficult:

Uh, I'll see if they can take an online test to narrow it down further.

They don't know what type they have more specifically than red-green, unfortunately.

There are 4 types of red-green color blindness, and they all work differently.

I went through color blindness simulators and I can distinguish every type using the supplied image. So without more information, I'm not sure how to proceed here. Why can't you ask them what type of color blindness they have, specifically?

I'm not sure I understand what you mean. To be clear, the user doesn't have an issue reading the text; they have an issue distinguishing between red highlight and green highlight. I think it would be even more confusing without any highlighting at all.

hopefully not a feature request, thanks.

See Consulting if you'd like a one-on-one answer from the upstream.

Hey @epriestley, Ideally i'd just like to ask a question on where this feature has gone. I posted in the IRC channel but got no response.

Please see Contributing Feature Requests for instructions on filing a feature request which can become a maintainable feature in the upstream.

We haven't received more information about this in more than a month.

Root problem: To ensure quality software, I want to make sure that all reviewers accept a change.

Most likely your request is covered by other tasks.

Do you have blocking reviewers on these diffs?

I have read it, but after re-reading let me give this another go. My apologies, I know you guys are busy and I'm sitting here not knowing how to properly formulate a problem description.

I think that's just a rewording of the original description, and doesn't provide any new insight or context. It still focuses on a very narrow symptom problem (not being able to see individual reviewer status from the revision list), not the root problem.

@epriestley Oh! You are right. Let me take a stab at my problem then. Some of this is caused by the lack of rules for complex acceptance conditions like in T731.

T1279 is talking about the reviewer list on the detail page (/Dxxx), not the list page (/differential/). This was implemented years ago, so I suspect it isn't a duplicate, unless you're years out of date.

@epriestley @eadler : T1279 is exactly what I was looking for. Thanks guys. Feel free to close this task as duplicate.

This request doesn't describe a root problem, so we can't develop a solution to it. We haven't received any new information in more than a month. See Describing Root Problems and Contributing Feature Requests for help describing root problems and filing feature requests that the usptream can accept.

We don't have enough information about this problem to design a solution, and haven't received more information in more than a month. See Describing Root Problems and Contributing Feature Requests for details on how to submit an actionable feature request.

Nothing actionable here, since we don't plan on adding additional options.

We use a custom field release description of type remarkup. We then export tasks via conduit API to our HTML release notes. In this release description we use some of the remarkup feature set.

Yes that should work for my use case - I've tested and verified this functionality. Thanks!

We ultimately want teams to choose different colors so they can know which workboard they're on at a quick glance.

Yes, I concur, that would be useful.

My understanding is the feature request would be to set a global color instead of white. If all workboards are red or blue or whatever, I don't think it provides any additional hints. I suspect the use case here is @rphl just really likes a specific color and wants them all that color. Which is cool, but we ultimately want teams to choose different colors so they can know which workboard they're on at a quick glance.

I suspect the goal could be to provide visual hints, in addition to the text, to recognize and disambiguate dashboards.