Feature Request (Needs Information)Milestone
ActivePublic

Recent Activity

Yesterday

chad closed T10388: Additional remarkup assistance buttons for decriptions as "Wontfix".

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.

Mon, Mar 27, 3:55 PM · Feature Request (Needs Information), Design & Planning, Remarkup

Mon, Mar 20

nfirmani added a comment to T12423: Add link for Revisions back to profile pages .

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

Mon, Mar 20, 10:01 PM · Feature Request (Needs Information)
chad added a comment to T12423: Add link for Revisions back to profile pages .

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.

Mon, Mar 20, 9:52 PM · Feature Request (Needs Information)
nfirmani added a comment to T12423: Add link for Revisions back to profile pages .

Interesting, that decision makes sense to me.

Mon, Mar 20, 9:38 PM · Feature Request (Needs Information)
epriestley added a comment to T12423: Add link for Revisions back to profile pages .

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

Mon, Mar 20, 9:34 PM · Feature Request (Needs Information)
epriestley added a comment to T12423: Add link for Revisions back to profile pages .

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.

Mon, Mar 20, 9:33 PM · Feature Request (Needs Information)
epriestley added a comment to T12423: Add link for Revisions back to profile pages .

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.

Mon, Mar 20, 9:30 PM · Feature Request (Needs Information)
nfirmani added a comment to T12423: Add link for Revisions back to profile pages .

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

Mon, Mar 20, 9:27 PM · Feature Request (Needs Information)
chad added a comment to T12423: Add link for Revisions back to profile pages .

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

Mon, Mar 20, 9:23 PM · Feature Request (Needs Information)
nfirmani added a comment to T12423: Add link for Revisions back to profile pages .

Sure, apologies for the lack of clarity.

Mon, Mar 20, 9:19 PM · Feature Request (Needs Information)
chad added a comment to T12423: Add link for Revisions back to profile pages .

Or more specifically, I don't intend to add this back. 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.

Mon, Mar 20, 9:06 PM · Feature Request (Needs Information)
chad edited projects for T12423: Add link for Revisions back to profile pages , added: Feature Request (Needs Information); removed Feature Request.
Mon, Mar 20, 9:01 PM · Feature Request (Needs Information)

Thu, Mar 9

bcooksley added a comment to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?.

@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.

Thu, Mar 9, 9:05 AM · KDE, Feature Request (Needs Information)

Wed, Mar 8

epriestley added a project to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?: KDE.
Wed, Mar 8, 6:36 PM · KDE, Feature Request (Needs Information)
epriestley merged task T12368: better support for "raw" patches, in particular corresponding to uncommitted changes? into T5029: Fill in missing context for low-context diffs against tracked repositories.
Wed, Mar 8, 6:36 PM · KDE, Feature Request (Needs Information)
epriestley updated subscribers of T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?.

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.

Wed, Mar 8, 6:35 PM · KDE, Feature Request (Needs Information)
RJVB added a comment to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?.

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

Wed, Mar 8, 6:26 PM · KDE, Feature Request (Needs Information)
chad added a comment to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?.

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, and so on.

Wed, Mar 8, 5:47 PM · KDE, Feature Request (Needs Information)
epriestley added a comment to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?.

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

Wed, Mar 8, 5:18 PM · KDE, Feature Request (Needs Information)
RJVB added a comment to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?.

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.

Wed, Mar 8, 5:12 PM · KDE, Feature Request (Needs Information)
chad added a comment to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?.

I guess this is pre pre-commit review?

Wed, Mar 8, 4:30 PM · KDE, Feature Request (Needs Information)
chad added a comment to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?.

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.

Wed, Mar 8, 4:09 PM · KDE, Feature Request (Needs Information)
RJVB added a comment to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?.

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.

Wed, Mar 8, 3:48 PM · KDE, Feature Request (Needs Information)
RJVB renamed T12368: better support for "raw" patches, in particular corresponding to uncommitted changes? from "better support for "raw" patches?" to "better support for "raw" patches, in particular corresponding to uncommitted changes?".
Wed, Mar 8, 3:47 PM · KDE, Feature Request (Needs Information)
chad edited projects for T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?, added: Feature Request (Needs Information); removed Feature Request.
Wed, Mar 8, 3:14 PM · KDE, Feature Request (Needs Information)

Fri, Mar 3

chad merged task T12341: Set cursor default focus to input field when selecting "Other Project" from access policy dropdown into T12273: Single input/typeahead dialogs should be consistently simpler.
Fri, Mar 3, 9:49 PM · Feature Request (Needs Information)

Thu, Mar 2

eliaspro added a comment to T12341: Set cursor default focus to input field when selecting "Other Project" from access policy dropdown.

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

Thu, Mar 2, 10:39 PM · Feature Request (Needs Information)
chad added a comment to T12341: Set cursor default focus to input field when selecting "Other Project" from access policy dropdown.

Yeah any dialog now that I think about it.

Thu, Mar 2, 10:08 PM · Feature Request (Needs Information)
epriestley added a comment to T12341: Set cursor default focus to input field when selecting "Other Project" from access policy dropdown.

(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.)

Thu, Mar 2, 9:49 PM · Feature Request (Needs Information)
epriestley added a comment to T12341: Set cursor default focus to input field when selecting "Other Project" from access policy dropdown.

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.

Thu, Mar 2, 9:48 PM · Feature Request (Needs Information)
chad edited projects for T12341: Set cursor default focus to input field when selecting "Other Project" from access policy dropdown, added: Feature Request (Needs Information); removed Feature Request.
Thu, Mar 2, 9:41 PM · Feature Request (Needs Information)

Jan 26 2017

epriestley closed T12156: User is unable to close an audit for own commits, even audit.can-author-close-audit is set to TRUE as "Resolved".

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

Jan 26 2017, 2:22 PM · Feature Request (Needs Information)
Ondrej added a comment to T12156: User is unable to close an audit for own commits, even audit.can-author-close-audit is set to TRUE.

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.

Jan 26 2017, 2:18 PM · Feature Request (Needs Information)
epriestley added a comment to T12156: User is unable to close an audit for own commits, even audit.can-author-close-audit is set to TRUE.

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

Jan 26 2017, 2:15 PM · Feature Request (Needs Information)
epriestley added a comment to T12156: User is unable to close an audit for own commits, even audit.can-author-close-audit is set to TRUE.

he has to remove the group and add himself as Auditor

Jan 26 2017, 2:12 PM · Feature Request (Needs Information)
Ondrej added a comment to T12156: User is unable to close an audit for own commits, even audit.can-author-close-audit is set to TRUE.

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.
Jan 26 2017, 2:07 PM · Feature Request (Needs Information)
epriestley edited projects for T12156: User is unable to close an audit for own commits, even audit.can-author-close-audit is set to TRUE, added: Feature Request (Needs Information); removed Bug Report.
Jan 26 2017, 1:52 PM · Feature Request (Needs Information)

Jan 12 2017

chad closed T12072: Tighten "Needs Review" category as "Invalid".

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

Jan 12 2017, 3:11 AM · Feature Request (Needs Information)

Jan 6 2017

chad added a comment to T12072: Tighten "Needs Review" category.

See also T4144#175505

Jan 6 2017, 4:17 AM · Feature Request (Needs Information)
chad edited projects for T12072: Tighten "Needs Review" category, added: Feature Request (Needs Information); removed Feature Request.
Jan 6 2017, 3:29 AM · Feature Request (Needs Information)

Jan 4 2017

chad added a comment to T12060: Colorblind accessibility for red/green highlighting in e-mails.

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

Jan 4 2017, 3:19 PM · Accessibility, Design & Planning, Feature Request, Restricted Project
epriestley added a comment to T12060: Colorblind accessibility for red/green highlighting in e-mails.

What color scheme would the user prefer?

Jan 4 2017, 8:38 AM · Accessibility, Design & Planning, Feature Request, Restricted Project
gregprice added a project to T12060: Colorblind accessibility for red/green highlighting in e-mails: Restricted Project.
Jan 4 2017, 5:14 AM · Accessibility, Design & Planning, Feature Request, Restricted Project
neilfitz edited the description of T12060: Colorblind accessibility for red/green highlighting in e-mails.
Jan 4 2017, 2:32 AM · Accessibility, Design & Planning, Feature Request, Restricted Project
neilfitz added a comment to T12060: Colorblind accessibility for red/green highlighting in e-mails.

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

Jan 4 2017, 2:32 AM · Accessibility, Design & Planning, Feature Request, Restricted Project
chad added a comment to T12060: Colorblind accessibility for red/green highlighting in e-mails.

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

Jan 4 2017, 2:18 AM · Accessibility, Design & Planning, Feature Request, Restricted Project
chad added a comment to T12060: Colorblind accessibility for red/green highlighting in e-mails.

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

Jan 4 2017, 2:18 AM · Accessibility, Design & Planning, Feature Request, Restricted Project
neilfitz added a comment to T12060: Colorblind accessibility for red/green highlighting in e-mails.

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

Jan 4 2017, 2:17 AM · Accessibility, Design & Planning, Feature Request, Restricted Project
neilfitz added a comment to T12060: Colorblind accessibility for red/green highlighting in e-mails.

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

Jan 4 2017, 2:15 AM · Accessibility, Design & Planning, Feature Request, Restricted Project
chad added a comment to T12060: Colorblind accessibility for red/green highlighting in e-mails.

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

Jan 4 2017, 2:09 AM · Accessibility, Design & Planning, Feature Request, Restricted Project