Some general notes:

• This would be inconsistent with other actions ("Add Reviewers", "Add CCs", "Add Auditors").
• This opens up a much wider window for race conditions, where another user edits the task between the time you load the page and the time you submit the form.
• An alternate approach is to add a comment field to "Edit Task".
• T5475 and similar may provide more clarity here.

• I don't see how this is inconsistent with existing actions: the menu does not contain only "Add" actions today: Change Status, Change Priority... so you can have "Change Projects"
• How is this different from race conditions if 2 people edit the task at the same time (using the main form)?
• A comment field to Edit Task might be a good thing in itself, but that's separate from this issue which is to make a common UI action (removing / replacing project) as efficient as adding projects

It's inconsistent in the sense that all fields which have tokenizers do "Add". They do this partially to limit the effect of race conditions, which are more damaging for these kinds of fields than for fields which have only one possible value.

It's different from an edit because the window is much larger. A user normally opens the edit screen to make a specific edit and spends only a few moments making that edit. With tasks, they are more likely to load the task, read through it, think about what change to make, and then make the change. This might take several minutes rather than a few moments. There's no fundamental difference, but the narrower window makes "Edit" more resistant to races than "View".

The concern about race conditions largely predates universal transaction logs. They are less damaging now than they used to be; long ago, it was easy for them to go completely unnoticed because there was no record of users making field-level edits to objects. It's reasonable to reconsider this policy now, but the rationale for only having "Add" on these fields is at least partially that it limits race condition damage and race conditions used to be quite difficult for humans to catch. The first version of this kind of field was in Differential (IIRC, Add Reviewers), and users legitimately hit races in the wild.

(This request is a reasonable one and these UIs are worth taking another look at, it's just not a cut-and-dry straightforward improvement with no downsides or tradeoffs.)

Got it, thanks for the feedback!

This is now fairly easy to implement and the race stuff isn't a problem anymore, but I'm not sure it's worthwhile from a product perspective. We could pursue these things fairly easily now:

• Add a "Remove Projects" action.
• Add a "Set Projects" action, allowing you to add or remove projects in a single action.
• Add both "Remove Projects" and "Set Projects" actions.

Personally, I don't think I'd ever use these actions and I'm hesitant to put a lot of stuff -- and, particularly, a lot of similar actions -- in the new "Add Action..." menu.

@chad, do you have feelings here?

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.

This might be idiosyncratic to our use, but each team will have some sort of backlog project, and 1-n kanban/sprint boards. This is because everything "doesn't fit" on one board both in the sense that it would be goofy wide (backlog columns tend to be abstract buckets while kanban boards are your typical pipeline) and it is unwieldy to have "a lot" of tasks in a column. (There are nice things about this split to like being able to search on "is in the backlog") Adding and removing projects are thus both common actions, but are done in different place in the UI. I suspect moving tasks between projects (and not just adding) will be more common with sprint/sub-projects (T3670).

Alright, I'll just replace "Add Projects" with "Change Projects".

I suspect moving tasks between projects (and not just adding) will be more common with sprint/sub-projects (T3670).

I'm currently thinking this will mostly happen from the board view, but maybe not.