We had a user that was confused and frustrated because on the task view page projects are under a "Projects" field but on the edit page are under a "Tags" field.

One followup request from D14935: Show the workboard column along with the project. Obviously there is a space vs information value tradeoff, but if workboard columns are relevant anywhere wouldn't it be in Workboards? This was feedback from one of our product managers who looks at many different workbaords, not just a single team's.

See also T7013, and maybe T9161.

See also T3301, T8594, & T4558

The ordering of blogs on the right /phame is (I think after looking at it) creation date. I'm not sure that is the more useful than just lexographical(?) and feels bit implementation detail-y.

cat unassigned this task, evicting dog from the seat of power.

I'm very open to making build variables extensible, but I think the bar for upstream defaults needs to get stricter and become "this is critical information for many build processes", not "this helps to simplify at least one build process on one install somewhere in the world".

The API endpoint for "make an http request" is ci.example.com/job/{repository_short_name}/build

T10479: Harbormaster build steps are duplicated in the UI

Would this eliminate most of the benefit from cron based "sync refs from the main repo" glue?

In T10412#160950, @epriestley wrote:

Change milestoneNumber in phabricator_project.project to reorder milestones.

You got all of the mineral costs correct!

Initially, I've found myself digging iterations for the magic workboard columns even for "evergreen" things that are not really iterations. I wanted to reorder them, but I'm confused what the UI is trying to tell me. Can I not re-order iterations, only control how they appear relative to "normal" columns, or is this busted?

I feel like I am admitting a secret weakness, but when I use GitHub or another UI with a preview toggle I find myself missing the live updating preview that Phabricator has. I hope this admission does not invalidate my elite command line user neck beard.

In T10374#161140, @epriestley wrote:

For anyone else with other use cases in this vein (roughly "select an existing file from Phabricator" as an alternative to "select a file from the filesystem"), can you run through the scenarios in which you'd want to use this, and why it's preferable to just downloading the file first?

In T9897#151198, @epriestley wrote:

Couple of thoughts, not necessarily unbeta stuff:

• Now that I'm actually using Phame, figuring out some kind of monogram/remarkup thing for it would be sort of nice so it's a little easier to reference a post in tasks/wikis/etc (my use case is that when I write a "Development Log" or "High Horse Soapbox" post, I'm often providing context for things elsewhere, and want to link it from that place/places). I don't think actual POST123 monograms are great for this, but this motivate:

Possibly related: T6469: Make it more clear which Workboard Column is 'default'

In T9897#155081, @chad wrote:

If they can post to the blog, they can read the draft.

After observing the feature on this install I feel like the email messages are misleading, or I'm confused about how sub-projects work.

I just added about 100 staging repositories by hand. I hope I spelled everything right!

I'd like to be able to search for watchers like I can for members:

• If you or an overwhelmed co-worker over-zealously watched/subscribed to too many projects, it would be nice to be able to undo that without playing whack-a-mole as emails come in a week later.
• If people are spying on my projects, I need some sort of counter-espionage capability.

We have like 50 "Team X Sprint 123" projects that would be nice to turn into "actual" sprints. But they are all old sprints so that's just for my need to keep things looking tidy.

If you are are extremely adventurous, you could make a checkstyle-daemon, some start-daemon-or-use-if-already-running command (Maybe gradle in daemon mode can already do something like that?), and a custom ArcanistLinter that talks to it. That's a significant amount of work, but does not clash with arc's current world view.

I've been using phame for an internal announcement blog (stuff like "we upgraded phabricator!"). I've found it helpful to write a draft when preparing the release, and then publish it whenever the release actually happens. One minor issue is that posts are displayed in the order they are drafted, not the order they are published. This means the "we upgraded on Thursday" post shows up on Wednesday, and is not even the most recent post since there was another one on Wednesday.

This has tripped me up a few times (maybe since arc was made great again?) and I think it happens when you do arc land foo instead of arc land in foo.

What do you use it for? That is, what are you trying to do when you click it?

We removed the default task link because in many cases, the link to all tasks wasn't used, wasn't useful, or wasn't the best link (e.g., maybe several links or a link with different filters would be better). Particularly, the link was often redundant when projects use workboards.

FWIW I don't think I had clicked on since first testing out typeahead and had come to associate it with "this is a magic typeahead box" not "click for more options".

Perhaps Phabricator should integrate with this node api?

We ran into a case where archived packages were trigger builds, which didn't feel right and was causing problkems. I'm not sure what the default behavior loadAffectedPackages should be or what would be most consistent with how archiving is handled elsewhere.

One hovercard related suggestion in T10187: hard to understand status of sub-tasks from parent was to add projects/columns to Hovercards so that when mousing over subtasks you can see what projects they are in without opening them all. It looks like the latest mock has that so

I've been trying Phame out internally and it's pretty sweet. The one thing I could not figure out how to do (and maybe the answer is I can't) was how to share a draft with someone to read before it's published. I tried adding them as a subscriber to the draft but that did not give them permission.

In T10187#154936, @chad wrote:

• Other projects are coming to workboards

Another use case for this query would be to visualize the 'status' of subtasks on a workboard by filtering on 'blocked by Txxx'. For example, maybe some of the subtasks are Done while others are languishing in Backlog.

The workflow I used when introducing linting was:

• Temporarily enable a large/default sent of rules, run with --everything and get the lay of the land, maybe make a list of common errors or get a list of all options from the linter itself
• Decided that rule X looked reasonable ("no trailing whitespace" or something like that)
• Send a diff out for review that fixed X and enabled the X linter rule
• Repeat.

Currently, I find it challenging to find existing failures.

Do you see there being a "Blessed" foo-linter (maybe as a repo on this instance?), or will there be multiple foo-tributes fending themselves in the wilds of github? At least one nice thing about having linters upstream is that you get to use phabricator (including arc lint!) to develop them.

On the flexibility side of this I've managed to run into the 32 character callsign limit. We like long names? ¯\_(ツ)_/¯

Is phabricator the name of the user running the daemons? Is that the same as the user running the web server? Permissions between these users can be a problem.

FWIW being able to change projects without going to the edit screen was what I was most looking forward to from stackable actions. "Set Projects" feels like the "obvious" choice because that is what I am already familiar with in the edit page.

Sounds good to me. Thanks for looking.

CURVEBALL: It would be cool if a run-checkstyle-via-maven linter could reuse some of this, but I'm unsure what that would look like at this point (maven is sort of complicated, see T9223 for some previous discussion).

(I used the "Land Revision" button this time and as far as I can tell no wild mutations occurred.)

• arc liberating
• rebased

I think as a practical matter to make larger image transforms work consistently the timeout will also need to be bumped. We patch that locally because otherwise Business Critical Memes are inoperable, but as a DDoS vector it's iffy for public installs to have a large timeout. I'm not sure if large files are also a problem for public installs.. T5258 has some related discussion.

My stacktrace:

After D14356, arc land will preserve authorship and author date data. Since arc patch also preserves them, the net effect should be preserved authors.