Hi,
maybe not the best place to talk about that but...
I'd like to categorize some phab tasks so that I can access them quickly in the future. At first I thought that tags would be a perfect fit by creating my own custom tags. But as far as I understood tags are projects and I'm not allowed to create them. I suppose that if this feature is protected behind permissions this is because phab admins do not want someone to pollute the system with random tags.
My usecase is:
Sometimes users report queries that are not performing very well. Usually by reading the query I can identify and classify the cause. This cause can be something like: - bad weighting of words in the title - text analysis issue - index/db discrepancies - ...
This list is quite vague...
While it's not worth fixing a particular issue that mentions a specific query it's sometimes helpful to retrieve such tickets (where sometimes I added a comment) while I'm working on this class of problems: - just to have more examples to test - maybe I was wrong with the initial classification and the problem is elsewhere
Retrieving such tickets is painful today, because I have to rely on search, not to blame phab developpers, search is hard we all know :)
Today I used the parent/child relationships e.g. https://phabricator.wikimedia.org/T128073 but I don't think it's the proper approach because when I classify tickets I don't necessarily have a parent task ready.
Thanks for your suggestions.
I wholeheartedly agree with David that cataloging examples of smallish problems is a good way to get a sense of where the biggest underlying problems are, and a great way of having more specific examples to investigate.
Tags do seem like the obvious way to address this. Tracking tasks seems to be deprecated in the mediawiki documentation https://www.mediawiki.org/wiki/Phabricator/Help#.22Tracking.22_tasks. And tags are recommended instead https://www.mediawiki.org/wiki/Phabricator/Project_management/Tracking_tasks, but I don't think that's enforced.
So I guess I'm in the same position as David: I think this is a good idea, the proper implementation seems to be blocked by permissions (and possibly rightly so), and the obvious hack is discouraged, so I don't know what to suggest.
In summary: +1
—Trey
Trey Jones Software Engineer, Discovery Wikimedia Foundation
On Thu, Jul 7, 2016 at 8:47 AM, David Causse dcausse@wikimedia.org wrote:
Hi,
maybe not the best place to talk about that but...
I'd like to categorize some phab tasks so that I can access them quickly in the future. At first I thought that tags would be a perfect fit by creating my own custom tags. But as far as I understood tags are projects and I'm not allowed to create them. I suppose that if this feature is protected behind permissions this is because phab admins do not want someone to pollute the system with random tags.
My usecase is:
Sometimes users report queries that are not performing very well. Usually by reading the query I can identify and classify the cause. This cause can be something like:
- bad weighting of words in the title
- text analysis issue
- index/db discrepancies
- ...
This list is quite vague...
While it's not worth fixing a particular issue that mentions a specific query it's sometimes helpful to retrieve such tickets (where sometimes I added a comment) while I'm working on this class of problems:
- just to have more examples to test
- maybe I was wrong with the initial classification and the problem is
elsewhere
Retrieving such tickets is painful today, because I have to rely on search, not to blame phab developpers, search is hard we all know :)
Today I used the parent/child relationships e.g. https://phabricator.wikimedia.org/T128073 but I don't think it's the proper approach because when I classify tickets I don't necessarily have a parent task ready.
Thanks for your suggestions.
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
In bugzilla's last years we've had a field "whiteboard", used for personal notes. You could just edit the task description to add your own keywords at the bottom. For broader classifications, there's nothing wrong about tracking tasks.
Nemo
For broader classifications, there's nothing wrong about tracking tasks.
I agree in theory, but I'm trying not to advocate against standard practice in the developer community. The first link I sent states "In Phabricator, it would be better to create a Project (tag) to categorize this type of work", and the entire sentence (!) is linked to the other page, which states:
Creating *new* tracking tasks (tasks that "automatically" get resolved when
all its dependency tasks are resolved) in Phabricator is discouraged. It is recommended to create a project https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects instead.
So it seems that someone somewhere doesn't like tracking tasks. Neither discussion page shed any light.
The whiteboard sounds very nice. I found this ticket https://phabricator.wikimedia.org/T64374 from about 2 years ago, and the idea of "personal tags" or something else similar to the Bugzilla whiteboard for Phabricator was discussed very, very briefly and the ticket declined and closed.
Trey Jones Software Engineer, Discovery Wikimedia Foundation
On Thu, Jul 7, 2016 at 10:51 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
In bugzilla's last years we've had a field "whiteboard", used for personal notes. You could just edit the task description to add your own keywords at the bottom. For broader classifications, there's nothing wrong about tracking tasks.
Nemo
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
Another option may be a 'Search-Quality' project or some such with associatedd board. We could create columns for each category and drop them where they belong. The problem here though might be that some things sanely fit into two categories, but a workboard can only have them in one place.
On Thu, Jul 7, 2016 at 8:11 AM, Trey Jones tjones@wikimedia.org wrote:
For broader classifications, there's nothing wrong about tracking tasks.
I agree in theory, but I'm trying not to advocate against standard practice in the developer community. The first link I sent states "In Phabricator, it would be better to create a Project (tag) to categorize this type of work", and the entire sentence (!) is linked to the other page, which states:
Creating *new* tracking tasks (tasks that "automatically" get resolved
when all its dependency tasks are resolved) in Phabricator is discouraged. It is recommended to create a project https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects instead.
So it seems that someone somewhere doesn't like tracking tasks. Neither discussion page shed any light.
The whiteboard sounds very nice. I found this ticket https://phabricator.wikimedia.org/T64374 from about 2 years ago, and the idea of "personal tags" or something else similar to the Bugzilla whiteboard for Phabricator was discussed very, very briefly and the ticket declined and closed.
Trey Jones Software Engineer, Discovery Wikimedia Foundation
On Thu, Jul 7, 2016 at 10:51 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
In bugzilla's last years we've had a field "whiteboard", used for personal notes. You could just edit the task description to add your own keywords at the bottom. For broader classifications, there's nothing wrong about tracking tasks.
Nemo
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
Thanks for raising this issue, David.
Tags are restricted because internally they are projects. Project (and thus tag) namespace is global, so if everyone were to create 3 tags, then if we laid them all end-to-end, they would stretch halfway to the moon[1].
My understanding about the history of tracking tasks is that they were parent tasks, like epics, but with no concept of being "done". Something like "Improve documentation" could have children come and go, but would persist potentially forever. A project (or tag) would be better.
I don't understand "Creating new tracking tasks (tasks that 'automatically' get resolved when all its dependency tasks are resolved) in Phabricator is discouraged", because that almost describes epics or other parent tasks. Those are a good thing, and should not be discouraged. Except for the "automatically get resolved" part, but if epics did automatically resolve, I don't think that would be a bad thing.
Using columns within a categorization project would be an option. And a less-cumbersome option now than it would have been earlier this year, because phabricator now allows you to change a task's column within a workboard by setting a dropdown. (You always used to have to drag-and-drop them).
You could just insert a known string, like [Bad weighting] in the titles of tasks related to that type of issue. Searching would work, as long as you chose strings without accidental collisions. And as long as you were very careful to never misspell one of your keywords.
Please continue the discussion!
[1] Ok, not really. But autocomplete for projects would become a lot more difficult.
Kevin Smith Agile Coach, Wikimedia Foundation
On Thu, Jul 7, 2016 at 8:24 AM, Erik Bernhardson <ebernhardson@wikimedia.org
wrote:
Another option may be a 'Search-Quality' project or some such with associatedd board. We could create columns for each category and drop them where they belong. The problem here though might be that some things sanely fit into two categories, but a workboard can only have them in one place.
On Thu, Jul 7, 2016 at 8:11 AM, Trey Jones tjones@wikimedia.org wrote:
For broader classifications, there's nothing wrong about tracking tasks.
I agree in theory, but I'm trying not to advocate against standard practice in the developer community. The first link I sent states "In Phabricator, it would be better to create a Project (tag) to categorize this type of work", and the entire sentence (!) is linked to the other page, which states:
Creating *new* tracking tasks (tasks that "automatically" get resolved
when all its dependency tasks are resolved) in Phabricator is discouraged. It is recommended to create a project https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects instead.
So it seems that someone somewhere doesn't like tracking tasks. Neither discussion page shed any light.
The whiteboard sounds very nice. I found this ticket https://phabricator.wikimedia.org/T64374 from about 2 years ago, and the idea of "personal tags" or something else similar to the Bugzilla whiteboard for Phabricator was discussed very, very briefly and the ticket declined and closed.
Trey Jones Software Engineer, Discovery Wikimedia Foundation
On Thu, Jul 7, 2016 at 10:51 AM, Federico Leva (Nemo) <nemowiki@gmail.com
wrote:
In bugzilla's last years we've had a field "whiteboard", used for personal notes. You could just edit the task description to add your own keywords at the bottom. For broader classifications, there's nothing wrong about tracking tasks.
Nemo
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
…if everyone were to create 3 tags, then if we laid them all end-to-end, they would stretch halfway to the moon[1].
…
[1] Ok, not really. But autocomplete for projects would become a lot more difficult.
Well, if you us a big enough font, you could reach the moon. 7,000,000,000 pt HelveticaNeue Extended, maybe.
For autocomplete, what about sticking with a department/team/issue format: e.g., Discovery-Search-BadWeight.. or they could all get a personal "_Tag" prefix: _Tag-dcausse-search-badweight. That's super unwieldy, but avoids autocomplete collisions for everything else.
However, it sounds like we could consider ignoring the "no tracking tasks" directive, at least within Discovery. (Now I am advocating going against the advice given since no one seems to be advocating for it.)
Trey Jones Software Engineer, Discovery Wikimedia Foundation
On Thu, Jul 7, 2016 at 3:57 PM, Kevin Smith ksmith@wikimedia.org wrote:
Thanks for raising this issue, David.
Tags are restricted because internally they are projects. Project (and thus tag) namespace is global, so if everyone were to create 3 tags, then if we laid them all end-to-end, they would stretch halfway to the moon[1].
My understanding about the history of tracking tasks is that they were parent tasks, like epics, but with no concept of being "done". Something like "Improve documentation" could have children come and go, but would persist potentially forever. A project (or tag) would be better.
I don't understand "Creating new tracking tasks (tasks that 'automatically' get resolved when all its dependency tasks are resolved) in Phabricator is discouraged", because that almost describes epics or other parent tasks. Those are a good thing, and should not be discouraged. Except for the "automatically get resolved" part, but if epics did automatically resolve, I don't think that would be a bad thing.
Using columns within a categorization project would be an option. And a less-cumbersome option now than it would have been earlier this year, because phabricator now allows you to change a task's column within a workboard by setting a dropdown. (You always used to have to drag-and-drop them).
You could just insert a known string, like [Bad weighting] in the titles of tasks related to that type of issue. Searching would work, as long as you chose strings without accidental collisions. And as long as you were very careful to never misspell one of your keywords.
Please continue the discussion!
[1] Ok, not really. But autocomplete for projects would become a lot more difficult.
Kevin Smith Agile Coach, Wikimedia Foundation
On Thu, Jul 7, 2016 at 8:24 AM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
Another option may be a 'Search-Quality' project or some such with associatedd board. We could create columns for each category and drop them where they belong. The problem here though might be that some things sanely fit into two categories, but a workboard can only have them in one place.
On Thu, Jul 7, 2016 at 8:11 AM, Trey Jones tjones@wikimedia.org wrote:
For broader classifications, there's nothing wrong about tracking tasks.
I agree in theory, but I'm trying not to advocate against standard practice in the developer community. The first link I sent states "In Phabricator, it would be better to create a Project (tag) to categorize this type of work", and the entire sentence (!) is linked to the other page, which states:
Creating *new* tracking tasks (tasks that "automatically" get resolved
when all its dependency tasks are resolved) in Phabricator is discouraged. It is recommended to create a project https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects instead.
So it seems that someone somewhere doesn't like tracking tasks. Neither discussion page shed any light.
The whiteboard sounds very nice. I found this ticket https://phabricator.wikimedia.org/T64374 from about 2 years ago, and the idea of "personal tags" or something else similar to the Bugzilla whiteboard for Phabricator was discussed very, very briefly and the ticket declined and closed.
Trey Jones Software Engineer, Discovery Wikimedia Foundation
On Thu, Jul 7, 2016 at 10:51 AM, Federico Leva (Nemo) < nemowiki@gmail.com> wrote:
In bugzilla's last years we've had a field "whiteboard", used for personal notes. You could just edit the task description to add your own keywords at the bottom. For broader classifications, there's nothing wrong about tracking tasks.
Nemo
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
On Thu, Jul 7, 2016 at 1:08 PM, Trey Jones tjones@wikimedia.org wrote:
For autocomplete, what about sticking with a department/team/issue format: e.g., Discovery-Search-BadWeight.. or they could all get a personal "_Tag" prefix: _Tag-dcausse-search-badweight. That's super unwieldy, but avoids autocomplete collisions for everything else.
Autocomplete is per-word, so that sample would come up for dc, sea, bad, etc. For example, typing "back" in the upper-right search bar brings up all the xxx-backlog projects.
However, it sounds like we could consider ignoring the "no tracking tasks" directive, at least within Discovery. (Now I am advocating going against the advice given since no one seems to be advocating for it.)
As long as you don't call it a tracking task, I doubt anyone would even notice in order to complain. If it seems like it would solve the issue, I would support that. The whole "no tracking tasks" rule seemed to be a reaction (or over-reaction?) to something going on in bugzilla, so until we see actual problems in phab, I'm in favor of reasonable experimentation.
Kevin
Now we're back to why David doesn't particularly like that:
Today I used the parent/child relationships e.g. https://phabricator.wikimedia.org/T128073 but I don't think it's the proper approach because when I classify tickets I don't necessarily have a parent task ready.
If the categories are ones you come back to again and again, the parent task would only have to be created once. And I could imagine a grandparent task of "Fix Search Stuff" which would make it easy to find the right parent task.
Trey Jones Software Engineer, Discovery Wikimedia Foundation
On Thu, Jul 7, 2016 at 4:52 PM, Kevin Smith ksmith@wikimedia.org wrote:
On Thu, Jul 7, 2016 at 1:08 PM, Trey Jones tjones@wikimedia.org wrote:
For autocomplete, what about sticking with a department/team/issue format: e.g., Discovery-Search-BadWeight.. or they could all get a personal "_Tag" prefix: _Tag-dcausse-search-badweight. That's super unwieldy, but avoids autocomplete collisions for everything else.
Autocomplete is per-word, so that sample would come up for dc, sea, bad, etc. For example, typing "back" in the upper-right search bar brings up all the xxx-backlog projects.
However, it sounds like we could consider ignoring the "no tracking tasks" directive, at least within Discovery. (Now I am advocating going against the advice given since no one seems to be advocating for it.)
As long as you don't call it a tracking task, I doubt anyone would even notice in order to complain. If it seems like it would solve the issue, I would support that. The whole "no tracking tasks" rule seemed to be a reaction (or over-reaction?) to something going on in bugzilla, so until we see actual problems in phab, I'm in favor of reasonable experimentation.
Kevin
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
FWIW the model of tracking task used in bugzilla often was a tag replacement. i.e. a never closed task for documentation (infamous bug #1) with new tickets associated all the time. Most of them were years old and unclose-able. It was essentially meaningless. That's the thing that is bad news.
I think the ideal is that a task has finite work and is eventually closed. Even if it carries over for months and gets 100 subtasks it is still finite.
No concern for what you want to do here just thought I'd add that
On Thu, Jul 7, 2016 at 3:52 PM, Kevin Smith ksmith@wikimedia.org wrote:
On Thu, Jul 7, 2016 at 1:08 PM, Trey Jones tjones@wikimedia.org wrote:
For autocomplete, what about sticking with a department/team/issue format: e.g., Discovery-Search-BadWeight.. or they could all get a personal "_Tag" prefix: _Tag-dcausse-search-badweight. That's super unwieldy, but avoids autocomplete collisions for everything else.
Autocomplete is per-word, so that sample would come up for dc, sea, bad, etc. For example, typing "back" in the upper-right search bar brings up all the xxx-backlog projects.
However, it sounds like we could consider ignoring the "no tracking tasks" directive, at least within Discovery. (Now I am advocating going against the advice given since no one seems to be advocating for it.)
As long as you don't call it a tracking task, I doubt anyone would even notice in order to complain. If it seems like it would solve the issue, I would support that. The whole "no tracking tasks" rule seemed to be a reaction (or over-reaction?) to something going on in bugzilla, so until we see actual problems in phab, I'm in favor of reasonable experimentation.
Kevin
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
Chase Pettet, 07/07/2016 23:07:
I think the ideal is that a task has finite work and is eventually closed.
Yes, this is the reason some dislike the tracking tasks; not a problem if you create reports for, say, 12 different classes of actionable search problems and add a handful blockers for each.
(A contributing factor was that Phabricator's support for dependencies between tasks is awful: hard to add, no flexibility in notifications, no charts, no searchability. Tracking tasks were very powerful in bugzilla, not so much in Phabricator.)
Nemo
Thanks for all the suggestions,
If I sum up (in no particular order):
- tracking tasks: pros: everyone can do it cons: requires a lot of manual steps to classify, possible confusions with existing hierarchy, hard to search - tags pros: seems to be perfect cons: requires special perms, could lead to tons of meaningless tags if it was open - keywords in description pros: flexible because non structured cons: no special tools in phab to manage them, easy to get lost - single tag with workboard and columns pros: good compromise cons: affected columns are not displayed everywhere, cannot assign to multiple columns, requires 2 steps to classify, cannot search a specific column
Tags remain the ideal solution imo.
I see that phabricator added a notion of subproject recently could it help in this case?
Thanks.
Le 08/07/2016 08:48, Federico Leva (Nemo) a écrit :
Chase Pettet, 07/07/2016 23:07:
I think the ideal is that a task has finite work and is eventually closed.
Yes, this is the reason some dislike the tracking tasks; not a problem if you create reports for, say, 12 different classes of actionable search problems and add a handful blockers for each.
(A contributing factor was that Phabricator's support for dependencies between tasks is awful: hard to add, no flexibility in notifications, no charts, no searchability. Tracking tasks were very powerful in bugzilla, not so much in Phabricator.)
Nemo
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
Another option for personal categorization: 'flags' - it's the phabricator equivalent of bookmarks. Flags are personal, not shared publicly.
A bit more info about flags is at https://phabricator.wikimedia.org/T102812
On Fri, Jul 8, 2016 at 8:14 AM, David Causse dcausse@wikimedia.org wrote:
Thanks for all the suggestions,
If I sum up (in no particular order):
- tracking tasks: pros: everyone can do it cons: requires a lot of manual steps to classify, possible confusions
with existing hierarchy, hard to search
- tags pros: seems to be perfect cons: requires special perms, could lead to tons of meaningless tags if
it was open
- keywords in description pros: flexible because non structured cons: no special tools in phab to manage them, easy to get lost
- single tag with workboard and columns pros: good compromise cons: affected columns are not displayed everywhere, cannot assign to
multiple columns, requires 2 steps to classify, cannot search a specific column
Tags remain the ideal solution imo.
I see that phabricator added a notion of subproject recently could it help in this case?
Thanks.
Le 08/07/2016 08:48, Federico Leva (Nemo) a écrit :
Chase Pettet, 07/07/2016 23:07:
I think the ideal is that a task has finite work and is eventually closed.
Yes, this is the reason some dislike the tracking tasks; not a problem if you create reports for, say, 12 different classes of actionable search problems and add a handful blockers for each.
(A contributing factor was that Phabricator's support for dependencies between tasks is awful: hard to add, no flexibility in notifications, no charts, no searchability. Tracking tasks were very powerful in bugzilla, not so much in Phabricator.)
Nemo
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
Wow! That's a great suggestion! Seems like an under-documented and under-appreciated feature, but other than being private rather than public, it is close to what you'd want from tags.
Thanks, Mukunda!
Trey Jones Software Engineer, Discovery Wikimedia Foundation
On Wed, Jul 13, 2016 at 9:15 AM, Mukunda Modell mmodell@wikimedia.org wrote:
Another option for personal categorization: 'flags' - it's the phabricator equivalent of bookmarks. Flags are personal, not shared publicly.
A bit more info about flags is at https://phabricator.wikimedia.org/T102812
On Fri, Jul 8, 2016 at 8:14 AM, David Causse dcausse@wikimedia.org wrote:
Thanks for all the suggestions,
If I sum up (in no particular order):
- tracking tasks: pros: everyone can do it cons: requires a lot of manual steps to classify, possible confusions
with existing hierarchy, hard to search
- tags pros: seems to be perfect cons: requires special perms, could lead to tons of meaningless tags if
it was open
- keywords in description pros: flexible because non structured cons: no special tools in phab to manage them, easy to get lost
- single tag with workboard and columns pros: good compromise cons: affected columns are not displayed everywhere, cannot assign to
multiple columns, requires 2 steps to classify, cannot search a specific column
Tags remain the ideal solution imo.
I see that phabricator added a notion of subproject recently could it help in this case?
Thanks.
Le 08/07/2016 08:48, Federico Leva (Nemo) a écrit :
Chase Pettet, 07/07/2016 23:07:
I think the ideal is that a task has finite work and is eventually closed.
Yes, this is the reason some dislike the tracking tasks; not a problem if you create reports for, say, 12 different classes of actionable search problems and add a handful blockers for each.
(A contributing factor was that Phabricator's support for dependencies between tasks is awful: hard to add, no flexibility in notifications, no charts, no searchability. Tracking tasks were very powerful in bugzilla, not so much in Phabricator.)
Nemo
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery
Hi!
Another option for personal categorization: 'flags' - it's the phabricator equivalent of bookmarks. Flags are personal, not shared publicly.
A bit more info about flags is at https://phabricator.wikimedia.org/T102812
Thanks, I didn't even know it existed!
I plan to look into this more, and perhaps make recommendations, in a couple weeks.
It is possible that sub-projects could help.
Kevin Smith Agile Coach, Wikimedia Foundation
On Wed, Jul 13, 2016 at 3:26 PM, Stas Malyshev smalyshev@wikimedia.org wrote:
Hi!
Another option for personal categorization: 'flags' - it's the phabricator equivalent of bookmarks. Flags are personal, not shared publicly.
A bit more info about flags is at
https://phabricator.wikimedia.org/T102812
Thanks, I didn't even know it existed!
-- Stas Malyshev smalyshev@wikimedia.org
discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery