Re: [Discuss] Split the dev@ mailing list?

[Andy Seaborne]

Ok, we can see how it goes.

I'll kick off the VOTE for the minimal proposal in a moment.

Andy

On 13/12/2019 15:32, ajs6f wrote:

I'm +1 to splitting off pr@, -0 to splitting off issues@. I don't see that the 
gain is worth creating another list, managing more subscriptions, missing 
replies when they go to the wrong list, etc., but if other folks would like to 
try it, I'm not -1 against it.

ajs6f


On Dec 13, 2019, at 10:07 AM, Andy Seaborne  wrote:

Adam - where are we on this?

My understanding is that the difference in the discussion is around how JIRA is 
handled after we direct all GH traffic to pr@.

Either we leave JIRA emails coming to dev@ or we direct them to a new issues@.

Even with GH not causing additional JIRA ticket entries, the dev@ list may 
still be a bit busy. JIRA has it's own level of additional emails.

The sender is "j...@apache.org"; reply-to: is "dev@".

How "reply" works is different for different email clients:

GMail:

I only get the option of replying to the dev@list and that will not get put 
back on the ticket.

Thunderbird:

I get "reply" which goes to "j...@apache.org" and will update the ticket, and "reply 
list" to "dev@".

What are you hoping for by having JIRA emails go to dev@


I've just setup a personal JIRA filter subscription and now get a list of new tickets 
from the past 24 hours, sent to me once a day. I use this from JIRA cloud - I wanted to 
make sure it works for the Apache installation. The "watching" controls also 
work so a person can track specific tickets.

Andy

On 10/12/2019 08:44, Andy Seaborne wrote:

On 09/12/2019 20:51, Andy Seaborne wrote:



On 09/12/2019 16:26, ajs6f wrote:

I'm not sure why I would want to use a clunky and less-functional (no reply-to 
to comment on PR, non-formatting-aware) email list instead of the more 
powerful_and_  more pleasant GH system.


No one is asking you to.
It is not either-or.

GH tools remain untouched as they are today.
  >> PR discussion is done on GH

  > any comment on a PR creates at least three email messages in my inbox,

One of the copies, the useful message, you get is direct from GH, not via ASF 
(assuming you have GH notifications on)


1. Turn off auto-mirroring of all PR comments (which now starts once a ticket 
is mentioned) from GH to Jira.


Yes
  >> all PR traffic to pr@

  >2. Put PR comments on a separate pr@ list to record them.

Yes
  >> all PR [email] traffic to pr@


The only difference here is whether JIRA goes to issues@.
Anyone can combine their email into one folder (as they can separate it today). 
The difference is really on the archives.

missing the other big benefit - the dev@ is more approachable for people 
dropping in and showing an interest.


The one thing we still JIRA for because there isn't "issues" on GH
(and they are weak as a long term record IMO).

  Andy

Re: [Discuss] Split the dev@ mailing list?

[ajs6f]

I'm +1 to splitting off pr@, -0 to splitting off issues@. I don't see that the 
gain is worth creating another list, managing more subscriptions, missing 
replies when they go to the wrong list, etc., but if other folks would like to 
try it, I'm not -1 against it.

ajs6f

> On Dec 13, 2019, at 10:07 AM, Andy Seaborne  wrote:
> 
> Adam - where are we on this?
> 
> My understanding is that the difference in the discussion is around how JIRA 
> is handled after we direct all GH traffic to pr@.
> 
> Either we leave JIRA emails coming to dev@ or we direct them to a new issues@.
> 
> Even with GH not causing additional JIRA ticket entries, the dev@ list may 
> still be a bit busy. JIRA has it's own level of additional emails.
> 
> The sender is "j...@apache.org"; reply-to: is "dev@".
> 
> How "reply" works is different for different email clients:
> 
> GMail:
> 
> I only get the option of replying to the dev@list and that will not get put 
> back on the ticket.
> 
> Thunderbird:
> 
> I get "reply" which goes to "j...@apache.org" and will update the ticket, and 
> "reply list" to "dev@".
> 
> What are you hoping for by having JIRA emails go to dev@
> 
> 
> I've just setup a personal JIRA filter subscription and now get a list of new 
> tickets from the past 24 hours, sent to me once a day. I use this from JIRA 
> cloud - I wanted to make sure it works for the Apache installation. The 
> "watching" controls also work so a person can track specific tickets.
> 
>Andy
> 
> On 10/12/2019 08:44, Andy Seaborne wrote:
>> On 09/12/2019 20:51, Andy Seaborne wrote:
>>> 
>>> 
>>> On 09/12/2019 16:26, ajs6f wrote:
 I'm not sure why I would want to use a clunky and less-functional (no 
 reply-to to comment on PR, non-formatting-aware) email list instead of the 
 more powerful_and_  more pleasant GH system.
>>> 
>>> No one is asking you to.
>>> It is not either-or.
>>> 
>>> GH tools remain untouched as they are today.
>>>  >> PR discussion is done on GH
>>> 
>>>  > any comment on a PR creates at least three email messages in my inbox,
>>> 
>>> One of the copies, the useful message, you get is direct from GH, not via 
>>> ASF (assuming you have GH notifications on)
>>> 
 1. Turn off auto-mirroring of all PR comments (which now starts once a 
 ticket is mentioned) from GH to Jira. 
>>> 
>>> Yes
>>>  >> all PR traffic to pr@
>>> 
>>>  >2. Put PR comments on a separate pr@ list to record them.
>>> 
>>> Yes
>>>  >> all PR [email] traffic to pr@
>>> 
>>> 
>>> The only difference here is whether JIRA goes to issues@.
>>> Anyone can combine their email into one folder (as they can separate it 
>>> today). The difference is really on the archives.
>> missing the other big benefit - the dev@ is more approachable for people 
>> dropping in and showing an interest.
>>> 
>>> The one thing we still JIRA for because there isn't "issues" on GH
>>> (and they are weak as a long term record IMO).
>>> 
>>>  Andy
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 

Re: [Discuss] Split the dev@ mailing list?

[Andy Seaborne]

Adam - where are we on this?

My understanding is that the difference in the discussion is around how 
JIRA is handled after we direct all GH traffic to pr@.


Either we leave JIRA emails coming to dev@ or we direct them to a new 
issues@.


Even with GH not causing additional JIRA ticket entries, the dev@ list 
may still be a bit busy. JIRA has it's own level of additional emails.


The sender is "j...@apache.org"; reply-to: is "dev@".

How "reply" works is different for different email clients:

GMail:

I only get the option of replying to the dev@list and that will not get 
put back on the ticket.


Thunderbird:

I get "reply" which goes to "j...@apache.org" and will update the 
ticket, and "reply list" to "dev@".


What are you hoping for by having JIRA emails go to dev@


I've just setup a personal JIRA filter subscription and now get a list 
of new tickets from the past 24 hours, sent to me once a day. I use this 
from JIRA cloud - I wanted to make sure it works for the Apache 
installation. The "watching" controls also work so a person can track 
specific tickets.


Andy

On 10/12/2019 08:44, Andy Seaborne wrote:



On 09/12/2019 20:51, Andy Seaborne wrote:



On 09/12/2019 16:26, ajs6f wrote:
I'm not sure why I would want to use a clunky and less-functional (no 
reply-to to comment on PR, non-formatting-aware) email list instead 
of the more powerful_and_  more pleasant GH system.


No one is asking you to.
It is not either-or.

GH tools remain untouched as they are today.
 >> PR discussion is done on GH

 > any comment on a PR creates at least three email messages in my inbox,

One of the copies, the useful message, you get is direct from GH, not 
via ASF (assuming you have GH notifications on)


1. Turn off auto-mirroring of all PR comments (which now starts once 
a ticket is mentioned) from GH to Jira. 


Yes
 >> all PR traffic to pr@

 >2. Put PR comments on a separate pr@ list to record them.

Yes
 >> all PR [email] traffic to pr@


The only difference here is whether JIRA goes to issues@.
Anyone can combine their email into one folder (as they can separate 
it today). The difference is really on the archives.


missing the other big benefit - the dev@ is more approachable for people 
dropping in and showing an interest.




The one thing we still JIRA for because there isn't "issues" on GH
(and they are weak as a long term record IMO).

 Andy

Re: [Discuss] Split the dev@ mailing list?

[Andy Seaborne]

On 09/12/2019 20:51, Andy Seaborne wrote:



On 09/12/2019 16:26, ajs6f wrote:
I'm not sure why I would want to use a clunky and less-functional (no 
reply-to to comment on PR, non-formatting-aware) email list instead of 
the more powerful_and_  more pleasant GH system.


No one is asking you to.
It is not either-or.

GH tools remain untouched as they are today.
 >> PR discussion is done on GH

 > any comment on a PR creates at least three email messages in my inbox,

One of the copies, the useful message, you get is direct from GH, not 
via ASF (assuming you have GH notifications on)


1. Turn off auto-mirroring of all PR comments (which now starts once a 
ticket is mentioned) from GH to Jira. 


Yes
 >> all PR traffic to pr@

 >2. Put PR comments on a separate pr@ list to record them.

Yes
 >> all PR [email] traffic to pr@


The only difference here is whether JIRA goes to issues@.
Anyone can combine their email into one folder (as they can separate it 
today). The difference is really on the archives.


missing the other big benefit - the dev@ is more approachable for people 
dropping in and showing an interest.




The one thing we still JIRA for because there isn't "issues" on GH
(and they are weak as a long term record IMO).

     Andy

Re: [Discuss] Split the dev@ mailing list?

[Andy Seaborne]

On 09/12/2019 16:26, ajs6f wrote:

I'm not sure why I would want to use a clunky and less-functional (no reply-to 
to comment on PR, non-formatting-aware) email list instead of the more 
powerful_and_  more pleasant GH system.


No one is asking you to.
It is not either-or.

GH tools remain untouched as they are today.
>> PR discussion is done on GH

> any comment on a PR creates at least three email messages in my inbox,

One of the copies, the useful message, you get is direct from GH, not 
via ASF (assuming you have GH notifications on)


1. Turn off auto-mirroring of all PR comments (which now starts once a ticket is mentioned) from GH to Jira. 


Yes
>> all PR traffic to pr@

>2. Put PR comments on a separate pr@ list to record them.

Yes
>> all PR [email] traffic to pr@


The only difference here is whether JIRA goes to issues@.
Anyone can combine their email into one folder (as they can separate it 
today). The difference is really on the archives.


The one thing we still JIRA for because there isn't "issues" on GH
(and they are weak as a long term record IMO).

Andy

Re: [Discuss] Split the dev@ mailing list?

[ajs6f]

> On Dec 9, 2019, at 10:01 AM, Andy Seaborne  wrote:
> The important point is a less-busy dev@.

Well, I want the right discussion on dev@, not just less discussion. Now that I 
go back and look over the recent archives, it's not clear to me at all that if 
we drop all the duplication we are now getting because of Jira-GH-dev 
reflection that dev@ is actually too busy.

> So can you +1 the discussion now

Not yet, because it is not clear to me that this is the minimal improvement. 
(see below)

> Whatever we do, we can fine-tune later when we see how it works in practice.
> 
>> I wouldn't subscribe to a pr@ list. GH's native service for that kind of 
>> communication is much better than any email list.
> (Though if you subscribe, can't you then choose not to have notifications 
> direct?)

I'm not sure why I would want to use a clunky and less-functional (no reply-to 
to comment on PR, non-formatting-aware) email list instead of the more powerful 
_and_ more pleasant GH system. No offense meant to INFRA; they are amazing 
people who often accomplish more in an hour than I often do in a day, but a 
mailing list is no substitute for the sophisticated integration that GH has 
done for email notifications and PRs.

> Agreed. (But that's actually separate from splitting the dev@ list.)
> I checked and it does not happen in some other projects so it does look 
> possible.
> Before I go and talk to infra, I do need to show its the PMC wanting to make 
> changes.

That (getting traffic off Jira and thereby lowering the _duplicated_ traffic to 
dec@) is actually the major change that interests me. I am ready to +1 a change 
that reduces the duplication without doing anything else more then necessary. 
Are you willing to start with a smaller proposal?

1. Turn off auto-mirroring of all PR comments (which now starts once a ticket 
is mentioned) from GH to Jira. Perhaps it could be manually triggered 
per-comment by mentioning the ticket, or some other more "throttled" way, but 
of course we need to talk to INFRA to see what is possible.

and

2. Put PR comments on a separate pr@ list to record them.

I suspect that will reduce the dev@ traffic enough that we may not have to do 
anything else. No more PR comment ping-pong might mean no new issues@ list.

> I want to get to tickets as soon as possible. At the moment we have some 
> ideas and next we can get some agreed general directions.
> e.g. new API in addition to a ported existing one?; or changes within the 
> existing one?
> Tickets work best for getting taking a proposal through the details.  We need 
> the proposal first. Otherwise tickets are a record of ideas with unclear 
> commitment to progress.  Too many tickets dilutes discussion

I think our confusion is exactly over what a "proposal" is. From my POV, we 
already have bunch of proposals, just at different stages of detail. (see below 
re: concreteness)

As for the issue you specifically give as an example-- I'm a bit surprised. I 
had understood us to be specifically talking about a new API. I am much less 
interested in evolving the old one radically. To be clear, I don't mean that I 
want to throw it away or anything insane like that, just that in the new 
proposal space we have no reason to worry about backward compatibility. Of 
course we'll want to start abstractly with the current API because it is 
successful and encodes a lot of hard-earnt experience. But it's a new API that 
we are talking about in my mind.

All that having been said, I'm not able to step up with a bunch of volunteer 
hours right now ($job is becoming progressively less interested in semweb and 
less willing to allocate time for suchlike), so if the community feels that a 
stark new API is too ambitious, fair enough.

> You (ajs6f) put forward some general ideas (Nov 21) in other Model APIs and 
> SPARQL - how about moving those into some thing more concrete , not necessary 
> complete (!), so we can see where it leads to?

I don't understand what you want to see here before filing a ticket. Can you 
point at an example that is "more concrete, [but] not necessary complete" so I 
can get the sense of it? That would really help me.

Adam

Re: [Discuss] Split the dev@ mailing list?

[Andy Seaborne]

On 09/12/2019 13:26, ajs6f wrote:



For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on GH so 
the usual GH controls work for people.  pr@ is more of a safe archive.



GH notifications include the ability to reply via email to put a remark in the 
conversation. How will that work with this? IMO, that is important 
functionality that we can't throw away.


The change means emails go to a different list - we can leave reply-to 
as "GitBox ".


The important point is a less-busy dev@.


Anything that prevents the duplication of messages is good. Right now any 
comment on a PR creates at least three email messages in my inbox, all of which 
are duplicated and of which, only one is formatted usefully. First the useful 
message direct from GH, then a duplicate via copying onto dev@ (I realize it's 
for the record-- that doesn't make it useful or any less annoying), then one or 
more replications from Jira. So to the extent that we get any improvement on 
that from splitting out lists, great.


So can you +1 the discussion now?

Whatever we do, we can fine-tune later when we see how it works in practice.


I wouldn't subscribe to a pr@ list. GH's native service for that kind of 
communication is much better than any email list.


(Though if you subscribe, can't you then choose not to have 
notifications direct?)



But if keeping a separate list allows us to keep GH traffic off the main dev@ 
list and out of Jira, I'm +1 to that. Duplicating all PR comments onto the Jira 
issues has made Jira almost unusable for me. I can't page through screen after 
screen of nested email and GH quotes duplicating each other.


Agreed. (But that's actually separate from splitting the dev@ list.)

I checked and it does not happen in some other projects so it does look 
possible.


Before I go and talk to infra, I do need to show its the PMC wanting to 
make changes.


-


On another note, the question I was asking was about how to organize the API 
discussion. This proposal, while interesting in its own right, wouldn't do 
anything to address my concern. Filtering via [] subject components is a 
valuable and powerful technique, but it doesn't actually connect the thread to 
work proposed and it's difficult for many people. I'd rather start tickets for 
API ideas, but I'm willing to try something else, i.e. more list-based 
conversation for some further period.


I want to get to tickets as soon as possible. At the moment we have some 
ideas and next we can get some agreed general directions.


e.g. new API in addition to a ported existing one?; or changes within 
the existing one?


Tickets work best for getting taking a proposal through the details.  We 
need the proposal first. Otherwise tickets are a record of ideas with 
unclear commitment to progress.  Too many tickets dilutes discussion.


You (ajs6f) put forward some general ideas (Nov 21) in other Model APIs 
and SPARQL - how about moving those into some thing more concrete , not 
necessary complete (!), so we can see where it leads to?


Andy



ajs6f

Re: [Discuss] Split the dev@ mailing list?

[ajs6f]

>>> For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on GH 
>>> so the usual GH controls work for people.  pr@ is more of a safe archive.


GH notifications include the ability to reply via email to put a remark in the 
conversation. How will that work with this? IMO, that is important 
functionality that we can't throw away.

Anything that prevents the duplication of messages is good. Right now any 
comment on a PR creates at least three email messages in my inbox, all of which 
are duplicated and of which, only one is formatted usefully. First the useful 
message direct from GH, then a duplicate via copying onto dev@ (I realize it's 
for the record-- that doesn't make it useful or any less annoying), then one or 
more replications from Jira. So to the extent that we get any improvement on 
that from splitting out lists, great.

I wouldn't subscribe to a pr@ list. GH's native service for that kind of 
communication is much better than any email list. But if keeping a separate 
list allows us to keep GH traffic off the main dev@ list and out of Jira, I'm 
+1 to that. Duplicating all PR comments onto the Jira issues has made Jira 
almost unusable for me. I can't page through screen after screen of nested 
email and GH quotes duplicating each other.

On another note, the question I was asking was about how to organize the API 
discussion. This proposal, while interesting in its own right, wouldn't do 
anything to address my concern. Filtering via [] subject components is a 
valuable and powerful technique, but it doesn't actually connect the thread to 
work proposed and it's difficult for many people. I'd rather start tickets for 
API ideas, but I'm willing to try something else, i.e. more list-based 
conversation for some further period.

ajs6f

Re: [Discuss] Split the dev@ mailing list?

[Claude Warren]

+1  This change seems like it will make my life easier so I am in favor ;)

On Mon, Dec 9, 2019 at 11:48 AM Andy Seaborne  wrote:

>
>
> On 05/12/2019 14:12, Andy Seaborne wrote:
> > Now would be a good time to get this done so we can have dev@ for
> > discussions.
> >
> > Please yes/no/etc and when it settles down I'll run a vote.
>
> Ping?
>
> > When going to infra, we then have a definite PMC agreement to point to,
> > not some minority or rogue action.
> >
> > On 19/11/2019 19:55, aj...@apache.org wrote:
> >>
> >> Andy, you've given a nice list of potential discussions and others
> >> have as
> >> well. My meta-question is when do we want to switch to tickets for this
> >> process? I don't want to smother discussion in process, but I find it
> >> very
> >> hard to follow a multithreaded discussion over email and I much prefer
> >> breaking things out early to more specifics.
> >
> > Splitting the lists will make it easier. I think we switch to tickets
> > when there specific activities.  When sorting what the activities are,
> > there is benefit in using dev@ so we can see the interactions more
> > clearly. With a quieter dev@, sensible [] should mean anyone can see
> the
> > overall activity.  We can change this if it does not work out.
> >
> > List proposal:
> >
> > 2 new lists: issues@ (for JIRA) and pr@ (for github traffic).
> >
> > Reply-to on JIRA becomes a comment (which I think it does at the moment
> > - the reply is j...@apache.org)
> >
> > For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on
> > GH so the usual GH controls work for people.  pr@ is more of a safe
> > archive.
> >
> > Using the same names as other projects helps infrequent visitors to
> > navigate our lists. "issues" is a common name; there isn't a common name
> > for the "pr" that I found - and it's not that common to split out GH.
> > (Cassandra have pr@).
> >
> > If anyone wants to combine issues@and pr@ they can do so with their own
> > mail filtering rules.
> >
> > Routing:
> >
> > JIRA:
> >
> > There are bunch of events:
> >
> > Issue Created
> > Issue Updated
> > Issue Assigned
> > Issue Resolved
> > Issue Closed
> > Issue Commented
> > Issue Comment Edited
> > Issue Comment Deleted
> > Issue Reopened
> > Issue Deleted
> > Issue Moved
> >
> > These are all:
> >
> >  All Watchers
> >  Current Assignee
> >  Reporter
> >  Single Email Address (dev@jena.apache.org)
> >
> > I suggest that all go to issues@ and, in addition, "Created" goes to
> dev@
> >
> > I think PRs are linked to JIRA by the title JENA-. We don't need pr
> > discussion on JIRA if we have pr@ but it probably isn't a big deal
> > because either it's a PR discussion or JIRA discussion, rarely both.
> >
> > (but please keep the "^JENA-:" on PRs)
> >
> > Github: I don't know what's possible.
> >
> > My ideal is all PR traffic to pr@, and like JIRA, any created PRs
> > notices go to dev@.
> >
> > (There aren't a GH issues for the Apache mirrored projects)
> >
> >  Andy
> >
> > On 02/06/2019 13:57, ajs6f wrote:
> >> I like the idea of breaking PR discussions off, but if we're going to
> >> continue to copy PR comments onto Jira tickets it only makes sense if
> >> we have separate pr@ and issue@ lists. Also, we would have to stop
> >> copying them onto dev@ (which I would be fine with).
> >>
> >> Ideally, I would like to see ticket _creation_ cc:ed onto dev@, so
> >> that any interested parties would be aware without having to set up
> >> notifications in Jira, but other ticket actions not cc:ed. I'm not
> >> sure if that's possible with our gear, but I'm sure INFRA can tell us.
> >>
> >> ajs6f
> >>
> >>> On May 30, 2019, at 10:42 AM, Andy Seaborne  wrote:
> >>>
> >>> The dev@ list can be dominated by github discussions.
> >>>
> >>> We have feeds from github PRs and JIRA. We could split the list in
> >>> one list per feed to leave the dev@ list for people.
> >>>
> >>> While you can do this with mail client rules, searching using the
> >>> archives isn't easy.
> >>>
> >>> Suggestion:
> >>> Add email lists for:
> >>>
> >>> pr@ -- github pull request discussions.
> >>> issues@ -- JIRA
> >>>
> >>> I'm not sure how clever we can be - for example, it would be nice for
> >>> dev@ to get an email for the submission of a pull request, then not
> >>> the discussion, but I don't think that is configurable. (It is all
> >>> INFRa consifuration anyway AFAIK).
> >>>
> >>> These names are the ones I have seen other projects use.
> >>>
> >>> Thoughts?
> >>> What have you seen work for other projects?
> >>>
> >>> Andy
> >>>
> >>
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [Discuss] Split the dev@ mailing list?

[Andy Seaborne]

On 05/12/2019 14:12, Andy Seaborne wrote:
Now would be a good time to get this done so we can have dev@ for 
discussions.


Please yes/no/etc and when it settles down I'll run a vote.


Ping?

When going to infra, we then have a definite PMC agreement to point to, 
not some minority or rogue action.


On 19/11/2019 19:55, aj...@apache.org wrote:


Andy, you've given a nice list of potential discussions and others 
have as

well. My meta-question is when do we want to switch to tickets for this
process? I don't want to smother discussion in process, but I find it 
very

hard to follow a multithreaded discussion over email and I much prefer
breaking things out early to more specifics.


Splitting the lists will make it easier. I think we switch to tickets 
when there specific activities.  When sorting what the activities are, 
there is benefit in using dev@ so we can see the interactions more 
clearly. With a quieter dev@, sensible [] should mean anyone can see the 
overall activity.  We can change this if it does not work out.


List proposal:

2 new lists: issues@ (for JIRA) and pr@ (for github traffic).

Reply-to on JIRA becomes a comment (which I think it does at the moment 
- the reply is j...@apache.org)


For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on 
GH so the usual GH controls work for people.  pr@ is more of a safe 
archive.


Using the same names as other projects helps infrequent visitors to 
navigate our lists. "issues" is a common name; there isn't a common name 
for the "pr" that I found - and it's not that common to split out GH. 
(Cassandra have pr@).


If anyone wants to combine issues@and pr@ they can do so with their own 
mail filtering rules.


Routing:

JIRA:

There are bunch of events:

Issue Created
Issue Updated
Issue Assigned
Issue Resolved
Issue Closed
Issue Commented
Issue Comment Edited
Issue Comment Deleted
Issue Reopened
Issue Deleted
Issue Moved

These are all:

     All Watchers
     Current Assignee
     Reporter
     Single Email Address (dev@jena.apache.org)

I suggest that all go to issues@ and, in addition, "Created" goes to dev@

I think PRs are linked to JIRA by the title JENA-. We don't need pr 
discussion on JIRA if we have pr@ but it probably isn't a big deal 
because either it's a PR discussion or JIRA discussion, rarely both.


(but please keep the "^JENA-:" on PRs)

Github: I don't know what's possible.

My ideal is all PR traffic to pr@, and like JIRA, any created PRs 
notices go to dev@.


(There aren't a GH issues for the Apache mirrored projects)

     Andy

On 02/06/2019 13:57, ajs6f wrote:
I like the idea of breaking PR discussions off, but if we're going to 
continue to copy PR comments onto Jira tickets it only makes sense if 
we have separate pr@ and issue@ lists. Also, we would have to stop 
copying them onto dev@ (which I would be fine with).


Ideally, I would like to see ticket _creation_ cc:ed onto dev@, so 
that any interested parties would be aware without having to set up 
notifications in Jira, but other ticket actions not cc:ed. I'm not 
sure if that's possible with our gear, but I'm sure INFRA can tell us.


ajs6f


On May 30, 2019, at 10:42 AM, Andy Seaborne  wrote:

The dev@ list can be dominated by github discussions.

We have feeds from github PRs and JIRA. We could split the list in 
one list per feed to leave the dev@ list for people.


While you can do this with mail client rules, searching using the 
archives isn't easy.


Suggestion:
Add email lists for:

pr@ -- github pull request discussions.
issues@ -- JIRA

I'm not sure how clever we can be - for example, it would be nice for 
dev@ to get an email for the submission of a pull request, then not 
the discussion, but I don't think that is configurable. (It is all 
INFRa consifuration anyway AFAIK).


These names are the ones I have seen other projects use.

Thoughts?
What have you seen work for other projects?

    Andy

Re: [Discuss] Split the dev@ mailing list?

[Colin Gross]

Yes.  This works for me as I already have filters that essentially do the
separation proposed pretty well.

Colin A. Gross


On Thu, Dec 5, 2019 at 9:11 AM Andy Seaborne  wrote:

> Now would be a good time to get this done so we can have dev@ for
> discussions.
>
> Please yes/no/etc and when it settles down I'll run a vote.
> When going to infra, we then have a definite PMC agreement to point to,
> not some minority or rogue action.
>
> On 19/11/2019 19:55, aj...@apache.org wrote:
> >
> > Andy, you've given a nice list of potential discussions and others have
> as
> > well. My meta-question is when do we want to switch to tickets for this
> > process? I don't want to smother discussion in process, but I find it
> very
> > hard to follow a multithreaded discussion over email and I much prefer
> > breaking things out early to more specifics.
>
> Splitting the lists will make it easier. I think we switch to tickets
> when there specific activities.  When sorting what the activities are,
> there is benefit in using dev@ so we can see the interactions more
> clearly. With a quieter dev@, sensible [] should mean anyone can see the
> overall activity.  We can change this if it does not work out.
>
> List proposal:
>
> 2 new lists: issues@ (for JIRA) and pr@ (for github traffic).
>
> Reply-to on JIRA becomes a comment (which I think it does at the moment
> - the reply is j...@apache.org)
>
> For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on
> GH so the usual GH controls work for people.  pr@ is more of a safe
> archive.
>
> Using the same names as other projects helps infrequent visitors to
> navigate our lists. "issues" is a common name; there isn't a common name
> for the "pr" that I found - and it's not that common to split out GH.
> (Cassandra have pr@).
>
> If anyone wants to combine issues@and pr@ they can do so with their own
> mail filtering rules.
>
> Routing:
>
> JIRA:
>
> There are bunch of events:
>
> Issue Created
> Issue Updated
> Issue Assigned
> Issue Resolved
> Issue Closed
> Issue Commented
> Issue Comment Edited
> Issue Comment Deleted
> Issue Reopened
> Issue Deleted
> Issue Moved
>
> These are all:
>
>  All Watchers
>  Current Assignee
>  Reporter
>  Single Email Address (dev@jena.apache.org)
>
> I suggest that all go to issues@ and, in addition, "Created" goes to dev@
>
> I think PRs are linked to JIRA by the title JENA-. We don't need pr
> discussion on JIRA if we have pr@ but it probably isn't a big deal
> because either it's a PR discussion or JIRA discussion, rarely both.
>
> (but please keep the "^JENA-:" on PRs)
>
> Github: I don't know what's possible.
>
> My ideal is all PR traffic to pr@, and like JIRA, any created PRs
> notices go to dev@.
>
> (There aren't a GH issues for the Apache mirrored projects)
>
>  Andy
>
> On 02/06/2019 13:57, ajs6f wrote:
> > I like the idea of breaking PR discussions off, but if we're going to
> continue to copy PR comments onto Jira tickets it only makes sense if we
> have separate pr@ and issue@ lists. Also, we would have to stop copying
> them onto dev@ (which I would be fine with).
> >
> > Ideally, I would like to see ticket _creation_ cc:ed onto dev@, so that
> any interested parties would be aware without having to set up
> notifications in Jira, but other ticket actions not cc:ed. I'm not sure if
> that's possible with our gear, but I'm sure INFRA can tell us.
> >
> > ajs6f
> >
> >> On May 30, 2019, at 10:42 AM, Andy Seaborne  wrote:
> >>
> >> The dev@ list can be dominated by github discussions.
> >>
> >> We have feeds from github PRs and JIRA. We could split the list in one
> list per feed to leave the dev@ list for people.
> >>
> >> While you can do this with mail client rules, searching using the
> archives isn't easy.
> >>
> >> Suggestion:
> >> Add email lists for:
> >>
> >> pr@ -- github pull request discussions.
> >> issues@ -- JIRA
> >>
> >> I'm not sure how clever we can be - for example, it would be nice for
> dev@ to get an email for the submission of a pull request, then not the
> discussion, but I don't think that is configurable. (It is all INFRa
> consifuration anyway AFAIK).
> >>
> >> These names are the ones I have seen other projects use.
> >>
> >> Thoughts?
> >> What have you seen work for other projects?
> >>
> >> Andy
> >>
> >
>

[Discuss] Split the dev@ mailing list?

[Andy Seaborne]

Now would be a good time to get this done so we can have dev@ for 
discussions.


Please yes/no/etc and when it settles down I'll run a vote.
When going to infra, we then have a definite PMC agreement to point to, 
not some minority or rogue action.


On 19/11/2019 19:55, aj...@apache.org wrote:


Andy, you've given a nice list of potential discussions and others have as
well. My meta-question is when do we want to switch to tickets for this
process? I don't want to smother discussion in process, but I find it very
hard to follow a multithreaded discussion over email and I much prefer
breaking things out early to more specifics.


Splitting the lists will make it easier. I think we switch to tickets 
when there specific activities.  When sorting what the activities are, 
there is benefit in using dev@ so we can see the interactions more 
clearly. With a quieter dev@, sensible [] should mean anyone can see the 
overall activity.  We can change this if it does not work out.


List proposal:

2 new lists: issues@ (for JIRA) and pr@ (for github traffic).

Reply-to on JIRA becomes a comment (which I think it does at the moment 
- the reply is j...@apache.org)


For pr@, reply-to is dev@ (same as commits@) - PR discussion is done on 
GH so the usual GH controls work for people.  pr@ is more of a safe archive.


Using the same names as other projects helps infrequent visitors to 
navigate our lists. "issues" is a common name; there isn't a common name 
for the "pr" that I found - and it's not that common to split out GH. 
(Cassandra have pr@).


If anyone wants to combine issues@and pr@ they can do so with their own 
mail filtering rules.


Routing:

JIRA:

There are bunch of events:

Issue Created   
Issue Updated   
Issue Assigned  
Issue Resolved  
Issue Closed
Issue Commented 
Issue Comment Edited
Issue Comment Deleted   
Issue Reopened  
Issue Deleted   
Issue Moved

These are all:

All Watchers
Current Assignee
Reporter
Single Email Address (dev@jena.apache.org)

I suggest that all go to issues@ and, in addition, "Created" goes to dev@

I think PRs are linked to JIRA by the title JENA-. We don't need pr 
discussion on JIRA if we have pr@ but it probably isn't a big deal 
because either it's a PR discussion or JIRA discussion, rarely both.


(but please keep the "^JENA-:" on PRs)

Github: I don't know what's possible.

My ideal is all PR traffic to pr@, and like JIRA, any created PRs 
notices go to dev@.


(There aren't a GH issues for the Apache mirrored projects)

Andy

On 02/06/2019 13:57, ajs6f wrote:

I like the idea of breaking PR discussions off, but if we're going to continue 
to copy PR comments onto Jira tickets it only makes sense if we have separate 
pr@ and issue@ lists. Also, we would have to stop copying them onto dev@ (which 
I would be fine with).

Ideally, I would like to see ticket _creation_ cc:ed onto dev@, so that any 
interested parties would be aware without having to set up notifications in 
Jira, but other ticket actions not cc:ed. I'm not sure if that's possible with 
our gear, but I'm sure INFRA can tell us.

ajs6f


On May 30, 2019, at 10:42 AM, Andy Seaborne  wrote:

The dev@ list can be dominated by github discussions.

We have feeds from github PRs and JIRA. We could split the list in one list per 
feed to leave the dev@ list for people.

While you can do this with mail client rules, searching using the archives 
isn't easy.

Suggestion:
Add email lists for:

pr@ -- github pull request discussions.
issues@ -- JIRA

I'm not sure how clever we can be - for example, it would be nice for dev@ to 
get an email for the submission of a pull request, then not the discussion, but 
I don't think that is configurable. (It is all INFRa consifuration anyway 
AFAIK).

These names are the ones I have seen other projects use.

Thoughts?
What have you seen work for other projects?

Andy