Sorry, I have a slight correction on my response. I meant to write: '"OPT-IN" makes so much more sense here.' Sorry for any confusion.
On Tue, Jul 6, 2021 at 10:45 AM Christopher <ctubb...@apache.org> wrote: > > To respond to your questions: > > On Tue, Jul 6, 2021 at 10:06 AM Rich Bowen <rbo...@rcbowen.com> wrote: > > > > May I be the contrary voice and ask why? > > I put two points of justification in the PR, but to repeat here: > > 1. These automated notices are redundant if somebody is already watching > the relevant notices for the repo on GitHub. So, sending these to > another list allows users more flexibility in receiving them or not, > and whether they prefer to receive them as an email or as a notice > directly from watching the repo in GitHub. > 2. These automated notices spam the dev@ list which many more people > follow for the human discussions here on community development across > the ASF. Sending them to another list ensures the dev@ list is > reserved for human-to-human conversations, and keeps people from > unsubscribing and connected to the community due to frustration with > spam. > > > Why do we not want to know what's being committed in our name? > > I don't understand this question. This doesn't prevent anybody from > watching any of the activity. It just gives more flexibility on how > they are able to follow it, removing redundant notifications for > people following the repos on GitHub, and providing a mechanism that > is equivalent to today if people prefer to follow a mailing list. > > > It's not like this list gets a lot of traffic, > > True, but that's probably why there are as many subscribers as there > are. The quantity is low, but the quality is very high. With the > automated emails landing here, the quality is lowered, and the > quantity is increased. The degree to which this has happened may be in > question, but the fact that automated emails are of lower quality than > human-written emails shouldn't be in question. These make it more > likely people will unsubscribe, as more activity on the list is less > relevant to their participation. > > > and those very emails that you want to banish to another > > list were what reminded me that we have PRs that have been languishing > > for several months. > > "Banish" seems harsh. I would characterize it as "organize". I don't > think email activity is the cause of languishing PRs. By organizing > these on a separate list, all options you had before to watch for > these and react to them will still be available to you. You can still > watch notifications on GitHub directly, or follow the other list. But, > it lowers the bar for other people (especially non-committers who > follow the list) to organize the lists they follow. > > > > > Granted, if this is enacted, I'll just filter that email to the same > > folder, but I don't think that this solves a real problem, and, indeed, > > that it will further reduce engagement. > > I don't think it has an impact on engagement, because no notifications > are being removed. Only organized. Keep in mind that many people > following ComDev are not committers, and follow this list for the > discussions of community development at the ASF, and *not* for > maintaining ComDev's website or other code (if there is any). > > And, because I know somebody will raise this point: email can be > filtered both ways. However, I think it's easier for committers to > follow two lists (assuming they prefer the email notifications rather > than the notifications in GitHub's UI in the first place), than it is > for casual followers interested in ComDev discussions on this list to > set up email filters to suppress the notifications. I'd prefer to > cater to the casual followers, to lower the bar to contributing. > > Furthermore, I also follow the INFRA list, and this GitBox spam seems > to be a frequent source of frustration for many casual contributors > since projects were moved to GitBox from the old git-wip, many > submitting requests for INFRA to help them "unsubscribe" from it, and > many uncertain how they are getting it in the first place. Yet, I > never see any complaints that users have to subscribe to a second list > to get jira@, issues@, or notifications@ messages in their projects. > So, I think it makes sense to put these notifications in a separate > list, making them "OPT-IN", rather than "OPT-OUT". > > Also, remember, even for users who *want* to follow this activity, > they don't necessarily want these messages, because many are already > following the activity on GitHub. "OPT-OUT" makes so much more sense > here. > > > > > > On 7/6/21 9:26 AM, Christopher wrote: > > > Hi ComDev, > > > > > > I'm probably not the only one who has noticed the flurry of emails on > > > the main dev@community.apache.org due to GitHub activity on the > > > comdev-site repo. > > > > > > To help deal with that, I created a pull request: > > > https://github.com/apache/comdev-site/pull/64 > > > For more information, see > > > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#Git.asf.yamlfeatures-Notificationsettingsforrepositories > > > > > > The PMC must create a new notificati...@community.apache.org list for > > > this change, if they decide to accept my proposed change. > > > > > > Thanks! > > > > > > - Christopher > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > -- > > Rich Bowen - rbo...@rcbowen.com > > @rbowen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
