We queried a subset of free instances to gain insight about free instance usage patterns (mostly: are they actually being used?). Specifically, I ran these queries to count repositories and feed stories on a subset of free instances:

Yeah, that seems like a valid solution, however the spoiler in question is still visible, and could get glimpsed at before reading the warning. It'll have to do for now.

Putting something like a header maybe could help in the meantime?

To answer @avivey's question more directly, it takes a long time for the yellow Loading... bars to expand to the diff for files I'm interested in because the server is spending all it's CPU time generating diffs of generated files that appear first on the page.

It's true that they're loaded in parallel using AJAX but there are enough generated files that it's tying up the server's CPU. And the generated files seem to end up first in the queue.

We don't consider the fact that feature is missing, and would be used, a root problem. Something along the lines of understanding how your company was operationally impacted by seeing/hiding a spoiler would be helpful.

Strange, I read the Contributing Feature Requests documentation prior to submission, and I figured I'd described the root problem as having revealed content that is context-sensitive with my example of a TV series spoiler. There are potentially more uses outside of TV series spoilers, and I don't think it's any less valid than something like Macros.

See Contributing Feature Requests for what information is required in a valid feature request. Specifically this request lacks a root problem and doesn't seem to be about coding / product development. We also can't enforce people knowing when to use such tags, so even having them doesn't really solve the problem of tv show spoilers.

Actually I guess this (storage format in commit history) is largely unrelated to that (display format in web UI).

T11114 should fix this for free.

There are no such plans.

A lot of arc help is version dependent, contextual, configuration-dependent, or extension-dependent, and this trend will only accelerate in the future. arc help is accurate; Googling for stuff will often get you help for a different version/configuration. Usage documentation is already available online.

This report is very old and doesn't have reproduction instructions. If you're still experiencing issues, please file a new report by following the instructions in Contributing Bug Reports, including reproduction instructions (see Providing Reproduction Steps).

If you're using a closed-source IDE, you can change the IDE's behavior by working with the IDE's vendor.

Thanks. I find the "Global Default Settings" now.

in which folder we need to place maniphest.custom-field-definitions

Everything you describe is working as intended, so this is not a bug in Phabricator.

HI @avivey! Thanks for your answer! My mistake, Subprojects support members.
Do you know if there is any plan in the future to support members in Milestones?

Thanks @chad for your answer! Unfortunately, there isn't a Pre-Build Dark Theme so far implemented in Phabricator ...

It would be cool if in Phabricator will be implemented a Pre-Build Dark theme.

FWIW: I believe @paladox means well, he's just young/inexperienced and overly enthusiastic. The decision to ban him is entirely reasonable for upstream though, given the circumstances.

In T11034#199653, @epriestley wrote:

---

Now that this has been deployed for a while, I'm curious if there's any feedback about it? Specifically:

• Does this approach generally seem like it's a reasonable solution to the problem (if not in its current form, in some similar form which handles these issues more gracefully)? Or are we not really in the right ballpark?

Good to know :) thanks again @chad

It's like asking to drive a car that has no wheel or engine. It's just a frame that does absolutely nothing,

Oh I see, but is it some how working ? Can you point what it currently does and what not ?