Page MenuHomePhabricator

Phabricator far too spammy and off-topic to continue posting to wikibugs-l
Closed, ResolvedPublic

Description

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.

Event Timeline

demon created this task.Oct 21 2014, 2:40 PM
demon updated the task description. (Show Details)
demon raised the priority of this task from to Needs Triage.
demon added a project: Phabricator.
demon changed Security from none to None.
demon added a subscriber: demon.
Qgil triaged this task as Normal priority.Oct 21 2014, 2:49 PM
Qgil edited projects, added Bugzilla-Migration; removed Phabricator.
Qgil added a subscriber: Qgil.

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

demon added a comment.Oct 21 2014, 4:43 PM

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?

In T763#14142, @jeremyb wrote:

Does it have to be a single project to decide whether or not it goes to the list?

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.

In T763#14145, @chasemp wrote:

maybe wikibugs-l shouldn't get anything from phab until then?

That.

proposing removal of the auto cc of wikibugs-l until bugzilla migration is done then

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:

Instead of adding the CC, new tasks simply send a single email to the list, this will cut down on spam significantly.

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


Then another herald rule sets the cc for wikibugs-l under a more narrow set of conditions:

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.

Qgil added a comment.Oct 26 2014, 6:44 AM

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.

revi added a subscriber: revi.Oct 26 2014, 6:50 AM

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]

In T763#15165, @Qgil wrote:

I see that a #Bug_Report tag exists.

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 added a comment.Oct 26 2014, 6:51 PM
In T763#15165, @Qgil wrote:

I see that a #Bug_Report tag exists.

Bug-Report

It was created with a space, and I applied the guidelines. :)

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)

Discard will silently discard, and should therefore be usable in this situation.

Discard will silently discard, and should therefore be usable in this situation.

citation needed. (or test it)

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

Qgil added a subscriber: santhosh.Oct 30 2014, 2:21 PM
Qgil lowered the priority of this task from Normal to Lowest.Nov 1 2014, 7:39 AM
Qgil added a subscriber: yuvipanda.

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

Nemo_bis renamed this task from Phabricator far too spammy to continue posting to wikibugs-l to Phabricator far too spammy and off-topic to continue posting to wikibugs-l.Nov 2 2014, 9:36 AM
Nemo_bis updated the task description. (Show Details)
Nemo_bis added a subscriber: Nemo_bis.

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?

Qgil added a comment.Nov 3 2014, 7:18 AM

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:

  1. Defining the scope of projects for wikibugs-l. In T763#14208 @mmodell recommend the formula "All except A, B, C". I think it is better to whitelist instead of blacklisting. We could start with the list of projects migrated from Bugzilla, and fine tune from there, reviewing projects currently listed here and new projects as they are created. We can define the Herald rule adding wikibugs-l already now.
  2. Avoiding that CC changes generate emails for wikibugs-l. There are two possible points for controlling this: fine tuning the Herald rule to make an exception on CC changes (but that doesn't seem to be possible today), or filtering emails with the CC changes related header before they are distributed to wikibugs-l (no idea how feasible this is).

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.

In T763#17921, @Qgil wrote:

or filtering emails with the CC changes related header before they are distributed to wikibugs-l (no idea how feasible this is).

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

In T763#15611, @Qgil wrote:

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

Qgil added a comment.Nov 3 2014, 8:54 AM

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?

Qgil raised the priority of this task from Lowest to Normal.Nov 3 2014, 7:18 PM

Qgil lowered the priority of this task

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.

mmodell claimed this task.Nov 3 2014, 8:16 PM

I'm going to try to figure out a workable solution for this one.

@Qgil's suggestion is probably an acceptable though hacky solution.

Qgil removed mmodell as the assignee of this task.Nov 23 2014, 10:45 PM
Qgil edited projects, added Phabricator; removed Bugzilla-Migration.
Qgil moved this task from To Triage to Need discussion on the Phabricator board.
scfc added a subscriber: scfc.Nov 24 2014, 4:45 AM
jayvdb added a subscriber: jayvdb.Dec 5 2014, 1:32 AM
Qgil lowered the priority of this task from Normal to Low.Dec 8 2014, 8:49 AM

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?

In T763#824400, @Qgil wrote:

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

demon removed a subscriber: demon.Dec 8 2014, 3:05 PM
Nemo_bis added a comment.EditedDec 8 2014, 4:30 PM

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.

chasemp closed this task as Resolved.Dec 30 2014, 7:37 PM
chasemp claimed this task.

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.