Page MenuHomePhabricator

Feature Request (Needs Information)Milestone
ArchivedPublic

Watchers

  • This project does not have any watchers.
  • View All

Recent Activity

Dec 13 2017

epriestley archived Feature Request (Needs Information).
Dec 13 2017, 1:14 PM

Jun 22 2017

chad added a comment to T12863: adasdasdasdasd.

nyancat

Jun 22 2017, 7:12 AM · Feature Request (Needs Information), Bug Report
avivey closed T12863: adasdasdasdasd as Spite.
Jun 22 2017, 6:46 AM · Feature Request (Needs Information), Bug Report
utsav.kakadiya created T12863: adasdasdasdasd.
Jun 22 2017, 6:27 AM · Feature Request (Needs Information), Bug Report

Jun 13 2017

banica moved T12834: Set new hourly rate for our new colleague from Future to Needs Information on the Feature Request board.
Jun 13 2017, 8:59 AM · Feature Request

Apr 11 2017

chad added a comment to T12423: Bring MenuItem customization options to User Profiles.

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.

Apr 11 2017, 7:20 PM · Dashboards, Restricted Project, Profile
chad added a comment to T12423: Bring MenuItem customization options to User Profiles.

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

Apr 11 2017, 7:19 PM · Dashboards, Restricted Project, Profile
nfirmani added a comment to T12423: Bring MenuItem customization options to User Profiles.

So, what's the word on this?

Apr 11 2017, 6:51 PM · Dashboards, Restricted Project, Profile

Mar 27 2017

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.

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

Mar 20 2017

nfirmani added a comment to T12423: Bring MenuItem customization options to User Profiles.

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

Mar 20 2017, 10:01 PM · Dashboards, Restricted Project, Profile
chad added a comment to T12423: Bring MenuItem customization options to User Profiles.

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.

Mar 20 2017, 9:52 PM · Dashboards, Restricted Project, Profile
nfirmani added a comment to T12423: Bring MenuItem customization options to User Profiles.

Interesting, that decision makes sense to me.

Mar 20 2017, 9:38 PM · Dashboards, Restricted Project, Profile
epriestley added a comment to T12423: Bring MenuItem customization options to User Profiles.

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

Mar 20 2017, 9:34 PM · Dashboards, Restricted Project, Profile
epriestley added a comment to T12423: Bring MenuItem customization options to User Profiles.

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.

Mar 20 2017, 9:33 PM · Dashboards, Restricted Project, Profile
epriestley added a comment to T12423: Bring MenuItem customization options to User Profiles.

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.

Mar 20 2017, 9:30 PM · Dashboards, Restricted Project, Profile
nfirmani added a comment to T12423: Bring MenuItem customization options to User Profiles.

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

Mar 20 2017, 9:27 PM · Dashboards, Restricted Project, Profile
chad added a comment to T12423: Bring MenuItem customization options to User Profiles.

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

Mar 20 2017, 9:23 PM · Dashboards, Restricted Project, Profile
nfirmani added a comment to T12423: Bring MenuItem customization options to User Profiles.

Sure, apologies for the lack of clarity.

Mar 20 2017, 9:19 PM · Dashboards, Restricted Project, Profile
chad added a comment to T12423: Bring MenuItem customization options to User Profiles.

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.

Mar 20 2017, 9:06 PM · Dashboards, Restricted Project, Profile
chad edited projects for T12423: Bring MenuItem customization options to User Profiles, added: Feature Request (Needs Information); removed Feature Request.
Mar 20 2017, 9:01 PM · Dashboards, Restricted Project, Profile

Mar 9 2017

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.

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

Mar 8 2017

epriestley added a project to T12368: better support for "raw" patches, in particular corresponding to uncommitted changes?: KDE.
Mar 8 2017, 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.
Mar 8 2017, 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.

Mar 8 2017, 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?

Mar 8 2017, 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, allow for chain of custody and so on.

Mar 8 2017, 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?

Mar 8 2017, 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.

Mar 8 2017, 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?

Mar 8 2017, 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.

Mar 8 2017, 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.

Mar 8 2017, 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?.
Mar 8 2017, 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.
Mar 8 2017, 3:14 PM · KDE, Feature Request (Needs Information)

Mar 3 2017

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.
Mar 3 2017, 9:49 PM · Feature Request (Needs Information)

Mar 2 2017

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 :)

Mar 2 2017, 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 typeahead dialog now that I think about it.

Mar 2 2017, 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.)

Mar 2 2017, 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.

Mar 2 2017, 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.
Mar 2 2017, 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, 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, Feature Request, Restricted Project