It's a problem. I am mentoring a colleague who is stressed with the prospect of keeping up with our community because of the volume of email, and so it's a serious barrier to community involvement. I too have email filters to help me, and it took some time to work out a system. We could share our filter descriptions for this with workflow? I'm sure I could learn from you all on your approaches, and new collaborators would appreciate this advise.
I think automated builds (Jenkins/CI) could warrant its own list. Separate lists would make setting up email filters easier in general. I like the idea of a list, like dev, but which does not include JIRA comments or GH code review comments, and does not include Jenkins/CI This would be a good way for potential contributors to have a light-weight way of getting involved. If they are involved or interested in specific issues, they can "watch" / "subscribe" to JIRA/GH issues and consequently they will get direct notifications from those systems. Then people who choose to get more involved, like us, can subscribe to the other list(s). We do have instances where "ASF subversion and git services" can be excessive due to feature branches that ought not to generate JIRA posts to unrelated issues, and I think we should work to prevent that. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Aug 7, 2019 at 7:01 AM Tomoko Uchida <[email protected]> wrote: > Hi > > +1 for separated list(s) for JIRA/Github updates and Jenkins jobs. > While I myself am not in trouble with assorting the mails thanks to > gmail filters, I know an user (external dev) who unsubscribed this > list. The one reason is the volume of the mail flow :) > > Tomoko > > 2019年8月7日(水) 8:17 Jan Høydahl <[email protected]>: > > > > 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] > >
