+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.
> >
>

Reply via email to