I am one of those who would like to contribute to Standard Name discussions without the need to go near Github.
Cheers, Roy. I have now retired but will continue to be active through an Emeritus Fellowship using this e-mail address. ________________________________ From: [email protected] <[email protected]> on behalf of Painter, Jeff <[email protected]> Sent: 07 November 2018 22:44 To: Brian Eaton Cc: [email protected]; [email protected] Subject: Re: Please stop sending Github messages to the ML Someone (I forget who) told me that many of the people discussing standard_names would not want to deal with the additional complexities of Github. From: Brian Eaton <[email protected]> Date: Wednesday, November 7, 2018 at 2:41 PM To: "Painter, Jeff" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Please stop sending Github messages to the ML Erik, > I don't have a view of the whole setup, so I may be missing some aspects > that complicate this. But even then, it may be worth the effort. The piece you're missing is that I'm trying to get Mailman support off of my plate; not make it a more integral part of the system. The CF conventions activities are supported at LLNL, not at NCAR. The original CF website which I created at NCAR was moved to LLNL quite a few years ago, but for reasons I've never understood it wasn't possible, at least at that time, to support a Mailman server there. So it stayed at NCAR, and has been stuck here ever since. Again, I don't really see why moving all discussion to github wouldn't be preferable to having discussions on both github and a Mailman list (wherever that list might reside). But I'm not a github expert so don't know whether there are drawbacks to having all the discussions there. Brian On Wed, Nov 7, 2018 at 3:14 PM Painter, Jeff <[email protected]<mailto:[email protected]>> wrote: It certainly is a hack! When we set up this two-list system long ago, LLNL's lists were managed by Majordomo. No they are run by LISTSERV. I don't know whether LISTSERV supports flexible topics within the list. On 11/7/18, 1:58 PM, "Erik Quaeghebeur" <[email protected]<mailto:[email protected]>> wrote: Dear Brian, > I don't believe that [email protected]<mailto:[email protected]> is a mailman list. The > cf-metadata mailman list (which I administer at NCAR) is > [email protected]<mailto:[email protected]>. The LLNL server is the one that gets the github > notifications and sends them to *mostly* the same people who are members of > the mailman list. I say mostly because the membership in these lists is > synchronized by hand. When people sign up or remove themselves from the > mailman list, I send this information to Jeff Painter who then makes the > changes at LLNL. We originally set things up like this so that people > didn't need to sign up in two places to follow the discussions that were > happening on the mailman list and on the trac server at LLNL. As github > has replaced trac the current system was set up. I understand the logic, but this sounds like a hack. It seems this can be dealt with as follows: * You as cf-metadata admin creates topics as needed * LLNL list traffic is sent to the cf-metadata list using one or more specific topic that people can (un)subscribe (from) to. It seems to me such an approach would have multiple advantages: * No need to (manually) sync users * Users are in control of selecting topics * Reverse traffic is likely possible by users sending mail to the appropriate topic (how exactly this works, I don't know, but it would surprise me if this were not possible) I don't have a view of the whole setup, so I may be missing some aspects that complicate this. But even then, it may be worth the effort. Best, Erik ________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ________________________________
