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 <g...@apache.org>".
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
