Filing the ticket to create the above list made me look at the current list of owners and moderators for announce and devel-announce. I removed Mike McGrath from ownership, because I’m quite sure he’s not taking an active role at that level at this point but I also thought… it’s often Ben who reviews and approves these messages. Should we broaden that?
I’ve no objection to adding more folks here… but I think we should all follow some simple guidelines on posts to these lists:
Someone other than the poster should review / approve posts (I’ve appoved my own posts many times, but this sometimes leeds to simple mistakes or typos the poster doesn’t see because they wrote it. If we had enough people to always review by another person I think that would be a win.
No replies. You should never reply to a announcement here, it should be a followup announcement.
we should have some kind of review time expectation, like in 4 hours or a day or something. I’d like to have this to avoid the ‘hey, I just sent an announcement email, I am going to bother moderators to stop doing whatever they are doing and approve it for me right now’ messages.
Perhaps fesco for devel-announce and council for announce? or program-mgmt for either I suppose… I don’t think we need some big long discussion, just a formalization of some simple rules we have mostly already been following.
Speaking on behalf of the team, I think that’s a reasonable thing for us to take on. Particularly since I do a lot of the moderation already. It could also reasonably fall to CommOps.
My main question would be “where should we put the moderation guidelines?” I’m not sure there’s a natural fit in the docs at the moment (at least not in such a way that people could actually find them). Kevin’s guidelines are an excellent starting point (particularly if the typo was intentional), although I have to say that I have never sent an email about a release go/no-go decision and had the release number wrong. Nope. Not once.
And I have never sent a release announcement where I started by editing the last release’s announcement several releases in a row, resulting in a comically long chain of repeated email footers.