This is very old, fairly vague, and doesn't have any clear modern customer interest. I'm open to implementing it, but would like a more clear/modern customer request before pursuing it.

See T13602 for modern followup, recent changes, and plans.

I think this was at least approximately resolved by D21115, which made the default log much quieter and the "debug" log more verbose.

See T13612 for followup.

See also PHI1987 for another case of this.

related to T3278, probably?

I think the general shape of this is:

I think that this is something we(Wikimedia) can patch downstream in our fork, I don't think there is anything further to add to this upstream discussion.

Bumping again simply because this has come up a few times this month. Teams I work with want to use a WIP feature, but don't use the current implementation because it tracks points instead of tasks. Reviewing the rest of the comments in this thread, all of it remains relevant to those use-cases.

I reordered these elements in D21200. See also D20967.

We've never seen other requests for this feature and currently have no customer requests for it, so I don't plan to implement it.

Just a question - are there any technical reasons why providing custom field for "projects" may not be a good idea?

Ah, thanks. Yeah, I think that's reasonable. I'm sure some other things can still be cleaned up -- like I changed the "Subscribers" UI a little bit recently, and it could now handle disabled users more clearly:

IMHO this could be closed as resolved these days.

I'd like to leave behind a "Results were GC'd on X/Y/Z" message when we GC these so it's clear what's going on.

I removed the strikethrough in T13482, which mostly moots this.

TravisCI sold to Idera and is no longer "cool".

Not necessarily applicable in the general case, but see also T13393.

I assume this is being done already in the Phacility cluster on some level when repositories get really large, but I'm not particularly sure how to perform this migration.

Owners review and auditing now have 6 and 4 options respectively, which I think cover most of the needs here. They don't handle everything (e.g. excluding merge commits) but think we're mostly in a reasonable place now and don't have any current plans to add additional shorthands.

Changes connected to T13277 likely moot this. If users are pushing temporary personal branches to a repository, configure "Permanent Refs" to exclude them. Commits pushed to these branches will no longer publish feed stories, trigger audits, etc.

D19549 added Spaces support to projects.

We could lock this order into "drag to column" interactions only once those are built (i.e., not support "drag to position" -- basically, when you drop a card, we fling it into the correct position, even if that position is at the bottom of the column far off the screen). This will be somewhat confusing but maybe the least-bad of the options.

After D20229, the rules are:

We have no customer interest in this and no current plans to pursue it.

However, at some point I expect that we'll be unable to continue meaningfully improving the heuristic in general, and need to start adding rules based on the file language (for example, look for function signatures in C, keywords like "function" and "class" in PHP, patterns like ".prototype" in Javascript, lots of opening braces in Lisp, etc).

I think this is reasonably well-covered between arc anoid and arc weld. Once T5055 comes online, third-parties can presumably fill in more titles for the arc game library.

These have existed for a while and recently got support for customizing sub-object behaviors in 2018 Week 50 (Mid December) and are being extended to Projects in 2019 Week 5, so it looks like they're here to stay.

D19968 got us closer here, but the link targets aren't actually rendering properly.

I'm not confident there's really a path forward here even for the subset of mailers where we have full control of the SMTP envelope and can generate Message-IDs, which is only a small subset of mailers today. Even if it does work, it makes the "Reply All" problem worse.

...it is virtually inconceivable to me that this is something we would ever bring upstream in any form.

@amckinley, for general context on where I'm headed here:

This doesn't seem to be cropping up terribly often and I think this use case is fairly weak.

This might happen eventually, or as a side effect of T7303, but the use case here is pretty narrow and there's currently no customer interest so I don't currently anticipate building it.

Password management is in good shape after T13043 , and this would now be fairly easy to implement in a general way by adding a check in PhabricatorAuthPasswordEngine->isUniquePassword().

In T12588#242719, @epriestley wrote:

If any of these lists only have one form (or the user can only see one form), we'll take the user directly to the specified form.

When users click "Create Subtask", we now look for a list of possible subtask forms.

@epriestley we are using the "menu item" solution that you described above, and the primary remaining pain point is that when you click on a link, the menu highlights "workboard", which confuses some users, because they expect the link (i.e. the menu item they just clicked on) to be highlighted.