I personally think if it is super easy to change back, I see no problem with making the change. "Ask for forgiveness not for permission".
It already happened in the past that someone in the past "forced" the projects to use previous defaults by the fact of defining it. What was the process when it was decided then and how the projects were participating in this decision then? Sure, change is painful, but if in our process we do not allow for a change we are stuck with sometimes bad decisions made in the past. And the only way to change those decisions is well, to change them. There were recent precedents where changes were forced on the projects. Example was the need to "approve" every Github workflow of every external contributor - so it's not that we've never done that. And (contrary to that change) it was not as easy to go back. It requires finding a somewhat hidden policy, opening a JIRA and waiting for approval of INFRA. In this case it's as easy as making a single commit with an update to .asf.yml. J. On Fri, Aug 4, 2023 at 11:29 AM sebb <seb...@gmail.com> wrote: > > This was not a fair poll - it was not open long enough. > Also it is not representative; participation on this list is not > required of projects. > And people participating in the discussion are likely to be in favour. > > I don't think Comdev should be making decisions on behalf of other projects. > > Note: I am not against alllowing projects to change, but it should not > be forced upon them. > > On Thu, 3 Aug 2023 at 15:56, Christofer Dutz <christofer.d...@c-ware.de> > wrote: > > > > Hi all, > > > > as there seems to be general consent on this, I have taken the liberty to > > prepare the PRs for this: > > https://github.com/apache/infrastructure-github-event-notifier/pull/12 > > https://github.com/apache/infrastructure-github-discussions-notifier/pull/2 > > However, have I marked them as DRAFT so they aren’t executed today. > > > > I think it would make sense to send out an email first, notifying projects > > about the coming changes and to define a date to which the changes will be > > applied. > > > > I’d be happy to prepare the email and send it out (once the 72h for this > > POLL are over). > > > > Chris > > > > Von: Christofer Dutz <christofer.d...@c-ware.de> > > Datum: Mittwoch, 2. August 2023 um 09:47 > > An: Volkan Yazıcı <vol...@yazi.ci> > > Betreff: AW: [POLL] Should we ask Infra to change the defaults used to > > generate GitHub integration email subjecs? > > Still giving this a bit more time (72 hours in total) as we usually do > > things. > > But yeah … I guess as soon as that time is over, I’ll create an infra > > ticket. > > > > Chris > > > > > > Von: Volkan Yazıcı <vol...@yazi.ci> > > Datum: Mittwoch, 2. August 2023 um 09:39 > > An: Christofer Dutz <christofer.d...@c-ware.de> > > Betreff: Re: [POLL] Should we ask Infra to change the defaults used to > > generate GitHub integration email subjecs? > > Check. Is there (or will there be) an INFRA ticket that I can follow the > > implementation progress? > > > > On Wed, Aug 2, 2023 at 9:28 AM Christofer Dutz > > <christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>> wrote: > > Hi Volkan, > > > > well I won’t be doing anything … also is this not really a vote (as we > > didn’t know if this is something we actually are allowed or able to vote > > on). > > So my plan is to show this thread to Infra to show that there’s general > > support for the proposal. > > > > I really hope they won’t let me jump another hoop, asking me to bring this > > to a vote on Members@. > > > > But sure I think this is worth sending out to committers@ or similar list, > > which will make a wide range of people be informed. > > > > Chris > > > > > > Von: Volkan Yazıcı <vol...@yazi.ci<mailto:vol...@yazi.ci>> > > Datum: Mittwoch, 2. August 2023 um 09:22 > > An: Christofer Dutz > > <christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>> > > Betreff: Re: [POLL] Should we ask Infra to change the defaults used to > > generate GitHub integration email subjecs? > > [PM'ing to avoid derailing the vote thread.] > > > > Christofer, in the email where you will announce the result, would you mind > > also sharing when the change will take place, please? This will help users > > to know when they shall expect the changes. > > > > Kind regards. > > > > On Wed, Aug 2, 2023 at 8:46 AM Christofer Dutz > > <christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>> wrote: > > Well, > > > > stating the obvious, I’ll add my +1 ;-) > > > > And yes Craig, I said the defaults … if you have explicitly configured your > > .asf.yaml subjects, they are left unchanged. > > > > Chris > > > > > > Von: Richard Zowalla <rich...@zowalla.com<mailto:rich...@zowalla.com>> > > Datum: Mittwoch, 2. August 2023 um 08:10 > > An: dev@community.apache.org<mailto:dev@community.apache.org> > > <dev@community.apache.org<mailto:dev@community.apache.org>> > > Betreff: Re: [POLL] Should we ask Infra to change the defaults used to > > generate GitHub integration email subjecs? > > +1 > > > > Am 2. August 2023 07:47:25 MESZ schrieb Jarek Potiuk > > <ja...@potiuk.com<mailto:ja...@potiuk.com>>: > > >+1 > > > > > >On Wed, Aug 2, 2023 at 2:15 AM Craig Russell > > ><apache....@gmail.com<mailto:apache....@gmail.com>> wrote: > > >> > > >> Hi Christofer, > > >> > > >> As long as projects with their own settings can continue to use them, I'm > > >> > > >> +1 > > >> > > >> to change the defaults for all projects. If the projects don't like > > >> being able to use their lists again, they can always go back to what > > >> they had before. > > >> > > >> Thanks, > > >> Craig > > >> > > >> > On Aug 1, 2023, at 05:16, Christofer Dutz > > >> > <christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>> wrote: > > >> > > > >> > Starting a new thread as the last one sort of dried up and didn’t > > >> > quite form anything actionable. > > >> > > > >> > Being subscribed to many of our mailing-lists and most recently > > >> > looking into every project, dev-lists when reviewing board reports, I > > >> > have seen many of our lists literally being rendered useless. > > >> > > > >> > Useless, because it’s almost impossible to follow these lists, as a > > >> > large percentage of the emails are: > > >> > > > >> > * Generated emails and the way they are currently generated makes > > >> > it impossible for email clients to correctly display them as threads. > > >> > * Contain so much redundant information, that the actual start of > > >> > the header that I’m interested in reading is usually not readable on > > >> > mobile phones. > > >> > * Most discussions have been moved away from the lists > > >> > (notifications@, commits@), having left over only skeletons in which > > >> > every now and then a vote is being handled. > > >> > > > >> > My proposal is to change the default settings for auto-generated > > >> > GitHub emails for all projects (not just the new ones) to be a much > > >> > more condensed version. > > >> > > > >> > With these changes, all existing lists, that haven’t manually > > >> > configured the format of the emails, instantly get readable lists > > >> > again. > > >> > > > >> > Some would argue that there might be projects that could object these > > >> > changes, but I would on the other hand bet that more projects would be > > >> > in favor of such a change than not. > > >> > Those who don’t want a change, can simply go back to the old format, > > >> > by specifying it in one commit for which we can even provide a default > > >> > .asf.yaml snippet. > > >> > > > >> > Some people expressed the wish to have longer prefixes, such as > > >> > “[ISSUE]”, “[PULL-REQUEST]” or “[DISCUSSION]” however do these not add > > >> > much information to the email that “[I]”, “[PR]” and “[D]” don’t and > > >> > the shorter version allows displaying more of the subject on mobile > > >> > email clients. > > >> > > > >> > Here’s an example of a project list before the changes: > > >> > https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15<https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9%7Cdto=2023-1-15> > > >> > Here’s an example of the same list after using the other defaults: > > >> > https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-6-12|dto=2023-6-18<https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-6-12%7Cdto=2023-6-18> > > >> > > > >> > Here’s an example on how even ponymail is now able to display > > >> > something happening on GitHub as a discussion you can also follow > > >> > nicely via email: > > >> > https://lists.apache.org/thread/rnr9tjx9rsnqc7b5nwcf68qnp5bkr9hc > > >> > > > >> > I would propose to keep the repository as part of the templates, even > > >> > if since my PR last week was merged it’s now possible to omit that too. > > >> > > > >> > I care deeply about our projects, and I would really hate to see our > > >> > core principles being lost more and more (“If it didn’t happen on the > > >> > list, it didn’t happen”). > > >> > > > >> > You would make me really happy if I could get some general approval by > > >> > you folks here. > > >> > > > >> > > > >> > Chris > > >> > > > >> > > > >> > > >> Craig L Russell > > >> c...@apache.org<mailto:c...@apache.org> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: > > >> dev-unsubscr...@community.apache.org<mailto:dev-unsubscr...@community.apache.org> > > >> For additional commands, e-mail: > > >> dev-h...@community.apache.org<mailto:dev-h...@community.apache.org> > > >> > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: > > >dev-unsubscr...@community.apache.org<mailto:dev-unsubscr...@community.apache.org> > > >For additional commands, e-mail: > > >dev-h...@community.apache.org<mailto:dev-h...@community.apache.org> > > > > > --------------------------------------------------------------------- > 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
