Hi all, So, I’ve tracked down the requirement to the test, that requires the “repository” variable, But it doesn’t really explain why it’s required. I was told that it’s for some 20 year old reason, however that simply can’t apply to the custom email templates for GitHub ;-)
So, I opened a discussion thread https://lists.apache.org/thread/wz6f71wovzsz0nk6bdpgs8m17f07o2ko Feel free to add your comments to it. Chris Von: Christofer Dutz <christofer.d...@c-ware.de> Datum: Dienstag, 11. Juli 2023 um 16:29 An: dev@community.apache.org <dev@community.apache.org> Betreff: AW: Changing the defaults for GitHub generated email titles? I have absolutely no idea … just whenever you leave it away the system starts yelling at you, telling you that it’s required ;-) If the computer says so … I gotta obey ;-) Von: Kelly Oglesbee <humbleoppurtun...@gmail.com> Datum: Dienstag, 11. Juli 2023 um 15:00 An: dev@community.apache.org <dev@community.apache.org> Betreff: Re: Changing the defaults for GitHub generated email titles? Why id this necessary? On Tue, Jul 11, 2023, 8:56 AM Christofer Dutz <christofer.d...@c-ware.de> wrote: > Hi Phil, > > Well, you can somewhat reduce it to whatever you like … however there > seems to be one limitation, which I can’t quite explain. > For some reason you need to have the repository name as part of the > subject line. That’s why I added it to the end as there it didn’t interrupt > my speed-reading and didn’t show up on my phone. > > And yeah … I agree that I also prefer the super-minimal prefixes [PR] for > Pull-Requests [I] for Issues and [D] for Discussions. > I think it takes me something round half a second to know that it’s a PR, > Issue or Discussion. > Generally, I could even live without them all together as it doesn’t > really matter, if a discussion is about a PR, Issue or just a > general-purpose discussion. > In an all-email workflow, we never had these prefixes before … everything > was just a discussion. > But if you ask me .. I’d keep the minimal prefixes, but be in favor of the > smaller ones above [PULL-REQUEST], [ISSUE] and [DISCUSSION] … > well … I guess that was why I chose these defaults for the projects I > could change it ;-) > > Chris > > > Von: Phil Steitz <phil.ste...@gmail.com> > Datum: Mittwoch, 5. Juli 2023 um 20:57 > An: dev@community.apache.org <dev@community.apache.org> > Betreff: Re: Changing the defaults for GitHub generated email titles? > +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 > > > > >
