These projects should always add the Search-Team project:

MediaWiki-Search
Wikimedia-Search
Elasticsearch
CirrusSearch
Wikidata-Query-Service

My hope is that all of these old projects will be emptied and archived, so there would be no need for them to be auto-added to Search Team.

MediaWiki-Search
Wikimedia-Search
Elasticsearch
CirrusSearch
Wikidata-Query-Service

Maps
Search-Data-Analytics
Search-Department-Freezer

I'm not sure if everything from Wikidata-Query-Service was transferred to Search-Team... OTOH, there are some old bugs there which probably shouldn't, but also some backlog items that should.

@Smalyshev Thanks. I'll be sure that all issues have new homes before archiving any projects.

In T95932#1283470, @ksmith wrote:

My hope is that all of these old projects will be emptied and archived, so there would be no need for them to be auto-added to Search Team.

Why would we want to archive those projects? They're about where the bugs are and which products they affect, not who's working on them.

In T95932#1285163, @Legoktm wrote:

In T95932#1283470, @ksmith wrote:

My hope is that all of these old projects will be emptied and archived, so there would be no need for them to be auto-added to Search Team.

Why would we want to archive those projects? They're about where the bugs are and which products they affect, not who's working on them.

Each team (vertical) needs to have one place to manage their work, rather than looking across several feature-oriented workboards. Having a feature-specific project that is never actually viewed by anyone (because all the tasks are auto-added to the real project) doesn't sound great either.

The new proposal on the table is to have the team board include hashtags for all the relevant features, so users can find what they need. So in this case, phab projects like "Maps" would be archived, and the Search-and-Discovery-Department project would include hashtags for Map, Maps, OpenStreetMap, etc. That way, when someone files a bug, and types in "map", the department project will be proposed as an autocomplete option.

I think this tension exists because phabricator is being used both as an issue-tracking system for the software, AND as a project-planning system for getting work done. This seems to be a case where separate systems might be cleaner. (But of course that would introduce a whole world of other problems.)

But, when that person types #'maps what will actually show up is "Search-and-Discovery-Department" on all tasks. No one will be able to figure out what the task is related to (Search? Discovery? Maps? WDQS? Logstash? Whatever-New-Project-Is-Started?). Tags are useful. Phabricator uses tags and it just so happens that some tags can be used as projects (with workboards and sprints and such).

Summary: Without breaking down tasks by software component you're making it impossible for anyone else to participate.

In T95932#1287921, @ksmith wrote:

Each team (vertical) needs to have one place to manage their work, rather than looking across several feature-oriented workboards. Having a feature-specific project that is never actually viewed by anyone (because all the tasks are auto-added to the real project) doesn't sound great either.

So have a Search-Team project that has a workboard that you prioritize and triage. Whenever someone adds "Maps" or "MediaWiki-Search" to a task, herald will automatically add Search-Team so it shows up in your backlog and can be triaged. And just ignore the workboards on the other projects. People will use the other projects as they want to.

Currently your solution makes it impossible for someone else to go "hey, I want to improve default core search, where are all the bugs for that?".

What lego is discussing is also how we did it for the Collaboration team. There are projects for Flow, Echo, Page-Triage, Thanks, etc. All of them automatically add the Collaboration team project through a herald rule. Our PM did all the organizing and prioritizing of tickets in the Collaboration team board. Tickets were added from there to sprints. I thought this worked quite well, and could work in the search vertical as well.

@greg People could actually tell what feature the task was associated with, because it would be in the "Maps" column (or whatever), or else would be in the maps sprint project. And users wouldn't have to type the # to get a match--typing "Map" would be enough. But I understand the more general point(s).

@EBernhardson @Legoktm
So if I understand the proposal, these "feature projects" (e.g. "Maps") would exist, and would contain tasks, but their only purpose would be to exist as feature-centric task containers. These feature projects either wouldn't have any workboard, or if they did have one, it would be completely non-organized. No management or manipulation of those tasks would take place within the context of that project. Tasks would just get added to it, and they might get removed (if they had been mis-categorized) or eventually they might get resolved (as fixed, or declined, or whatever).

Is that right?

Thanks to all of you for helping me work through this. There were reasons for my original proposal, but hopefully we can agree on a better plan.

In T95932#1289278, @ksmith wrote:

@greg People could actually tell what feature the task was associated with, because it would be in the "Maps" column (or whatever), or else would be in the maps sprint project. And users wouldn't have to type the # to get a match--typing "Map" would be enough. But I understand the more general point(s).

Except users can't find that column easily without knowing to look for it. It doesn't show up automatically in searches like tags/projects do.

Let's not take away functionality that users use. :) There's no downside in the work that PMs have to do (they still only groom one backlog, the #SADD one) but we keep useful information about *where* (code-wise) issues are located (because columns are more ephemeral than tags).

I still don't understand the point of removing/archiving those projects/what it will gain.

@Aklapper: I think I would actually like fancier rules than what are in this task description. Can you and I have a real-time discussion to make sure I understand what is possible and would make sense in this case?

I'm thinking:

1. Any time a task is added to any of these [...] projects, also add it to that project.
2. Any time a task is added to this column of this project, also add it to that project. (for 5 columns/projects)

I don't think it makes sense to automatically remove projects in either direction, but am open to that possibility as well.

T630: Enabling Herald seems to be coming finally (today!?!!). You can also play with Herald at https://phab-01.wmflabs.org/herald/

In T95932#1351044, @ksmith wrote:

@Aklapper: I think I would actually like fancier rules than what are in this task description. Can you and I have a real-time discussion

@ksmith: Feel free to ping me on IRC.

to make sure I understand what is possible

See https://phabricator.wikimedia.org/T630#1131896 for what's possible (linked from the Help).

and would make sense in this case?

I'm thinking:

1. Any time a task is added to any of these [...] projects, also add it to that project.

Done now via H33; see my comment above.

2. Any time a task is added to this column of this project, also add it to that project. (for 5 columns/projects)

Not sure I get you. A task being in column X of project Y requires the task to be associated with project Y already, so that sounds like 1. to me.
But maybe you mean T91716: Mechanism for associating workboard columns with tags (projects)?

In any case, Herald does not allow column-based rules currently.

I don't think it makes sense to automatically remove projects in either direction, but am open to that possibility as well.

Just for the records, removing projects via Herald rules is possible since a few weeks ago.

@Aklapper Thanks. I can't view the herald rule you created (yet), but the description sounds like what we needed.

Triggering on columns would be very helpful in this case, but I guess it will have to wait for the upstream trigger feature. In this case, if a task were added to the Maps column of the Discovery project, it should be added to the Maps project. Same for the other categories. I'll probably just do periodic manual batch edit sweeps to catch errors in that direction. Monthly sounds about right.