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.