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 <a...@apache.org> 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-NNNN. 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-NNNN:" 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 <a...@apache.org> 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 > >> > > >
