+1 from another Commons contributor drowning in the flood of cruft on commons-dev. Shorter subject lines would be great. I don't know if the tooling would support or can be customized for Commons, but one thing that would help would be to uniformly drop the word "Commons", so we go back to what we did when we actually used the dev list for discussion [Commons-Foo] is just [Foo]. There is also no value in the [GitHub] prefix in the messages from there. All PRs come from there. Probably should talk about this on Commons-dev (maybe with some special decorations on the subject line so people will see it amidst all of the bot stuff :)
Phil On Mon, Jul 3, 2023 at 5:48 AM Gary Gregory <garydgreg...@gmail.com> wrote: > Thanks for sharing these links; what a great start :-) > > I'm pretty sure the Commons community will welcome these kinds of > changes where a complaint has been the "flood" of emails from GitHub, > so hopefully this will help. > > For my money though, I'd prefer much shorter subject prefixes, even to > the extreme, I'll just learn the codes, otherwise, it's impossible to > read on my phone, which would be counterproductive (for me). > > For example, [BUILD-FAILURE] -> [BUILD-FAIL] -> [BUILD-F] -> [B-F], > just something much shorter, again, think phone. B means Build, F > means Fail, that kinda mapping. I'm not sure where the mapping would > be best documented, perhaps on each project's mailing list page. > > Gary > > On Mon, Jul 3, 2023 at 8:12 AM Christofer Dutz > <christofer.d...@c-ware.de> wrote: > > > > Hi all, > > > > So here’s an example of one week’s email traffic on one project before > and after the config changes: > > > > (Sorry for putting the Spotlight on you streampipes folks, but this is > the best positive example I know) > > > > Before the change: > > > https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15 > > Here you can see, that: > > a) It’s hard to see what something is about as the prefix is very large > > b) The only grouping happening is the same person doing the same thing > on one issue (commenting on an issue for example) > > > > Also, one week on the same list, with updated settings: > > > https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-6-12|dto=2023-6-18 > : > > Here you can see: > > a) Greatly reduced number of threads > > b) Threads are grouped together > > c) You can actually follow a thread > > (The reason so many threads start with “RE:” is that the initial post > seems to be outside of the date-range of that week and the reason for one > or two long discussion titles, was they changed the config on 16.06.2023) > > > > Hope this brings a bit more context for some. > > > > Chris > > > > > > > > Von: Shane Curcuru <a...@shanecurcuru.org> > > Datum: Freitag, 30. Juni 2023 um 23:20 > > An: dev@community.apache.org <dev@community.apache.org> > > Betreff: Re: Changing the defaults for GitHub generated email titles? > > Christofer Dutz wrote on 6/30/23 3:49 AM: > > ...snip... > > > So in general, I would like to change the defaults used by the GitHub > tooling to the ones I proposed in > https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent > . Quite a number of projects have adopted these settings: > > > Like StreamPipes: > https://lists.apache.org/list?d...@streampipes.apache.org:lte=4M > > > > +1 to giving this several more days of review and refinement, and then > > holding a vote to make this a ComDev PMC recommendation of best practice > > and then working (separately) on how to announce and make any changes. > > > > A couple of things I'd love to see: > > > > - A clear example of a before and after within a single project. Come > > up with a specific Ponymail date search URL that shows one week of > > old-style notifications on a dev@ list, and then a second URL that shows > > a week of new-style notifications from the same dev@ list. Directly > > seeing that difference would really help cement "yes, let's do it!" > > > > - Changing Chris' description page above to clearly show the best > > practice first, and then talk about how to find options for projects > > that want to customize. The page as written now is good at helping > > convince someone new that 1) this is an easy change, and 2) this is a > > good idea. > > > > When we work on communications to PMCs, we need a "How-To setup best > > practices for GH notifications" guide that focuses on the *why* > > "Inclusion and transparency", and then the *steps to do/configure* which > > would be brief description of asfyaml stuff, and start with the best > > practice configuration, explaining what it does. > > > > After that in the doc, include the original GH notifications and other > > pointers to technical reference. > > > > Thinking ahead, I'd be happy voting to send out PMCs email saying "the > > default notifications are going to change on date X; email here to > > opt-out". Keep track of opt-outs, and then change defaults for all. > > > > -- > > - Shane > > ComDev PMC > > The Apache Software Foundation > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
