+1 - Just two days ago I created a filter to send [JENKINS] emails elsewhere... I don't want to completely unsubscribe from Lucene development emails, but the traffic here is a bit overwhelming and it's hard to see the signal in the noise sometimes (high recall, low precision you might say!)
On Wed, Aug 7, 2019 at 5:27 PM Noble Paul <[email protected]> wrote: > +1 > > The mail list is sending so many mails that it has become difficult to > catch up > > On Thu, Aug 8, 2019 at 12:26 AM Michael Sokolov <[email protected]> > wrote: > > > > big +1 -- I'm also curious why the subject lines of many automated > > emails (from Jira?) start with [CREATED] even though they are > > generated by comments or other kinds of updates (not creating a new > > issue). Overall, I think we have way too much comment spam. In > > particular Github comments are so poorly formatted in email (at least > > in gmail?) as to be almost unreadable - I think because they always > > include the complete comment history. I wonder if there is a way to > > neaten them up (especially the subject lines, so you can scan > > quickly)? > > > > On Tue, Aug 6, 2019 at 7:17 PM Jan Høydahl <[email protected]> > wrote: > > > > > > Hi > > > > > > The mail volume on dev@ is fairly high, betwen 2500-3500/month. > > > To break down the numbers last month, see > https://lists.apache.org/[email protected]:lte=1M: > > > > > > Top 10 participants: > > > -GitBox: 420 emails > > > -ASF subversion and git services (JIRA): 351 emails > > > -Apache Jenkins Server: 261 emails > > > -Policeman Jenkins Server: 234 emails > > > -Munendra S N (JIRA): 134 emails > > > -Joel Bernstein (JIRA): 84 emails > > > -Tomoko Uchida (JIRA): 77 emails > > > -Jan Høydahl (JIRA): 52 emails > > > -Andrzej Bialecki (JIRA): 47 emails > > > -Adrien Grand (JIRA): 46 emails > > > > > > I have especially noticed how every single GitHub PR review comment > triggers its own email instead of one email per review session. > > > Also, every commit/push triggers an email since a bot adds a comment > to JIRA for it. > > > > > > Personally I think the ratio of notifications vs human emails is a bit > too high. I fear external devs who just want to follow the project may get > overwhelmed and unsubscribe. > > > One suggestion is therefore to add a new list where detailed JIRA > comments and Github comments / reviews go. All committers should of course > subscribe! > > > I saw the Zookeeper project have a notifications@ list for GitHub > comments and issues@ for JIRA comments (Except the first [Created] email > for a JIRA will also go to dev@) > > > The Maven project follows the same scheme and they also send Jenkins > mails to the notifications@ list. The Cassandra project seems to divert > all jira comments to the commits@ list. > > > The HBase project has keeps only [Created]/[Resolved] mails on dev@ > and all other from Jira/GH on issues@ list and Jenkins mails on a > separate builds@ list. > > > > > > Is it time we did something similar? I propose a single new > notifications@ list for everything JIRA, GitHub and Jenkins but keep > [Created|Resolved] mails on dev@ > > > > > > -- > > > Jan Høydahl, search solution architect > > > Cominvent AS - www.cominvent.com > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- *Doug Turnbull **| CTO* | OpenSource Connections <http://opensourceconnections.com>, LLC | 240.476.9983 Author: Relevant Search <http://manning.com/turnbull> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
