I guess it depends how we want to use the Projects field. In Ops we're talking about using sub-project tags to carve up the pool of Ops tasks, which could be defined as any ticket that has "Operations" in the projects list. Once a ticket has been triaged to a sub-project, its easier for people to find what to work on.

I guess it depends how we want to use the Projects field.

So how do you (plural, also includes Fundraising which probably should know) want to use it? :)

Decision welcome so we can move forward here.

So how do you (plural, also includes Fundraising which probably should know) want to use it? :)

I meant the overall org and the big picture of how we use phabricator (and I may be missing something obvious).

Projects could be treated as a list of all relevant or interested projects, teams, whatever. Just keep throwing tags on there. In that case it's reasonable for both 'operations' and 'fundraising' to be on the list, and I'd have to rely on a search for the combination of operations+fundraising plus I'd have to read a lot more for each task before deciding whether it's something I should take.

Or Projects could be treated as an indicator of where the task is assigned. In that case putting lots of different projects on the list seems confusing to me, maybe you'd want just one there and we'd make more intentional use of the Cc list. In this case having both 'fundraising' and 'operations' on the list is confusing. How would you tell, without reading the whole task, whether its something you should pick up as an Ops person?

I guess my personal preference would be to have a set of post-triage 'queue-assignment' tags, and whether or not there are multiple tags on the list there would only be one 'queue-assignment' tag. We would look for those specific tags when taking tasks from the post-triage-but-not-yet-assigned pool. In this case, initial triage would add "ops-fundraising" to the list based on a read of the ticket, and I would watch for tasks with that tag.