This was brought up by @tstarling to me but it makes sense I think. Phabricator is far too spammy for us to continue posting to wikibugs-l as a spamlist. We're also using Phabricator for many non-bug things that we didn't before, which is outside the scope of that list.
I'm wondering if wikibugs-l has outlived its purpose at this point.
If Phabricator is spammy now, then imagine what it will be after the Bugzilla migration. I'm adding this task to Bugzilla-Migration, not because it is a blocker but to encourage a quick decision.
This decision doesn't correspond to the Phabricator team, really. I personally have never used wikibugs-l, and I think now we have other ways to watch the activity relevant to each of us. However, let's not forget that our bot currently depends on wikibugs-l (iirc).
we could narrow it down to adding wikibugs-l when a certain set of projects are added or something, but yeah the volume will only increase
If wikibugs-l is too noisy either don't follow it or set up mail filters or watch certain projects in Phabricator itself only? Not entirely sure what's the point here...
Maybe spammy isn't the right word, as it's not volume we're worried about. It's that we're encouraging the filing of many tasks that aren't actually bugs or enhancement requests in the software (broadly speaking). Tasks like "team plan for Q2" fall way outside the scope of wikibugs-l.
I think chase's suggestion about adding a project is a good idea. Maybe it shouldn't go to wikibugs-l until a "code" related project is added?
Ok I think we should create a 'bug' tag (project)... the only problem I can see is that users unfamiliar with out conventions would most likely omit the 'bug' project when submitting bug reports. We could handle this in triage by simply adding the tag when it's forgotten but that's extra manual effort for our triage team.
Does it have to be a single project to decide whether or not it goes to the list?
Ideally, we could have something editable directly from project pages be a flag for whether that project's tasks should be spammed. Something like project color/icon/keyword in project's description, etc. Even could be whether the wikibugs-l user is a member of the project.
btw, does wikibugs-l currently get notifs for subscriber list changes? (which should be configurable as it was with bugzilla)
a good idea but I am hesitant to do this before bugzilla migration as I think it encourages something we don't want....maybe wikibugs-l shouldn't get anything from phab until then?
it could be a list, right now it's simply new tasks CC the list. We can pair that down how we want per herald.
If we can stop cc only changes from getting sent, I think that would cut down on a lot of the spam? (Example: https://www.mail-archive.com/wikibugs-l@lists.wikimedia.org/msg441879.html).
I'd rather not cut off phab from wikibugs-l if possible...
ok I changed the rules a little:
When all of these conditions are met:
Projects do not include security, operations, Human-Resources, Community-Engagement, WMF-Legal
Is newly created? is true
Take these actions the first time this rule matches:
Send an email to wikibugs-l
When any of these conditions are met:
Projects include any of Bug Report, Patch-For-Review
Title contains [bug]
Take these actions the first time this rule matches:
Add emails to CC: wikibugs-l
I see that a #Bug_Report tag exists. If we want to use it, we better add it to all Bugzilla tasks during the migration.
What if we made an extension that added the list for any project with the
bug symbol? Could have a generic one 'bug' but then then it allows better
taxonomy. Unless there is a better use for the bug symbol.
One problem with this approach is that most probably there will not be projects only for bugs. Within a projects you will have bugs, development of new features, and perhaps even other tasks taking time from developers, like writing documentation of running a tutorial in an event.
If we really want to see only bugs in wikibugs-l, then the only way is to allow reports and triages to mark bugs as such, with a tag or with a custom field.
If adding all the activity of projects likely to contain bugs (software components), then we need to have a list maintained manually. That list could be maintained in the extension itself. What about a special page (can extensions have this?) on projects could be added using type-ahead for comfort.
Ok, can we please start simple before deciding to turn actually useful things off?
Here's an easy one, have the mailing list (or is this possible to do on Phab's side?) reject all mail with the following header and value: X-Phabricator-Mail-Tags: <maniphest-cc>
That should stop emails that are *only* people CC'ing themselves.
Is that possible from mailman @chad?
I'm not sure either reject or discard at the mailman layer are appropriate.
Reject will send a message back to phab. Discard will (i think) send an auto discard notif to the list owners. (which they could filter… but they shouldn't have to)
[off-topic I guess]
If there was such a tag in here, then there isn't anymore (I don't know the story behind).
IMHO it is good that the tag is gone if we don't plan to bikeshed on types of tickets.
From the top of my head I could offer anomalies, bugs, defects, errors, faults, failures, flaws, glitches, gripes, incidents, problems; feature requests, enhancement requests; or criteria such as crashers, refactoring/code cleanups, specification changes, test case issues, performance issues, security issues, documentation updates. And that's only software development.
Personally I don't believe that such categorizations help anybody to find or filter anything because personal criteria differ (the classic: "is it a bug or a feature request?") hence I believe in personal notification filter rules based on individual needs / interest in projects.
@Qgil: the current phawikibugs doesn't need emails from wikibugs-l to report anything, so I'm not sure if it should be considered a blocking task here; as far as phawikibugs is concerned, wikibugs-l can be 'unspammed'.
I am asking @yuvipanda and @Legoktm (or their managers, or someone else they know at the WMF) to be officially responsible of fixing this task, and get some time allocated accordingly. Chase and Mukunda have their hands full with Bugzilla & RT migrations tasks.
This is kind of urgent. We want to start the migration on 21 Nov, and it would be odd that after all the actual blockers are IRC and wikibugs-l...
This is kind of urgent.
Qgil lowered the priority of this task
Hmmmm.
(or their managers, or someone else they know at the WMF) to be officially responsible of fixing this task, and get some time allocated accordingly.
Is there a budget for Phabricator migration? I assume WMF also has a contract with Phacility for Phabricator development?
We don't have any contract signed with Phacility. All the help we get from them comes from their role as upstream maintainers. Phacility only signs contracts to build features that fit with their current roadmap and priorities (we asked them, at the beginning of the migration project).
If we want to fix this task in a couple of weeks, the contract route will be just too slow. This is why we are betting on internal resourcing at the WMF. Monday is only starting in Europe. Let us some hours to discuss properly who could work on this. :)
In the meantime, we can agree on the solution to be implemented. If I understand the discussion correctly, we have two different problems here:
Are T624 and T647 really blockers here? They are also related to CC changes, but I'm not sure that fixing them would fix anything here.
Parsing the Subject for "[Changed CC]" could work in theory if notifications were really atomic but they are not (notification could still include a comment) - see https://secure.phabricator.com/T5253 merged into https://secure.phabricator.com/T5604
I don't think that adding #Bug-Report to tickets will scale (as somebody needs to add that tag). Personally I'd remove that project tag again and I really wonder where the discussion about its addition took place. It would have welcomed discussion which other categories might exist and if such categorization makes sense. For example we get rid off marking tasks as so-called "enhancements" too, IMHO for good reasons (hard to distinguish anyway).
A totally different approach that maybe could work is to create a wikibugs user and a Herald rule adding this user to the tasks created in the projects specified in this rule. Real users can fine tune their notifications with more precision. We could set "A task's subscribers change" condition to "Ignore" and problem solved?
It was Saturday morning :) and I basically wanted to say that we need someone out there to work on this task. I see that next time I just need to report that we are looking actively for help, keeping the priority as it was.
I'm going to try to figure out a workable solution for this one.
@Qgil's suggestion is probably an acceptable though hacky solution.
The solution I proposed is less simple than we thought. Creating that account in the name of a mailing list is not that simple. Projects relevant to wikibugs-l are created all the time, it is not easy to keep track to them and it would be tedious to update the rules.
A basic question related to this task is: who is using wikibugs-l and for what purpose? Can Phabricator provide what wikibugs-l users are looking for?
To my honest surprise, I have not seen anybody yet who has complained about wikibugs-l being silent for the last two weeks.
Hence I do not think we should investigate time into this task unless a few more people consider it a problem.
I also tried to find out the actual number of list subscribers but Mailman does not offer piece of info in its admin UI. Easiest way seems to be temporarily editing its public HTML by setting "<MM-Num-Members>", there are also some bash or php scripts for ml admins on the interwebs...
I also tried to find out the actual number of list subscribers but Mailman does not offer piece of info in its admin UI
How so, you just have to visit the subscriber list. Good, it has the default access rule: 84+(5)+29(+4) subscribers.
https://lists.wikimedia.org/mailman/roster/wikibugs-l
Urgh, I entirely missed that... Thank you!
Yes, https://lists.wikimedia.org/mailman/admin/wikibugs-l/members should show a small header with "XXXX members total, YY shown".
Recommending to not further investigate this at all for the time being.
If there have been complaints that wikibugs-l@ does not receive notifications anymore then please post links to such complaints as I am not aware of any.
Recommending to not further investigate this at all for the time being.
I'd rather email all the subscribers to ask that they add their expectations here. I'm not sure how to reach most of the consumers, who are probably using the mirrors: if we're lucky, emailing the mirror's addresses will get a message on the mirror sites themselves.
If there have been complaints that wikibugs-l@ does not receive notifications anymore then please post links to such complaints as I am not aware of any.
They might have assumed phabricator breaks things, or not be aware of how to communicate with us, or consume the archives on an irregular/unfrequent basis.
@Aklapper, could you maybe send a personal type email to the wikibugs-l folks asking if anyone has concerns or wants modified behavior from the existing? I think the lack of complaints or really recognition at all of a problem means we may be trying to solve something that is not an issue for any actual users.
If the personal appeal to the list has no response I vote we close this and wait for feedback from someone so we have a hard and fast problem to solve.
Closing this as there is no meaningful activity in awhile and no related complaints. In this case no news isn't necessarily good news, but until there is some actionable idea it is not a real open issue.
Sorry, I missed your previous comment.
+1 on closing this task.
Didn't send a personal email to wikibugs-l folks because I don't have access to the subscribers list, but if anyone cares here I won't stop anybody. :)
Fwiw i used to be subscribed a long time ago. It was a very good way to keep track of everything going on in our community, and helped me learn about how various things worked. However at some point the bugzilla traffic got to be too much and i unsubscribed years ago.