On 16 January 2015 at 11:13, Gilles <gil...@harfang.homelinux.org> wrote: > On Fri, 16 Jan 2015 08:53:56 +0100, Benedikt Ritter wrote: >> >> Hi Gilles, >> >> 2015-01-16 1:47 GMT+01:00 Gilles <gil...@harfang.homelinux.org>: >> >>> Hi. >>> >>> In the discussion that started about RDF, it seems that the >>> traffic volume is a stumbling block. >>> [For some time now, it has been a growing nuisance, and the >>> usual dismissal about filters won't change the fact: Setting >>> up a filter that will redirect stuff to /dev/null is a waste >>> of bandwidth.] >>> >>> If different ML are created, people interested in everything >>> can subscribe _once_, and nothing will change for them. >>> For people who spend a lot of time just deleting dozens messages >>> and notifications a day, it will be a relief. >>> >>> Maintaining community conversation is not a problem: just >>> create an "all-...@commons.apache.org" ML for things that >>> need input form a larger audience (like votes). >>> >> >> Personally I don't care. I have filters set up and if we would do the >> much, >> I'd simply subscribe to all MLs. >> I agree that it seems to be a problem for some that the ML has so much >> traffic. So we should think about this. >> >> There are two questions for me: >> >> - What about commits@ and issues@? Do we simply route commits and issues >> to >> the component MLs or do we want to have separate commit MLs on a per >> component basis? > > > A developer who is active on some component would presumably want to > see commit activity. > Conversely, commit reports on code that one does not touch or read are > not interesting by default.
However PMC members would have to subscribe to every single list, as the PMC must have oversight of them. I don't think that is viable if there are separate lists for each component. If we are trying to make it easier for new-comers, then yes, trimming down the dev list might help. But the way to do that is to ensure that automated mails such as CI builds are moved to one of the other lists. >> - How do we want to manage the transition? I think the process we choose >> for the git migration is a good one. If a component decides it needs a >> separate ML, they can simply request one. All other components simply stay >> on dev@ For example I don't see much value in creating a >> primit...@comons.apache.org ML, simply because there is so low activity >> right now. > > > Suppose that someone is interested in some component that is not on > a separate ML, he will still get all the traffic... > People who want the traffic can subscribe to everything. [It would even > be OK to be automatically subscribed to every new list, and people would > need to explicitly unsubscribe...] > > > Regards, > Gilles > > >> >> Regards, >> Benedikt > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
