I created (still pending with a 12-24 hr delay) the lists with the default list behavior which lets subscribers post but others are moderated.
It would be good to have a few PPMC folks to help moderate the list. Let me know if you are happy to help and I'll add you. What's involved? Emails from non-subscribers go to moderators. There is a link to accept, another to reject. There is an optional place to give a reason but it's rarely used since most rejections are spam bots. If you see a legitimate email, just click accept and it will appear on the list. You can hit reject on spam but it will just sit in a queue and eventually time out if you ignore it (i.e., no need to worry if it ends up in your spam folder and you ignore it). Paul. On Tue, Feb 25, 2025 at 9:41 AM Paul King <pa...@asert.com.au> wrote: > > It looks like there is consensus, so I'll go ahead and create those lists. > > Does someone want to create an issue to make the old lists read-only > once the new lists are up and running? At least for users. > > On Fri, Feb 21, 2025 at 4:14 PM Paul King <pa...@asert.com.au> wrote: > > > > 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.
