Page MenuHomePhabricator

Automatically add tasks to "Discovery" project via Herald
Closed, ResolvedPublic

Description

UPDATE: Please do create a herald rule so that any task added to any of the following feature projects also gets added to Discovery (which used to be called Search-Team):

It'd be really really useful if all tasks in the Wikidata-Query-Service project and the CirrusSearch project were always in the Search-Team project. Because we use the search team project to orgranize things its possible that stuff in the other two can fall through the cracks.

Event Timeline

Manybubbles raised the priority of this task from to Medium.
Manybubbles updated the task description. (Show Details)
Manybubbles added a subscriber: Manybubbles.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 13 2015, 6:58 PM

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

Smalyshev added a subscriber: Smalyshev.EditedMay 13 2015, 10:39 PM

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.

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.

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.)

greg added a subscriber: greg.May 15 2015, 3:37 PM

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.

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.

greg added a comment.May 15 2015, 10:23 PM

@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.

ksmith renamed this task from Automatically add tasks to search team project to Automatically add tasks to Search and Discovery project.May 19 2015, 9:47 PM
ksmith updated the task description. (Show Details)
ksmith set Security to None.

@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.

Restricted Application added a project: Wikidata. · View Herald TranscriptJun 9 2015, 10:35 PM
Lydia_Pintscher moved this task from incoming to monitoring on the Wikidata board.Jun 10 2015, 6:34 AM
Qgil added a subscriber: Qgil.Jun 10 2015, 7:20 AM

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

Aklapper closed this task as Resolved.Jun 10 2015, 1:57 PM
Aklapper claimed this task.

I am sorry, this somehow fell through the cracks. :(

I have created Herald rule H33:

  • When all of these conditions are met:
    • Projects include any of: CirrusSearch, Wikidata-Query-Service, Elasticsearch, MediaWiki-Search, Maps
  • Take these actions the first time this rule matches:
    • Add projects: Discovery

The Discovery project is not associated retroactively, only for future actions.
If wanted, the existing 1353 tasks in any of those projects could be added by batch-editing.

Aklapper renamed this task from Automatically add tasks to Search and Discovery project to Automatically add tasks to "Discovery" project via Herald.Jun 10 2015, 1:57 PM

@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.

  1. 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.

Restricted Application added subscribers: Luke081515, scfc. · View Herald TranscriptDec 31 2015, 5:09 AM
Danny_B moved this task from To Triage to Herald rules on the Phabricator board.Jul 12 2016, 2:05 PM
Restricted Application added a project: Discovery-Search. · View Herald TranscriptJul 12 2016, 2:05 PM
Restricted Application added a subscriber: TerraCodes. · View Herald Transcript