You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Christopher <ct...@apache.org> on 2021/07/06 13:26:30 UTC
Please redirect automated GitBox emails to different list
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 notifications@community.apache.org list for
this change, if they decide to accept my proposed change.
Thanks!
- Christopher
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Please redirect automated GitBox emails to different list
Posted by Rich Bowen <rb...@rcbowen.com>.
Fair. Count me as -0. Thanks for your detailed answers.
On 7/6/21 10:45 AM, Christopher wrote:
> To respond to your questions:
>
> On Tue, Jul 6, 2021 at 10:06 AM Rich Bowen <rb...@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 notifications@community.apache.org list for
>>> this change, if they decide to accept my proposed change.
>>>
>>> Thanks!
>>>
>>> - Christopher
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>>> For additional commands, e-mail: dev-help@community.apache.org
>>>
>>
>> --
>> Rich Bowen - rbowen@rcbowen.com
>> @rbowen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
--
Rich Bowen - rbowen@rcbowen.com
@rbowen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Please redirect automated GitBox emails to different list
Posted by Christopher <ct...@apache.org>.
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 <ct...@apache.org> wrote:
>
> To respond to your questions:
>
> On Tue, Jul 6, 2021 at 10:06 AM Rich Bowen <rb...@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 notifications@community.apache.org list for
> > > this change, if they decide to accept my proposed change.
> > >
> > > Thanks!
> > >
> > > - Christopher
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
> > >
> >
> > --
> > Rich Bowen - rbowen@rcbowen.com
> > @rbowen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Please redirect automated GitBox emails to different list
Posted by Christopher <ct...@apache.org>.
To respond to your questions:
On Tue, Jul 6, 2021 at 10:06 AM Rich Bowen <rb...@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 notifications@community.apache.org list for
> > this change, if they decide to accept my proposed change.
> >
> > Thanks!
> >
> > - Christopher
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
>
> --
> Rich Bowen - rbowen@rcbowen.com
> @rbowen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Please redirect automated GitBox emails to different list
Posted by Christopher <ct...@apache.org>.
On Tue, Jul 6, 2021 at 1:10 PM Dave Fisher <wa...@apache.org> wrote:
[SNIP]
> Tell me why a split discussion is good for the community?
I feel like I didn't do a good enough job of responding to this point,
so to clarify further:
My answer is that it's *not*. However, that problem already exists
with any issue tracker. Discussions happen on JIRA today, as well as
on GitHub pull requests, or ReviewBoard, or Slack. We can moderate the
notifications list to prevent additional discussions from occurring
there, so this wouldn't create a new forum for discussions to be split
across. That's a misunderstanding of what I'm proposing.
The purpose of this change isn't to split up discussions further.
Rather, it's intent is to make it easier to *find* discussions to
participate in. One way it does this is by removing redundant spammy
notifications if users are already being notified by GitHub directly
because they have subscribed to the repo there. Reducing this spam on
the dev@ list makes finding the remaining discussions on the list
easier, because there's less noise to wade through. It also makes it
easier to find discussions happening on GitHub, even if you aren't
subscribed, because if you choose to subscribe to the second list to
receive notifications that way, filtering your mail in your email
client is much more reliably done with a "list-id:" header that is
unique for each mailing list than it is with only pattern-matching on
a "subject:" line.
I hope that helps clarify the intent here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Please redirect automated GitBox emails to different list
Posted by Dave Fisher <wa...@apache.org>.
I have rather hard as a mentor in the Incubator now that all new projects use GitHub. Much development discussion is driven away from dev@project mailing lists and occurs in issues(if enabled) and PRs.
comdev-site: https://github.com/apache/comdev-site/blob/master/.asf.yaml
notifications:
commits: commits@community.apache.org
issues: dev@community.apache.org
pullrequests: dev@community.apache.org
One - issues have not been enabled so that setting is meaningless to comdev-site.
Why add notifications@ when commits@ exists?
.asf.yaml allows:
# Send new/closed PR notifications to dev@
pullrequests_status: dev@foo.apache.org
# Send individual PR comments/reviews to issues@
pullrequests_comment: issues@foo.apache.org
So PRs could be split, but we are already having a split discussion of https://github.com/apache/comdev-site/pull/64
Tell me why a split discussion is good for the community?
All The Best,
Dave
> On Jul 6, 2021, at 9:37 AM, Brian Thompson <br...@hashvault.io> wrote:
>
> I don't think asking for a new mailing list for GitHub notifications is
> unreasonable. In fact, I would go as far to say that having a GitHub
> notifications mailing list makes more sense than having those
> notifications being sent to the "dev" mailing list. Shouldn't the dev
> mailing list be used for discussion about the development rather than
> individual PRs? Those discussions can still be had on the other
> mailining list, if so desired.
>
> --
> Best regards,
>
> Brian T
> B.S. Computer Science 2014 (Truman State University)
> Minor Stasitics
> Minor Chemistry
> Minor Mathematics
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Please redirect automated GitBox emails to different list
Posted by sebb <se...@gmail.com>.
Does it really make sense to use the same list for development
discussions amongst the ComDev community, and discussions with the
general public?
At present this single list is acting as both developer and user list.
[Many projects would also have commits, issues and notifications lists]
It may not be an issue for the ComDev community to disentangle the
emails, but it must be confusing for the general public trying to find
answers to their questions on how the ASF works.
It also means that the mail archives are less useful for people trying
to see how the ASF community works rather than how ComDev itself
functions.
It has always seemed strange to me that discussions on ComDev tools
are mixed in with questions from someone on how to get started with
the ASF.
Sebb.
On Tue, 6 Jul 2021 at 22:01, Brian Thompson <br...@hashvault.io> wrote:
>
> On Tue, Jul 06, 2021 at 01:16:19PM -0400, Joe Brockmeier wrote:
> >First, I feel like I have to respond given the Truman State University sig.
> >It's rare I run into other Truman grads in the wild, though we wouldn't
> >have crossed paths on campus... (1998 grad here...)
>
> Wow, this is a first for me, too. Glad to see some fellow Truman grads
> in technology.
>
> >If the PRs appear here on this list, it makes it slightly easier to have a
> >discussion on list about the PRs. It also doesn't require people to go
> >upstream to subscribe to github or a second list.
> >
> >I wouldn't go so far as to say it's "unreasonable" to have a second list, I
> >just am not convinced it's desirable.
> >
> >As to the suggestion to discussing the PRs on the other list - then we have
> >to ask people to subscribe to both or miss some of the conversations about
> >the site development. Creating a filter for the GitBox notices +
> >subscribing to a new list are both about the same amount of work. If you
> >filter by sender or something like that you still can see discussions here
> >if anybody decides to go deeper on a specific commit. If you have to track
> >both lists, then that means a subset of the community is not going to see
> >those discussions either. (Either by omission or they just filter
> >everything and then see something six months later... ask me how I know...)
>
> That is true. I guess I am just used to having more mailing lists
> (I am mostly active on the Debian mailing lists) to choose from so that
> the mailing lists themselves act as filters.
>
> It's not a big deal to me either way; having a new mailing list or
> keeping it consolidated. Whatever the community decides I will go along
> with. It's not a battle I will choose to fight.
>
> --
> Best regards,
>
> Brian T
> B.S. Computer Science 2014 (Truman State University)
> Minor Stasitics
> Minor Chemistry
> Minor Mathematics
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Please redirect automated GitBox emails to different list
Posted by Brian Thompson <br...@hashvault.io>.
On Tue, Jul 06, 2021 at 01:16:19PM -0400, Joe Brockmeier wrote:
>First, I feel like I have to respond given the Truman State University sig.
>It's rare I run into other Truman grads in the wild, though we wouldn't
>have crossed paths on campus... (1998 grad here...)
Wow, this is a first for me, too. Glad to see some fellow Truman grads
in technology.
>If the PRs appear here on this list, it makes it slightly easier to have a
>discussion on list about the PRs. It also doesn't require people to go
>upstream to subscribe to github or a second list.
>
>I wouldn't go so far as to say it's "unreasonable" to have a second list, I
>just am not convinced it's desirable.
>
>As to the suggestion to discussing the PRs on the other list - then we have
>to ask people to subscribe to both or miss some of the conversations about
>the site development. Creating a filter for the GitBox notices +
>subscribing to a new list are both about the same amount of work. If you
>filter by sender or something like that you still can see discussions here
>if anybody decides to go deeper on a specific commit. If you have to track
>both lists, then that means a subset of the community is not going to see
>those discussions either. (Either by omission or they just filter
>everything and then see something six months later... ask me how I know...)
That is true. I guess I am just used to having more mailing lists
(I am mostly active on the Debian mailing lists) to choose from so that
the mailing lists themselves act as filters.
It's not a big deal to me either way; having a new mailing list or
keeping it consolidated. Whatever the community decides I will go along
with. It's not a battle I will choose to fight.
--
Best regards,
Brian T
B.S. Computer Science 2014 (Truman State University)
Minor Stasitics
Minor Chemistry
Minor Mathematics
Re: Please redirect automated GitBox emails to different list
Posted by Christopher <ct...@apache.org>.
Great discussion, everybody! Here's some thoughts in response to some
of the questions/concerns raised:
People should *not* have to subscribe to the other list in order to
participate in discussions. It should just be for automated notices.
The best practice is, like commits@, have it moderated and
automatically reject anything not from "apache.org" to virtually
eliminate any moderation effort. If you need to discuss, the best
practice is to reply to it on the dev@ list to start a new discussion
thread there.
The reason not to use commits@ directly is because it's nice to have
actual commit activity, for archival purposes, in its own dedicated
list. Many projects have a jira@, notifications@, or issues@ list for
automated notices from their issue tracker. That's all I'm suggesting
here.
I noticed that COMDEV JIRA notifications are also going to dev@. If
you want to use the same notifications@ list for the COMDEV JIRA, I'd
be in favor of that as well, but that's a separate issue that I wasn't
intending to raise here. It has its own pros and cons. To configure
that, it's not done in .asf.yaml, it's done at
https://issues.apache.org/jira/plugins/servlet/project-config/COMDEV/notifications
or by submitting a JIRA ticket to INFRA. Therefore, it's outside the
scope of my PR to address the GitHub notifications.
I also understand the concern raised about the difficulty of having
discussions on dev@ because of GitHub's ease-of-use. However, I don't
think forcing redundant notifications on GitHub users is the right
solution, as it will discourage GitHub users from participating in the
mailing lists... which is the opposite of what you want. The reason
for GitHub users to participate in the mailing lists will be because
they get value out of the mailing lists other than what they get from
using GitHub directly.
As for the comment regarding whether or not a destination should be
set for `issues:`, GitHub considers pull requests to be a type of
issue, so its important to set this value, even if you have issues
disabled on GitHub, because (I believe) commenting on a pull request
triggers the same notification as commenting on an issue. I believe
`pullrequests:` is triggered for newly created PRs, but `issues:` is
still used for notifications of any comments or code reviews on a pull
request, as though it were any other issue.
On Tue, Jul 6, 2021 at 1:16 PM Joe Brockmeier <jz...@apache.org> wrote:
>
> First, I feel like I have to respond given the Truman State University sig.
> It's rare I run into other Truman grads in the wild, though we wouldn't
> have crossed paths on campus... (1998 grad here...)
>
> If the PRs appear here on this list, it makes it slightly easier to have a
> discussion on list about the PRs. It also doesn't require people to go
> upstream to subscribe to github or a second list.
>
> I wouldn't go so far as to say it's "unreasonable" to have a second list, I
> just am not convinced it's desirable.
>
> As to the suggestion to discussing the PRs on the other list - then we have
> to ask people to subscribe to both or miss some of the conversations about
> the site development. Creating a filter for the GitBox notices +
> subscribing to a new list are both about the same amount of work. If you
> filter by sender or something like that you still can see discussions here
> if anybody decides to go deeper on a specific commit. If you have to track
> both lists, then that means a subset of the community is not going to see
> those discussions either. (Either by omission or they just filter
> everything and then see something six months later... ask me how I know...)
>
> Best,
>
> jzb
>
> On Tue, Jul 6, 2021 at 12:37 PM Brian Thompson <br...@hashvault.io> wrote:
>
> > I don't think asking for a new mailing list for GitHub notifications is
> > unreasonable. In fact, I would go as far to say that having a GitHub
> > notifications mailing list makes more sense than having those
> > notifications being sent to the "dev" mailing list. Shouldn't the dev
> > mailing list be used for discussion about the development rather than
> > individual PRs? Those discussions can still be had on the other
> > mailining list, if so desired.
> >
> > --
> > Best regards,
> >
> > Brian T
> > B.S. Computer Science 2014 (Truman State University)
> > Minor Stasitics
> > Minor Chemistry
> > Minor Mathematics
> >
>
>
> --
> Joe Brockmeier
> Vice President Marketing & Publicity
> jzb@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Please redirect automated GitBox emails to different list
Posted by Joe Brockmeier <jz...@apache.org>.
First, I feel like I have to respond given the Truman State University sig.
It's rare I run into other Truman grads in the wild, though we wouldn't
have crossed paths on campus... (1998 grad here...)
If the PRs appear here on this list, it makes it slightly easier to have a
discussion on list about the PRs. It also doesn't require people to go
upstream to subscribe to github or a second list.
I wouldn't go so far as to say it's "unreasonable" to have a second list, I
just am not convinced it's desirable.
As to the suggestion to discussing the PRs on the other list - then we have
to ask people to subscribe to both or miss some of the conversations about
the site development. Creating a filter for the GitBox notices +
subscribing to a new list are both about the same amount of work. If you
filter by sender or something like that you still can see discussions here
if anybody decides to go deeper on a specific commit. If you have to track
both lists, then that means a subset of the community is not going to see
those discussions either. (Either by omission or they just filter
everything and then see something six months later... ask me how I know...)
Best,
jzb
On Tue, Jul 6, 2021 at 12:37 PM Brian Thompson <br...@hashvault.io> wrote:
> I don't think asking for a new mailing list for GitHub notifications is
> unreasonable. In fact, I would go as far to say that having a GitHub
> notifications mailing list makes more sense than having those
> notifications being sent to the "dev" mailing list. Shouldn't the dev
> mailing list be used for discussion about the development rather than
> individual PRs? Those discussions can still be had on the other
> mailining list, if so desired.
>
> --
> Best regards,
>
> Brian T
> B.S. Computer Science 2014 (Truman State University)
> Minor Stasitics
> Minor Chemistry
> Minor Mathematics
>
--
Joe Brockmeier
Vice President Marketing & Publicity
jzb@apache.org
Re: Please redirect automated GitBox emails to different list
Posted by Brian Thompson <br...@hashvault.io>.
I don't think asking for a new mailing list for GitHub notifications is
unreasonable. In fact, I would go as far to say that having a GitHub
notifications mailing list makes more sense than having those
notifications being sent to the "dev" mailing list. Shouldn't the dev
mailing list be used for discussion about the development rather than
individual PRs? Those discussions can still be had on the other
mailining list, if so desired.
--
Best regards,
Brian T
B.S. Computer Science 2014 (Truman State University)
Minor Stasitics
Minor Chemistry
Minor Mathematics
Re: Please redirect automated GitBox emails to different list
Posted by Joe Brockmeier <jz...@apache.org>.
If I had a dollar for every time I've been on a list with this discussion
or a variant thereof... I wouldn't be rich, but I could probably buy myself
a really spiffy NVME drive or something.
FWIW I think the better approach is to filter rather than shunt the commits
to a different list. I don't feel super-strongly about this, but commits to
the site _are_ part of human discussions, IMO. It gives people an
opportunity to see what is being added to the site whereas not all of those
commits are going to be discussed in depth on the list.
We are all, presumably, capable of creating filters for something like this
if we don't want to see the content in our inbox.
Best,
jzb
On Tue, Jul 6, 2021 at 10:06 AM Rich Bowen <rb...@rcbowen.com> wrote:
> May I be the contrary voice and ask why? Why do we not want to know
> what's being committed in our name? It's not like this list gets a lot
> of traffic, 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.
>
> 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.
>
> 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 notifications@community.apache.org list for
> > this change, if they decide to accept my proposed change.
> >
> > Thanks!
> >
> > - Christopher
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
>
> --
> Rich Bowen - rbowen@rcbowen.com
> @rbowen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
--
Joe Brockmeier
Vice President Marketing & Publicity
jzb@apache.org
Re: Please redirect automated GitBox emails to different list
Posted by Rich Bowen <rb...@rcbowen.com>.
May I be the contrary voice and ask why? Why do we not want to know
what's being committed in our name? It's not like this list gets a lot
of traffic, 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.
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.
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 notifications@community.apache.org list for
> this change, if they decide to accept my proposed change.
>
> Thanks!
>
> - Christopher
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
--
Rich Bowen - rbowen@rcbowen.com
@rbowen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org