Personally I am comfortable with the way how things are now because mail filters appear to work well for me.
However this thread made me curious about whether ASF has some guidance or recommendations on that matter. I searched quite a bit and found none of that kind. It looks like Apache leaves it at discretion of the project community to decide whether to make separate list for automated messages or not (which made a fairly good sense after I gave it a bit more thought, see below). --- After that I decided to check how other Apache projects manage their mailing lists and as far as I can tell most active ones tend to have separate mailing lists for automatic notifications from version control and / or issue tracker. I checked few top projects by number of committers from the list here: https://projects.apache.org/projects.html?number - specifically top 8 that had over 80 committers (for comparison, this list currently says Ignite has 38, I think we're fairly close to that league). - https://hadoop.apache.org/mailing_lists.html https://openoffice.apache.org/mailing-lists.html http://cloudstack.apache.org/mailing-lists.html http://ambari.apache.org/mail-lists.html ---> Separate lists for commits and for issue tracker. - http://geode.apache.org/community/#mailing-lists https://cordova.apache.org/contact/ http://subversion.apache.org/mailing-lists.html http://hive.apache.org/mailing_lists.html ---> Separate list for commits. For the sake of completeness I also sampled 4 projects having 38 committers, just like Ignite. - http://chemistry.apache.org/project/community.html ---> No lists for commits nor issues. - http://ctakes.apache.org/mailing.html ---> Separate list for commits. - http://metron.apache.org/community/ ---> Separate list for issues. - https://orc.apache.org/develop/ ---> Separate lists for commits and for issue tracker. --- Based on my personal experience this issue looks to some extent a matter of whether we consider some barrier for entry to dev list desirable or not. I could not actively use list until I learned how to setup mail filters because it was difficult to find discussions to participate. On the other hand, after setting these filters it turned out very easy. So the question is, do we want to have dev list easier or harder to use for "passers by" who aren't deeply involved in project. If we want to keep it strictly at top experience level, then we better keep all automated messages in. If we want it welcoming for any random passer by, then we better move all automated messages somewhere else. And there are of course intermediate approaches, we can basically tune ease of entry by picking which part of automated messages will stay and which will go away. --- Another important thing I learned when studying mailing lists of other projects is we better take into account that regular automated messages may help in keeping dev list "lively" in the slow times, when there are little to none discussions. At first I was tempted to propose moving all the automated messages outside - "just like big boys do" - note how top 4 projects in my list all have commits and issues in separate lists. But looking how smaller projects tend to handle it differently made me wonder if maybe it is a bit more complicated, maybe there is some difference worth considering. And as far as I can tell, the important difference is size of community / amount of committers. When there are lots of people actively involved in the project it is very likely that they can permanently maintain dev list active by natural discussions. But when the project is smaller, there is a substantial risk that sometimes most active developers are focused on issue tracker or github which means dev list may look abandoned (if it contains only discussions). If there is such a risk then keeping some (not necessarily all) automated messages in dev list will help its subscribers and visitors avoid misleading impression of "abandoned empty place" by showing that the project is indeed actively maintained. regards, Oleg -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/