I am aware, I was at the committers meeting yesterday. While mailing lists are nice for historical reasons, they aren't great for community building in today's world but that's a different problem than we are trying to solve here.
/Eric On Fri, Feb 21, 2025 at 8:58 AM Søren Berg Glasius <soe...@glasius.dk> wrote: > We are not talking about shutting down the Grails Slack, but discussions > about dev and direction of Grails needs to be done "the Apache way" through > a dev mailing list. > > /Søren > > Den fre. 21. feb. 2025 kl. 15.56 skrev Eric Kinsella < > erickinse...@gmail.com > >: > > > +1 to proposed users, commits, and notifications mailing lists > > > > I agree with Soren about cleaning up previous mailing lists/google groups > > ie gra...@googlegroups.com to point to users@grails. > > > > I do believe there is some benefit to new users having Slack/Discord for > > "getting-started" questions and hopefully quicker turnaround than > > StackOverflow or mailing lists. > > > > Thanks, > > Eric > > > > > > On Fri, Feb 21, 2025 at 7:18 AM James Daugherty > > <jdaughe...@jdresources.net.invalid> wrote: > > > > > +1 to proposed users, commits, and notifications mailing lists. > > > > > > On Fri, Feb 21, 2025 at 5:27 AM Søren Berg Glasius <soe...@glasius.dk> > > > wrote: > > > > > > > +1 to proposed users, commits and notifications mailing lists > > > > > > > > I propose that gra...@googlegroups.com should be decommissioned (or > > made > > > > read only) with a final message encouraging members to join > > > > us...@grails.apache.org instead. > > > > > > > > Den fre. 21. feb. 2025 kl. 07.15 skrev Paul King <pa...@asert.com.au > >: > > > > > > > > > Hi folks, > > > > > > > > > > Currently Grails has private and dev mailing lists created. Folks > > > > > interested in the development of Grails should subscribe to the dev > > > > > list. Folks on the PPMC (podling project management committee) > should > > > > > subscribe to the private list. Typically projects have additional > > > > > lists. > > > > > > > > > > The most common one is "users" for users of Grails to ask > questions. > > > > > > > > > > **It is recommended you have a users mailing list.** > > > > > > > > > > The next most common ones are commits/notifications. There are lots > > of > > > > > potential sources of information that can provide insight into > > changes > > > > > made in the project. The ASF strongly recommends that you send > those > > > > > to a mailing list. You will have numerous options to configure what > > > > > goes where (it can be changed over time and you don't need to > decide > > > > > that now). For now you just need to decide if you want one or both > of > > > > > those lists. You can send some of the sources of notifications to > the > > > > > dev list but it can soon become swamped, so you'd typically only > want > > > > > a select subset to go there. > > > > > > > > > > Geb just has notifications. It sends a few select sources of info > to > > > > > geb-dev and everything else (includes commits, discussions, issues, > > GH > > > > > action status, PR comments; about 100/month) goes to > > > > > geb-notifications. The advantage of having one list is that there > is > > > > > just one place to look but there might be more noise if you are > > > > > browsing through looking for something. > > > > > > > > > > Groovy has both commits (all commits/code changes from all repos; > > > > > about 200/month) and notifications (PR status changes, issue > tracking > > > > > comments; 300+/month). The advantage of splitting the two is that > if > > > > > you are searching for a code change, commits is likely where you'll > > > > > find luck. If you remember something someone said (maybe in an > issue > > > > > comment), notifications might be the better place to look. I > > encourage > > > > > bigger projects to go down this path since you have a bit more > > > > > flexibility, but I wouldn't call it a super strong preference. > > > > > > > > > > You could also go more fine grained and have "issues", > "discussions" > > > > > and so forth. I don't have a lot of experience with this approach. > > > > > Some aspects would be simpler but if you can't remember where a > > > > > discussion took place, as a discussion, in a mailing list, on an > > > > > issue, a comment on a GitHub commit, etc, you might have more > places > > > > > to look. > > > > > > > > > > **It is recommended you have a commits mailing list.** > > > > > > > > > > **It is recommended have a notifications mailing list.** > > > > > > > > > > There are other possibilities, e.g. "security". For now you can > just > > > > > use "private" and if you end up responding to lots of security > > > > > aspects, you can create a special one later. > > > > > > > > > > In terms of process, if you are happy with my suggestions, you can > > > > > respond +1 to this whole email or +1 to the specific lists you are > > > > > happy with. We should discuss as long as needed. After discussion > > dies > > > > > down (or around 72 hrs have passed), if it looks like there is > > general > > > > > consensus, I'll go ahead and create the lists. We should iterate if > > > > > discussions head us in a slightly different direction. > > > > > > > > > > If it looks like we need any further clarity, I'll create a [VOTE] > > > > > thread separate to this [DISCUSS] thread and we can vote and gain > > > > > consensus that way. PPMC votes are binding but, as a general rule, > > > > > you'd typically want to take votes from all community members into > > > > > account in such discussions/votes. > > > > > > > > > > Cheers, Paul. > > > > > > > > > > > > > > > > > -- > > > > > > > > Med venlig hilsen, > > > > Søren Berg Glasius > > > > > > > > Hedevej 1, Gl. Rye, 8680 Ry > > > > Mobile: +45 40 44 91 88 > > > > --- Press ESC once to quit - twice to save the changes. > > > > > > > > > > > > -- > > Med venlig hilsen, > Søren Berg Glasius > > Hedevej 1, Gl. Rye, 8680 Ry > Mobile: +45 40 44 91 88 > --- Press ESC once to quit - twice to save the changes. >
