Page MenuHomePhabricator

scode (Peter Schuller)
User

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Wednesday

  • Clear sailing ahead.

User Details

User Since
Jan 11 2016, 9:47 PM (456 w, 6 d)
Availability
Available

Recent Activity

Aug 10 2016

scode added a comment to T11450: Distinguish between issue and non-issue inline comments.

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

Aug 10 2016, 8:03 PM · Inline Comments, Restricted Project, Feature Request
scode added a comment to T11450: Distinguish between issue and non-issue inline comments.

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.

Aug 10 2016, 7:04 PM · Inline Comments, Restricted Project, Feature Request
scode added a comment to T11450: Distinguish between issue and non-issue inline comments.

A few thoughts.

Aug 10 2016, 6:33 PM · Inline Comments, Restricted Project, Feature Request

Jun 22 2016

scode added a comment to T11199: User visible error message on X-Forwarded-For header.

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.

Jun 22 2016, 6:42 PM · Bug Report
scode added a comment to T11199: User visible error message on X-Forwarded-For header.

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

Jun 22 2016, 6:25 PM · Bug Report
scode closed T11199: User visible error message on X-Forwarded-For header as Invalid.
Jun 22 2016, 6:24 PM · Bug Report
scode created T11199: User visible error message on X-Forwarded-For header.
Jun 22 2016, 6:18 PM · Bug Report

Jun 17 2016

scode added a comment to T11085: Prevent users from generating an ambiguous commit message by editing revisions with the web UI.

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

Jun 17 2016, 4:51 PM · Prioritized, Restricted Project, Arcanist, Bug Report

Jun 16 2016

scode added a comment to T9028: Phabricator handles commits which are published and later deleted poorly.

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

Jun 16 2016, 10:43 PM · Restricted Project, Prioritized, Audit, Restricted Project
scode added a comment to T9028: Phabricator handles commits which are published and later deleted poorly.

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.

Jun 16 2016, 8:11 PM · Restricted Project, Prioritized, Audit, Restricted Project
scode added a comment to T9028: Phabricator handles commits which are published and later deleted poorly.

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?

Jun 16 2016, 7:35 PM · Restricted Project, Prioritized, Audit, Restricted Project

May 25 2016

scode added a project to T9028: Phabricator handles commits which are published and later deleted poorly: Restricted Project.
May 25 2016, 9:37 PM · Restricted Project, Prioritized, Audit, Restricted Project

May 24 2016

scode added a comment to T2543: Add a formal "Draft" / "Not Yet Ready for Review" state to Differential.

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

May 24 2016, 8:22 PM · Customer Impact, Restricted Project, Restricted Project, Prioritized, Differential
scode added a comment to T4103: Implement "Role Profiles" to provide search, homepage and application defaults.

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

May 24 2016, 7:56 PM · Prioritized, Restricted Project, Restricted Project, Applications, Dashboards

May 23 2016

scode added a comment to T3025: Detect when browser and account timezone settings differ and prompt user to reconcile them.

That's a lot more clear, thanks!

May 23 2016, 7:07 PM · Prioritized, Restricted Project, User Preferences
scode added a comment to T2543: Add a formal "Draft" / "Not Yet Ready for Review" state to Differential.

The user story most important to us is:

May 23 2016, 6:38 PM · Customer Impact, Restricted Project, Restricted Project, Prioritized, Differential
scode added a comment to T3025: Detect when browser and account timezone settings differ and prompt user to reconcile them.

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.

May 23 2016, 4:45 PM · Prioritized, Restricted Project, User Preferences

May 20 2016

scode moved T1279: Show per-reviewer status in Differential revision reviewer list from Restricted Project Column to Restricted Project Column on the Restricted Project board.
May 20 2016, 11:31 PM · Restricted Project, Differential
scode moved T10512: Implement `user.search` Conduit API method from Restricted Project Column to Restricted Project Column on the Restricted Project board.
May 20 2016, 11:31 PM · Prioritized, Restricted Project, People, Conduit, Feature Request
scode added a comment to T10512: Implement `user.search` Conduit API method.

To further elaborate:

May 20 2016, 11:30 PM · Prioritized, Restricted Project, People, Conduit, Feature Request
scode added a comment to T8629: Create some kind of queue of profile/settings action items for users.

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

May 20 2016, 9:28 PM · Restricted Project, People
scode added a comment to T8629: Create some kind of queue of profile/settings action items for users.

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

May 20 2016, 6:57 PM · Restricted Project, People

May 17 2016

scode added a comment to T10939: Support for OWNERS files.

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.

May 17 2016, 3:18 PM · Prioritized, Restricted Project, Owners

May 11 2016

scode added a comment to T10694: Improve behavior of context for inline comments in mail.

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.

May 11 2016, 7:36 AM · Prioritized, Restricted Project, Differential, Mail
scode added a comment to T10939: Support for OWNERS files.

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.

May 11 2016, 7:20 AM · Prioritized, Restricted Project, Owners

May 6 2016

scode added a comment to T10694: Improve behavior of context for inline comments in mail.

Overall it looks a *lot* better now :)

May 6 2016, 11:11 PM · Prioritized, Restricted Project, Differential, Mail

Apr 28 2016

scode added inline comments to D15817: Document all the hypothetical URI features we plan to support soon.
Apr 28 2016, 8:41 PM
scode added a comment to T10895: Support`arc browse --revision <commit>` and make `arc browse` with no arguments mean `... --revision HEAD`.

Ah, sorry about that!

Apr 28 2016, 6:58 PM · Arcanist, Prioritized, Restricted Project, Feature Request
scode added a comment to T10895: Support`arc browse --revision <commit>` and make `arc browse` with no arguments mean `... --revision HEAD`.

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.

Apr 28 2016, 6:45 PM · Arcanist, Prioritized, Restricted Project, Feature Request
scode moved T10895: Support`arc browse --revision <commit>` and make `arc browse` with no arguments mean `... --revision HEAD` from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Apr 28 2016, 6:00 PM · Arcanist, Prioritized, Restricted Project, Feature Request
scode added a project to T10895: Support`arc browse --revision <commit>` and make `arc browse` with no arguments mean `... --revision HEAD`: Restricted Project.
Apr 28 2016, 6:00 PM · Arcanist, Prioritized, Restricted Project, Feature Request
scode updated the task description for T10895: Support`arc browse --revision <commit>` and make `arc browse` with no arguments mean `... --revision HEAD`.
Apr 28 2016, 5:58 PM · Arcanist, Prioritized, Restricted Project, Feature Request
scode created T10895: Support`arc browse --revision <commit>` and make `arc browse` with no arguments mean `... --revision HEAD`.
Apr 28 2016, 5:58 PM · Arcanist, Prioritized, Restricted Project, Feature Request

Apr 19 2016

scode added a comment to T3025: Detect when browser and account timezone settings differ and prompt user to reconcile them.

Makes sense!

Apr 19 2016, 6:45 PM · Prioritized, Restricted Project, User Preferences
scode added a comment to T3025: Detect when browser and account timezone settings differ and prompt user to reconcile them.

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.

Apr 19 2016, 7:16 AM · Prioritized, Restricted Project, User Preferences

Apr 7 2016

scode moved T10512: Implement `user.search` Conduit API method from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Apr 7 2016, 9:44 PM · Prioritized, Restricted Project, People, Conduit, Feature Request

Apr 4 2016

scode added a comment to T10722: Communicate drag policies clearly in the workboard/list UIs.

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

Apr 4 2016, 10:03 PM · Workboards (v3), Bug Report
scode added a comment to T10722: Communicate drag policies clearly in the workboard/list UIs.

Definitely open to this being a user expectation bug.

Apr 4 2016, 9:59 PM · Workboards (v3), Bug Report

Feb 23 2016

scode moved T9210: break apart Publish/Notify repo setting from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Feb 23 2016, 12:02 AM · Restricted Project, Restricted Project, Diffusion

Feb 8 2016

scode added a comment to T10283: improve differential emails, optimizing for efficiency.

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

Feb 8 2016, 9:00 PM · Mail, Restricted Project, Feature Request

Feb 5 2016

scode moved T10283: improve differential emails, optimizing for efficiency from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Feb 5 2016, 4:29 PM · Mail, Restricted Project, Feature Request
scode added a project to T10283: improve differential emails, optimizing for efficiency: Restricted Project.
Feb 5 2016, 4:28 PM · Mail, Restricted Project, Feature Request
scode updated subscribers of T10283: improve differential emails, optimizing for efficiency.
Feb 5 2016, 4:11 PM · Mail, Restricted Project, Feature Request
scode created T10283: improve differential emails, optimizing for efficiency.
Feb 5 2016, 4:11 PM · Mail, Restricted Project, Feature Request

Jan 28 2016

scode added a comment to T10233: arc error message unclear for accepted revision in "plan change" state.

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.

Jan 28 2016, 4:47 AM · Restricted Project, Bug Report
scode added a comment to T10233: arc error message unclear for accepted revision in "plan change" state.

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

Jan 28 2016, 4:41 AM · Restricted Project, Bug Report