T5701 describes a strategy for Pygments styles. I don't think we should tackle that as an accessibility issue, but I think building it as a user preference issue is reasonable.

If you configure your project so that arc unit runs your tests and then make your Buildkite build run arc unit --everything --target $HARBORMASTER_TARGET_PHID --conduit-token ..., you should get full reporting support. Then arc unit on its own will also work, arc diff will get the same integration, etc.

I've recently found myself wishing for couple kinds of functionality that would connect calendar and maniphest:

• "due date" for tasks,
• recurring tasks (just like events)
• age-based priority for tasks (dunno if calendar would be involved, but i've seen some instances of similar FRs popping up)

Any thoughts on deeper integration with Phabricator? Namely:

• Reporting back which tests passed/failed
• Reporting back code coverage (I guess right now it's part of reporting tests via the API, but I'd be happy even if it's merged under 1 dummy test case)

:/ colors are hard. From my end, I'm very happy with what I ended up doing in Stylish (and this conversation helped, thank you) so it's not as pressing for me anymore. But LMK if there's anything I can help test out.

Basically, can we support "Large Fonts" and "Colorblind Diffs" at the same time?

if td.new-full just used td.new's background color instead (#eaffea). I think it's because:

Based on http://enchroma.com/test/result/medium-protan/?completed=1&summary=moderate+protan&axis=3.11&exta=87.34&extb=4.85&lcs=5.69, I have protanomaly (TIL!)

So I took another look today. Given that the syntax colors are hard to change, looking only at the 4 bg colors I realized that the main change that would help is if td.new-full just used td.new's background color instead (#eaffea). I think it's because:

I see your point.

please no I am so young and have so much to live for

Please read and follow Contributing Feature Requests and Describing Root Problems. Unfortunately, we don't accept feature requests into the upstream without understanding the core reasons you need a feature and what problem you are having using Phabricator. A better way to think about this is, assume we won't build what you ask for, what is the real problem you are expecting this feature to solve.

hiding policy controls when creating panels in context of the Arrange Panels page seems like a good way to minimize this

I'm hoping to make panel creation dramatically simpler, so building a new dashboard from scratch is maybe a 1-2 minute task. Getting rid of copy and maybe also hiding policy controls when creating panels in context of the Arrange Panels page seems like a good way to minimize this.

No idea if realistic, but what if this "feature" is only enabled on installs of less than 6 months (or with the right db schema or something)?

Those seem to have been the magic words:

Panels can currently appear on multiple dashboards, so we can't use the dashboard's policy for them directly. If we could, you could always see any panel by creating a new dashboard you have permission to see, adding every panel to it, and looking at the panel you wanted.

Unless you can define a different default dashboard for logged in and logged out users, yeah.
The problem I see:

• I run a phabricator instance where the main part is only accesible for logged in users, but logged out users can still see some tasks.
• My problem: I want to inform my users about different upcoming events etc, for example per text panel
• The logged out users should not be able to see these messages, so I restricted some panels
• The whole problem would be easy to solve, if admins can define: logged in users get dashboard a), logged out users get dashboard b) in my situation

This is an essential feature for organizations running many, similarly structured projects. For us, each project is essentially a workflow of a predefined series of tasks that need to be tracked, assigned, and discussed individually for each project. Of course, each project will grow its own, custom additional tasks, too.

+1 to hide cover as an option on the board

Do we have a good reason for having separate polices for panels?

A possible workflow change might be to use "Edit Parent Tasks" instead of "Merge", to collect separate bugs under a single parent task but not actually close them.

The LocationsResource file is completely copy/pasted and wrong (still refers to "Instances").

I think the complexity of those rules exceeds their utility.

What are your thoughts on allowing valid HTML entities through to the
browser without further escaping (outside of code blocks)? There seems to
be no reason to have them in text, and they could allow escaping.

Base scenario should create the appropriate edge tables.

And phabricator.developer-mode and phabricator.developer-mode and phabricator.developer-mode and also phabricator.show-prototypes.

We should suggest configuring phabricator.developer-mode and phabricator.developer-mode (for UIExamples, to see icons).

I like. ♥. Thank you a lot!

💃

Yep, if you can update other people's diffs then this is fine. I'll just upgrade if needed. Thanks.

This is what I just did as a test:

I suppose that I'm being lazy, but the exact same argument exists for arc close-revision or arc upload.

@chad my understanding was that only the current owner of a revision can make changes. I guess I didn't read that thread through to completion, though I'm not sure that patch has made it to our install yet.

Can't they just arc patch Dxxxx and arc diff their changes back up?

I'm not trying to be facetious, but I'm not sure that there are two other ways. The scenario is that somebody is out and I'd like to continuing working on their feature whilst they're away. I've read through T10584 which mostly discusses why commandeer should be used in this case rather than updating somebody else's diff. In this case, if they say to me, "hey, can you take D123 whilst I'm out?", I'd prefer to just type arc commandeer D123 than have to go to the UI, find the diff and commandeer it. I suppose that I'm being lazy, but the exact same argument exists for arc close-revision or arc upload.

The db001 issue is still an issue, but the shard has managed to stay just under 80% for the last couple of weeks so we're not in any immediate peril. As followups, I think T12217 and T12218 better capture the broader issues here.

We haven't received any more information about this in a little more than two weeks, and don't know how to reproduce it so we can't move forward. Feel free to file a new task if you're able to come up with reproduction steps which work in a clean environment.

I think there are some more things worth doing here, but user profiles should be significantly more clear after recent changes. Here's @demo on this install now:

Oh we already had one of these

Presuming this is resolved since it's extremely boring and I ran it here and on every instance in the production cluster last week without any issues, but yell if you run into problems.

Presuming this is resolved since we haven't seen any evidence otherwise, but feel free to file followups if you run into issues or limitations.

We haven't received information that lets us reproduce this in about a week.

I scratched at the surface of T2794, but @chad also bought me a larger monitor so I can put more SSH terminals on it which should buy us another few weeks.

• Why do you track "percent complete"? What do you use it for?
• Is it actually accurate? Developers are notoriously bad at estimating project timelines, so I would naively guess that a "Percent" field would have almost no relationship to reality.

D17333 is a probable fix without needing to resort to a bunch of weird setInterval() juggling. I've pushed that here, let me know if you're still seeing the issue? If you are, does your JS console have anything in it?

Other than implementing arc commandeer, can you suggest two different ways we could solve the problem you're running into?

I'm having some trouble reproducing this -- I tried Safari and Chrome here and in my sandbox. You aren't using anything weird, right?

At some point, it's starting to be a lot of noise in the project, so we dup all these reports against the task tracking the root cause.

From a technical standpoint, we did not record these relationships in a normalized way prior to D16196 (June 2016, about 7 months ago) -- they only existed in the transaction log, and we just wrote a "close", extra_data="as duplicate of X" transaction that can't be queried efficiently.

We could also implement "Mute Thread" in Phabricator, but I assume no one would be willing to click twice to mute a thread.

If we use SMTP envelope To, doesn't Alice potentially get multiple messages still (envelope "To: Alice", envelope "To: All-About-Alice@lists.company.com")? The list rewrites the envelope to go to all the list members, right? Or is there more magic there I don't know about?

One issue with one-mail-per-recipient is that gmail does not permit muting an email conversation if you are the only TO recipient.