+1 to proposed users, commits and notifications mailing lists
On 2025/02/21 06:14:04 Paul King 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. >
