Separate dev mailing list for automated mails?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Separate dev mailing list for automated mails?

Jan Høydahl / Cominvent
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/trends.html?dev@...: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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Tomoko Uchida
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 <[hidden email]>:

>
> 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/trends.html?dev@...: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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

david.w.smiley@gmail.com
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


On Wed, Aug 7, 2019 at 7:01 AM Tomoko Uchida <[hidden email]> 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 <[hidden email]>:
>
> 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/trends.html?dev@...: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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Michael Sokolov-4
In reply to this post by Jan Høydahl / Cominvent
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 <[hidden email]> 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/trends.html?dev@...: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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Noble Paul നോബിള്‍  नोब्ळ्
+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 <[hidden email]> 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 <[hidden email]> 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/trends.html?dev@...: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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Doug Turnbull
+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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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/trends.html?dev@...: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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Doug Turnbull | CTO | OpenSource Connections, LLC | 240.476.9983 
Author: Relevant Search
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.
Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Shawn Heisey-2
In reply to this post by Jan Høydahl / Cominvent
On 8/6/2019 5:17 PM, Jan Høydahl wrote:
> 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@

If it weren't for server-side filtering on my mail server
(sieve/dovecot), I'd probably have brought this up a LONG time ago. :)
The filtering separates all those things out into their own folders so
my "lucene-dev" folder shows only human-generated traffic for the most part.

I'm also subscribed to commits, and that goes to its own folder too.

+1 to this idea.  Having separate lists would mean my filters will be
more reliable, and people who have an interest in dev discussions
without tons of computer-generated junk can join us.

Here's my bikeshed paint:

issues@ for detailed Jira/GH activity.
builds@ for things like Jenkins.
I'm ambivalent about whether dev should get the created/resolved
activity from Jira/GH.  I can see arguments both ways.

Thanks,
Shawn

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Jan Høydahl / Cominvent
I don't have strong feelings for whether we have one list of two, i.e. issues@ and builds@ - I'll subscribe to them anyways. A benefit of the latter is that the list names are intuituve and self describing.
I guess the strongest argument against would be that many will not subscribe and miss out on important events. But what I think will happen is that a majority of committers will follow the new lists and should there be events that require disussion, bring those to dev@. 

In fact I'd argue that the new list(s) be announce only, not accepting email from others than the bots. This would force discussions over to dev@ to the benefit of all.

Wrt a commit breaking the build, I would assume that Jenkins is able to email all committers that did a commit in a broken build?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

8. aug. 2019 kl. 00:17 skrev Shawn Heisey <[hidden email]>:

On 8/6/2019 5:17 PM, Jan Høydahl wrote:
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@

If it weren't for server-side filtering on my mail server (sieve/dovecot), I'd probably have brought this up a LONG time ago. :) The filtering separates all those things out into their own folders so my "lucene-dev" folder shows only human-generated traffic for the most part.

I'm also subscribed to commits, and that goes to its own folder too.

+1 to this idea.  Having separate lists would mean my filters will be more reliable, and people who have an interest in dev discussions without tons of computer-generated junk can join us.

Here's my bikeshed paint:

issues@ for detailed Jira/GH activity.
builds@ for things like Jenkins.
I'm ambivalent about whether dev should get the created/resolved activity from Jira/GH.  I can see arguments both ways.

Thanks,
Shawn

---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Alexandre Rafalovitch
In reply to this post by david.w.smiley@gmail.com
I apply the following (gmail) rules, just in case it helps somebody.
With this combination, I am able to track human conversations
reasonably well.

Human conversation:
Matches: from:(-[hidden email]) subject:(-[jira]) list:<dev.lucene.apache.org>
Do this: Skip Inbox, Apply label "ML/Lucene-dev"

All JIRA issues, regardless of other filters
Matches: subject:([jira] {SOLR- LUCENE-}) list:"dev.lucene.apache.org"
Do this: Skip Inbox, Apply label "ML/Lucene-jira", Never send it to Spam

New JIRA issues (that I check to see if I want to track/comment before
I remove the label)
Matches: subject:("[Created]") list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Apply label "ML/Lucene-Jira-Interesting", Never
send it to Spam

Updates on JIRA issues from me (I already know them)
Matches: from:(Alexandre Rafalovitch (JIRA) <[hidden email]>)
Do this: Skip Inbox, Mark as read, Star it, Apply label "Solr-Jiras"

All JIRA issues I am involved in or marked to track
Matches: from:([hidden email]) to:([hidden email])
Do this: Skip Inbox, Apply label "Solr-Jiras"

Delete JENKINS stuff, as I am currently not contributing
Matches: subject:([JENKINS]) list:(<dev.lucene.apache.org>)
Do this: Delete it

Git emails that I am not really tracking right now, but do keep
Matches: from:([hidden email]) list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Mark as read, Apply label "ML/Lucene-GitBox",
Never send it to Spam

Moderation emails I help with
Matches: subject:(MODERATE for [hidden email])
Do this: Skip Inbox, Apply label "Solr-Moderate"

Matches: list:"<solr-user.lucene.apache.org>"
Do this: Skip Inbox, Apply label "ML/SolrUsers"

Regards,
    Alex.

On Wed, 7 Aug 2019 at 07:54, David Smiley <[hidden email]> wrote:

>
> 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 <[hidden email]> 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 <[hidden email]>:
>> >
>> > 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/trends.html?dev@...: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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Erick Erickson
+1 to Jan’s idea of the bot-originated lists be announce only…..

Personally I’ve been able to make some sense out of the messages by

1> switching to the mac mail client (not an option for others, I know). It threads pretty well and for those topics where there are 10 replies I only have to glance at one to see if I’m interested enough to pursue.

2> I have a _lot_ of filters set up.

I have to admit that one of the motivations for moving to the mail program on the mac was because gmail’s filters are such a disaster. Or I just totally missed how to configure them. For instance, changing the order of execution was impossible, so when I wanted to make a new filter execute first I had to redefine the entire list…..

> On Aug 8, 2019, at 5:31 AM, Alexandre Rafalovitch <[hidden email]> wrote:
>
> I apply the following (gmail) rules, just in case it helps somebody.
> With this combination, I am able to track human conversations
> reasonably well.
>
> Human conversation:
> Matches: from:(-[hidden email]) subject:(-[jira]) list:<dev.lucene.apache.org>
> Do this: Skip Inbox, Apply label "ML/Lucene-dev"
>
> All JIRA issues, regardless of other filters
> Matches: subject:([jira] {SOLR- LUCENE-}) list:"dev.lucene.apache.org"
> Do this: Skip Inbox, Apply label "ML/Lucene-jira", Never send it to Spam
>
> New JIRA issues (that I check to see if I want to track/comment before
> I remove the label)
> Matches: subject:("[Created]") list:(<dev.lucene.apache.org>)
> Do this: Skip Inbox, Apply label "ML/Lucene-Jira-Interesting", Never
> send it to Spam
>
> Updates on JIRA issues from me (I already know them)
> Matches: from:(Alexandre Rafalovitch (JIRA) <[hidden email]>)
> Do this: Skip Inbox, Mark as read, Star it, Apply label "Solr-Jiras"
>
> All JIRA issues I am involved in or marked to track
> Matches: from:([hidden email]) to:([hidden email])
> Do this: Skip Inbox, Apply label "Solr-Jiras"
>
> Delete JENKINS stuff, as I am currently not contributing
> Matches: subject:([JENKINS]) list:(<dev.lucene.apache.org>)
> Do this: Delete it
>
> Git emails that I am not really tracking right now, but do keep
> Matches: from:([hidden email]) list:(<dev.lucene.apache.org>)
> Do this: Skip Inbox, Mark as read, Apply label "ML/Lucene-GitBox",
> Never send it to Spam
>
> Moderation emails I help with
> Matches: subject:(MODERATE for [hidden email])
> Do this: Skip Inbox, Apply label "Solr-Moderate"
>
> Matches: list:"<solr-user.lucene.apache.org>"
> Do this: Skip Inbox, Apply label "ML/SolrUsers"
>
> Regards,
>    Alex.
>
> On Wed, 7 Aug 2019 at 07:54, David Smiley <[hidden email]> wrote:
>>
>> 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 <[hidden email]> 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 <[hidden email]>:
>>>>
>>>> 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/trends.html?dev@...: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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Jan Høydahl / Cominvent
I'll let this email topic run over the weekend to attract more eyeballs. Even if it's not a VOTE thread, feel free to add your +1 or -1's, and if others also seem in favour of this idea then I'll start working on it next week. To sum up what I believe to be the current consensus:

A new issues@ list (announce only) for JIRA and Github notifications
A new build@ list (announce only) for Jenkins notifications

Whether [Created|Resolved] mails for JIRA/PR should also go to Dev list is still an open question. To help decide, here's the expected volume for those (from reporter.apache.org:
357 issues opened in JIRA, past quarter, 270 issues closed in JIRA, past quarter, 155 PRs opened on GitHub, past quarter, 143 PRs closed on GitHub, past quarter
…which sums up to about 300/month or 10/day.
An alternative to this could be some script that runs once a day and emits ONE email per day with a digest with links to new/closed JIRAs and PRs last 24h.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

8. aug. 2019 kl. 14:15 skrev Erick Erickson <[hidden email]>:

+1 to Jan’s idea of the bot-originated lists be announce only…..

Personally I’ve been able to make some sense out of the messages by

1> switching to the mac mail client (not an option for others, I know). It threads pretty well and for those topics where there are 10 replies I only have to glance at one to see if I’m interested enough to pursue.

2> I have a _lot_ of filters set up.

I have to admit that one of the motivations for moving to the mail program on the mac was because gmail’s filters are such a disaster. Or I just totally missed how to configure them. For instance, changing the order of execution was impossible, so when I wanted to make a new filter execute first I had to redefine the entire list…..

On Aug 8, 2019, at 5:31 AM, Alexandre Rafalovitch <[hidden email]> wrote:

I apply the following (gmail) rules, just in case it helps somebody.
With this combination, I am able to track human conversations
reasonably well.

Human conversation:
Matches: from:(-[hidden email]) subject:(-[jira]) list:<dev.lucene.apache.org>
Do this: Skip Inbox, Apply label "ML/Lucene-dev"

All JIRA issues, regardless of other filters
Matches: subject:([jira] {SOLR- LUCENE-}) list:"dev.lucene.apache.org"
Do this: Skip Inbox, Apply label "ML/Lucene-jira", Never send it to Spam

New JIRA issues (that I check to see if I want to track/comment before
I remove the label)
Matches: subject:("[Created]") list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Apply label "ML/Lucene-Jira-Interesting", Never
send it to Spam

Updates on JIRA issues from me (I already know them)
Matches: from:(Alexandre Rafalovitch (JIRA) <[hidden email]>)
Do this: Skip Inbox, Mark as read, Star it, Apply label "Solr-Jiras"

All JIRA issues I am involved in or marked to track
Matches: from:([hidden email]) to:([hidden email])
Do this: Skip Inbox, Apply label "Solr-Jiras"

Delete JENKINS stuff, as I am currently not contributing
Matches: subject:([JENKINS]) list:(<dev.lucene.apache.org>)
Do this: Delete it

Git emails that I am not really tracking right now, but do keep
Matches: from:([hidden email]) list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Mark as read, Apply label "ML/Lucene-GitBox",
Never send it to Spam

Moderation emails I help with
Matches: subject:(MODERATE for [hidden email])
Do this: Skip Inbox, Apply label "Solr-Moderate"

Matches: list:"<solr-user.lucene.apache.org>"
Do this: Skip Inbox, Apply label "ML/SolrUsers"

Regards,
  Alex.

On Wed, 7 Aug 2019 at 07:54, David Smiley <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]>:

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/trends.html?[hidden email]: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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]



---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Namgyu Kim
+1 to Jan's idea :D
I think it's better to split the mailing list.

But I have a little opinion about the name.
Which one is better, the singular(build-issue) or the plural(builds-issues)?
Personally, "build-issue" looks better because names of the our mailing list are used as a singular. (not jave-users but java-user)

What do you think about this?

2019년 8월 8일 (목) 오후 9:42, Jan Høydahl <[hidden email]>님이 작성:
I'll let this email topic run over the weekend to attract more eyeballs. Even if it's not a VOTE thread, feel free to add your +1 or -1's, and if others also seem in favour of this idea then I'll start working on it next week. To sum up what I believe to be the current consensus:

A new issues@ list (announce only) for JIRA and Github notifications
A new build@ list (announce only) for Jenkins notifications

Whether [Created|Resolved] mails for JIRA/PR should also go to Dev list is still an open question. To help decide, here's the expected volume for those (from reporter.apache.org:
357 issues opened in JIRA, past quarter, 270 issues closed in JIRA, past quarter, 155 PRs opened on GitHub, past quarter, 143 PRs closed on GitHub, past quarter
…which sums up to about 300/month or 10/day.
An alternative to this could be some script that runs once a day and emits ONE email per day with a digest with links to new/closed JIRAs and PRs last 24h.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

8. aug. 2019 kl. 14:15 skrev Erick Erickson <[hidden email]>:

+1 to Jan’s idea of the bot-originated lists be announce only…..

Personally I’ve been able to make some sense out of the messages by

1> switching to the mac mail client (not an option for others, I know). It threads pretty well and for those topics where there are 10 replies I only have to glance at one to see if I’m interested enough to pursue.

2> I have a _lot_ of filters set up.

I have to admit that one of the motivations for moving to the mail program on the mac was because gmail’s filters are such a disaster. Or I just totally missed how to configure them. For instance, changing the order of execution was impossible, so when I wanted to make a new filter execute first I had to redefine the entire list…..

On Aug 8, 2019, at 5:31 AM, Alexandre Rafalovitch <[hidden email]> wrote:

I apply the following (gmail) rules, just in case it helps somebody.
With this combination, I am able to track human conversations
reasonably well.

Human conversation:
Matches: from:(-[hidden email]) subject:(-[jira]) list:<dev.lucene.apache.org>
Do this: Skip Inbox, Apply label "ML/Lucene-dev"

All JIRA issues, regardless of other filters
Matches: subject:([jira] {SOLR- LUCENE-}) list:"dev.lucene.apache.org"
Do this: Skip Inbox, Apply label "ML/Lucene-jira", Never send it to Spam

New JIRA issues (that I check to see if I want to track/comment before
I remove the label)
Matches: subject:("[Created]") list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Apply label "ML/Lucene-Jira-Interesting", Never
send it to Spam

Updates on JIRA issues from me (I already know them)
Matches: from:(Alexandre Rafalovitch (JIRA) <[hidden email]>)
Do this: Skip Inbox, Mark as read, Star it, Apply label "Solr-Jiras"

All JIRA issues I am involved in or marked to track
Matches: from:([hidden email]) to:([hidden email])
Do this: Skip Inbox, Apply label "Solr-Jiras"

Delete JENKINS stuff, as I am currently not contributing
Matches: subject:([JENKINS]) list:(<dev.lucene.apache.org>)
Do this: Delete it

Git emails that I am not really tracking right now, but do keep
Matches: from:([hidden email]) list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Mark as read, Apply label "ML/Lucene-GitBox",
Never send it to Spam

Moderation emails I help with
Matches: subject:(MODERATE for [hidden email])
Do this: Skip Inbox, Apply label "Solr-Moderate"

Matches: list:"<solr-user.lucene.apache.org>"
Do this: Skip Inbox, Apply label "ML/SolrUsers"

Regards,
  Alex.

On Wed, 7 Aug 2019 at 07:54, David Smiley <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]>:

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/trends.html?dev@...: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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]



---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Jan Høydahl / Cominvent
We already have commits@, so let’s go with issues@ and builds@

Jan Høydahl

8. aug. 2019 kl. 18:32 skrev Namgyu Kim <[hidden email]>:

+1 to Jan's idea :D
I think it's better to split the mailing list.

But I have a little opinion about the name.
Which one is better, the singular(build-issue) or the plural(builds-issues)?
Personally, "build-issue" looks better because names of the our mailing list are used as a singular. (not jave-users but java-user)

What do you think about this?

2019년 8월 8일 (목) 오후 9:42, Jan Høydahl <[hidden email]>님이 작성:
I'll let this email topic run over the weekend to attract more eyeballs. Even if it's not a VOTE thread, feel free to add your +1 or -1's, and if others also seem in favour of this idea then I'll start working on it next week. To sum up what I believe to be the current consensus:

A new issues@ list (announce only) for JIRA and Github notifications
A new build@ list (announce only) for Jenkins notifications

Whether [Created|Resolved] mails for JIRA/PR should also go to Dev list is still an open question. To help decide, here's the expected volume for those (from reporter.apache.org:
357 issues opened in JIRA, past quarter, 270 issues closed in JIRA, past quarter, 155 PRs opened on GitHub, past quarter, 143 PRs closed on GitHub, past quarter
…which sums up to about 300/month or 10/day.
An alternative to this could be some script that runs once a day and emits ONE email per day with a digest with links to new/closed JIRAs and PRs last 24h.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

8. aug. 2019 kl. 14:15 skrev Erick Erickson <[hidden email]>:

+1 to Jan’s idea of the bot-originated lists be announce only…..

Personally I’ve been able to make some sense out of the messages by

1> switching to the mac mail client (not an option for others, I know). It threads pretty well and for those topics where there are 10 replies I only have to glance at one to see if I’m interested enough to pursue.

2> I have a _lot_ of filters set up.

I have to admit that one of the motivations for moving to the mail program on the mac was because gmail’s filters are such a disaster. Or I just totally missed how to configure them. For instance, changing the order of execution was impossible, so when I wanted to make a new filter execute first I had to redefine the entire list…..

On Aug 8, 2019, at 5:31 AM, Alexandre Rafalovitch <[hidden email]> wrote:

I apply the following (gmail) rules, just in case it helps somebody.
With this combination, I am able to track human conversations
reasonably well.

Human conversation:
Matches: from:(-[hidden email]) subject:(-[jira]) list:<dev.lucene.apache.org>
Do this: Skip Inbox, Apply label "ML/Lucene-dev"

All JIRA issues, regardless of other filters
Matches: subject:([jira] {SOLR- LUCENE-}) list:"dev.lucene.apache.org"
Do this: Skip Inbox, Apply label "ML/Lucene-jira", Never send it to Spam

New JIRA issues (that I check to see if I want to track/comment before
I remove the label)
Matches: subject:("[Created]") list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Apply label "ML/Lucene-Jira-Interesting", Never
send it to Spam

Updates on JIRA issues from me (I already know them)
Matches: from:(Alexandre Rafalovitch (JIRA) <[hidden email]>)
Do this: Skip Inbox, Mark as read, Star it, Apply label "Solr-Jiras"

All JIRA issues I am involved in or marked to track
Matches: from:([hidden email]) to:([hidden email])
Do this: Skip Inbox, Apply label "Solr-Jiras"

Delete JENKINS stuff, as I am currently not contributing
Matches: subject:([JENKINS]) list:(<dev.lucene.apache.org>)
Do this: Delete it

Git emails that I am not really tracking right now, but do keep
Matches: from:([hidden email]) list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Mark as read, Apply label "ML/Lucene-GitBox",
Never send it to Spam

Moderation emails I help with
Matches: subject:(MODERATE for [hidden email])
Do this: Skip Inbox, Apply label "Solr-Moderate"

Matches: list:"<solr-user.lucene.apache.org>"
Do this: Skip Inbox, Apply label "ML/SolrUsers"

Regards,
  Alex.

On Wed, 7 Aug 2019 at 07:54, David Smiley <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]>:

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/trends.html?dev@...: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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]



---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

david.w.smiley@gmail.com
In reply to this post by Jan Høydahl / Cominvent

On Thu, Aug 8, 2019 at 2:42 PM Jan Høydahl <[hidden email]> wrote:
...
Whether [Created|Resolved] mails for JIRA/PR should also go to Dev list is still an open question. To help decide, here's the expected volume for those (from reporter.apache.org:
357 issues opened in JIRA, past quarter, 270 issues closed in JIRA, past quarter, 155 PRs opened on GitHub, past quarter, 143 PRs closed on GitHub, past quarter
…which sums up to about 300/month or 10/day.
An alternative to this could be some script that runs once a day and emits ONE email per day with a digest with links to new/closed JIRAs and PRs last 24h.


The summary script sounds great to me. Maybe just JIRA is fine here since it's the master place holding the issue status.  JIRA supports creating saved searches called "Filters" and you can add an email based "Subscription" to them.  I was just exploring this option.  We could create a saved filter and document to interested users on how to subscribe themselves, and/or we could get the dev list subscribed for a daily summary email.  WDYT?
Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Jan Høydahl / Cominvent

> Maybe just JIRA is fine here since it's the master place holding the issue status.
+1

> we could get the dev list subscribed for a daily summary email.  WDYT?
This is quick to test out and would probably work well.

Or perhaps, as Alexandre does with his filtering, only subscribe to [Created] from Jira, there’s 4-5 per day which is not that bad, and then it is easier to scan your mailbox for interesting subject lines for issues to “follow” directly?

Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Namgyu Kim
In reply to this post by Jan Høydahl / Cominvent
+1 for issues@ and builds@
Thanks Jan :)


2019년 8월 9일 (금) 오전 3:02, Jan Høydahl <[hidden email]>님이 작성:
We already have commits@, so let’s go with issues@ and builds@

Jan Høydahl

8. aug. 2019 kl. 18:32 skrev Namgyu Kim <[hidden email]>:

+1 to Jan's idea :D
I think it's better to split the mailing list.

But I have a little opinion about the name.
Which one is better, the singular(build-issue) or the plural(builds-issues)?
Personally, "build-issue" looks better because names of the our mailing list are used as a singular. (not jave-users but java-user)

What do you think about this?

2019년 8월 8일 (목) 오후 9:42, Jan Høydahl <[hidden email]>님이 작성:
I'll let this email topic run over the weekend to attract more eyeballs. Even if it's not a VOTE thread, feel free to add your +1 or -1's, and if others also seem in favour of this idea then I'll start working on it next week. To sum up what I believe to be the current consensus:

A new issues@ list (announce only) for JIRA and Github notifications
A new build@ list (announce only) for Jenkins notifications

Whether [Created|Resolved] mails for JIRA/PR should also go to Dev list is still an open question. To help decide, here's the expected volume for those (from reporter.apache.org:
357 issues opened in JIRA, past quarter, 270 issues closed in JIRA, past quarter, 155 PRs opened on GitHub, past quarter, 143 PRs closed on GitHub, past quarter
…which sums up to about 300/month or 10/day.
An alternative to this could be some script that runs once a day and emits ONE email per day with a digest with links to new/closed JIRAs and PRs last 24h.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

8. aug. 2019 kl. 14:15 skrev Erick Erickson <[hidden email]>:

+1 to Jan’s idea of the bot-originated lists be announce only…..

Personally I’ve been able to make some sense out of the messages by

1> switching to the mac mail client (not an option for others, I know). It threads pretty well and for those topics where there are 10 replies I only have to glance at one to see if I’m interested enough to pursue.

2> I have a _lot_ of filters set up.

I have to admit that one of the motivations for moving to the mail program on the mac was because gmail’s filters are such a disaster. Or I just totally missed how to configure them. For instance, changing the order of execution was impossible, so when I wanted to make a new filter execute first I had to redefine the entire list…..

On Aug 8, 2019, at 5:31 AM, Alexandre Rafalovitch <[hidden email]> wrote:

I apply the following (gmail) rules, just in case it helps somebody.
With this combination, I am able to track human conversations
reasonably well.

Human conversation:
Matches: from:(-[hidden email]) subject:(-[jira]) list:<dev.lucene.apache.org>
Do this: Skip Inbox, Apply label "ML/Lucene-dev"

All JIRA issues, regardless of other filters
Matches: subject:([jira] {SOLR- LUCENE-}) list:"dev.lucene.apache.org"
Do this: Skip Inbox, Apply label "ML/Lucene-jira", Never send it to Spam

New JIRA issues (that I check to see if I want to track/comment before
I remove the label)
Matches: subject:("[Created]") list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Apply label "ML/Lucene-Jira-Interesting", Never
send it to Spam

Updates on JIRA issues from me (I already know them)
Matches: from:(Alexandre Rafalovitch (JIRA) <[hidden email]>)
Do this: Skip Inbox, Mark as read, Star it, Apply label "Solr-Jiras"

All JIRA issues I am involved in or marked to track
Matches: from:([hidden email]) to:([hidden email])
Do this: Skip Inbox, Apply label "Solr-Jiras"

Delete JENKINS stuff, as I am currently not contributing
Matches: subject:([JENKINS]) list:(<dev.lucene.apache.org>)
Do this: Delete it

Git emails that I am not really tracking right now, but do keep
Matches: from:([hidden email]) list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Mark as read, Apply label "ML/Lucene-GitBox",
Never send it to Spam

Moderation emails I help with
Matches: subject:(MODERATE for [hidden email])
Do this: Skip Inbox, Apply label "Solr-Moderate"

Matches: list:"<solr-user.lucene.apache.org>"
Do this: Skip Inbox, Apply label "ML/SolrUsers"

Regards,
  Alex.

On Wed, 7 Aug 2019 at 07:54, David Smiley <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]>:

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/trends.html?dev@...: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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]



---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Separate dev mailing list for automated mails?

Jan Høydahl / Cominvent
Ok, time to execute on this, please engage in https://issues.apache.org/jira/browse/LUCENE-8951 if you want to contribute!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

9. aug. 2019 kl. 01:08 skrev Namgyu Kim <[hidden email]>:

+1 for issues@ and builds@
Thanks Jan :)


2019년 8월 9일 (금) 오전 3:02, Jan Høydahl <[hidden email]>님이 작성:
We already have commits@, so let’s go with issues@ and builds@

Jan Høydahl

8. aug. 2019 kl. 18:32 skrev Namgyu Kim <[hidden email]>:

+1 to Jan's idea :D
I think it's better to split the mailing list.

But I have a little opinion about the name.
Which one is better, the singular(build-issue) or the plural(builds-issues)?
Personally, "build-issue" looks better because names of the our mailing list are used as a singular. (not jave-users but java-user)

What do you think about this?

2019년 8월 8일 (목) 오후 9:42, Jan Høydahl <[hidden email]>님이 작성:
I'll let this email topic run over the weekend to attract more eyeballs. Even if it's not a VOTE thread, feel free to add your +1 or -1's, and if others also seem in favour of this idea then I'll start working on it next week. To sum up what I believe to be the current consensus:

A new issues@ list (announce only) for JIRA and Github notifications
A new build@ list (announce only) for Jenkins notifications

Whether [Created|Resolved] mails for JIRA/PR should also go to Dev list is still an open question. To help decide, here's the expected volume for those (from reporter.apache.org:
357 issues opened in JIRA, past quarter, 270 issues closed in JIRA, past quarter, 155 PRs opened on GitHub, past quarter, 143 PRs closed on GitHub, past quarter
…which sums up to about 300/month or 10/day.
An alternative to this could be some script that runs once a day and emits ONE email per day with a digest with links to new/closed JIRAs and PRs last 24h.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

8. aug. 2019 kl. 14:15 skrev Erick Erickson <[hidden email]>:

+1 to Jan’s idea of the bot-originated lists be announce only…..

Personally I’ve been able to make some sense out of the messages by

1> switching to the mac mail client (not an option for others, I know). It threads pretty well and for those topics where there are 10 replies I only have to glance at one to see if I’m interested enough to pursue.

2> I have a _lot_ of filters set up.

I have to admit that one of the motivations for moving to the mail program on the mac was because gmail’s filters are such a disaster. Or I just totally missed how to configure them. For instance, changing the order of execution was impossible, so when I wanted to make a new filter execute first I had to redefine the entire list…..

On Aug 8, 2019, at 5:31 AM, Alexandre Rafalovitch <[hidden email]> wrote:

I apply the following (gmail) rules, just in case it helps somebody.
With this combination, I am able to track human conversations
reasonably well.

Human conversation:
Matches: from:(-[hidden email]) subject:(-[jira]) list:<dev.lucene.apache.org>
Do this: Skip Inbox, Apply label "ML/Lucene-dev"

All JIRA issues, regardless of other filters
Matches: subject:([jira] {SOLR- LUCENE-}) list:"dev.lucene.apache.org"
Do this: Skip Inbox, Apply label "ML/Lucene-jira", Never send it to Spam

New JIRA issues (that I check to see if I want to track/comment before
I remove the label)
Matches: subject:("[Created]") list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Apply label "ML/Lucene-Jira-Interesting", Never
send it to Spam

Updates on JIRA issues from me (I already know them)
Matches: from:(Alexandre Rafalovitch (JIRA) <[hidden email]>)
Do this: Skip Inbox, Mark as read, Star it, Apply label "Solr-Jiras"

All JIRA issues I am involved in or marked to track
Matches: from:([hidden email]) to:([hidden email])
Do this: Skip Inbox, Apply label "Solr-Jiras"

Delete JENKINS stuff, as I am currently not contributing
Matches: subject:([JENKINS]) list:(<dev.lucene.apache.org>)
Do this: Delete it

Git emails that I am not really tracking right now, but do keep
Matches: from:([hidden email]) list:(<dev.lucene.apache.org>)
Do this: Skip Inbox, Mark as read, Apply label "ML/Lucene-GitBox",
Never send it to Spam

Moderation emails I help with
Matches: subject:(MODERATE for [hidden email])
Do this: Skip Inbox, Apply label "Solr-Moderate"

Matches: list:"<solr-user.lucene.apache.org>"
Do this: Skip Inbox, Apply label "ML/SolrUsers"

Regards,
  Alex.

On Wed, 7 Aug 2019 at 07:54, David Smiley <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]>:

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/trends.html?dev@...: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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]



---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]