Python SIG Creation Guidelines
The guidelines for creation of new SIGs are rather informal, but a few key things are necessary. First we outline the general framework of the SIGs and then we describe what you have to do if you want us to create a new SIG.
The SIG mailing lists are managed by MailMan, a web-based interface for mailing lists written in Python by John Viega and Ken Manheimer (and several others, in an ongoing open-source effort). Un/subscription requests, archiving of messages, etc. all happen automatically, without human intervention. This is A Good Thing (TM) because such responses should be processed very quickly. (While the normal way to interact with a mailing list is via the SIG's "listinfo" web page, it is also possible to send commands to a special administrative address, see below.)
Every SIG must have a clear mission, with a well defined conclusion and end date, and a coordinator - a specific person responsible for reporting on the SIG activity and for shepherding the SIG's activity and wrap-up. The end date can be extended if activity warrants, but we need some reasonable wrap-up objective to avoid maintenance of unproductive SIGs.
To create a SIG once you can satisfy these criteria, propose it for discussion on the meta-sig mailing list. If you get agreement that the SIG is worth creating - and in particular, no other SIG nor the general Python newsgroup is already more suitable - and your coordinator is ready, the SIG will be created.
Mailing List Framework
Each mailing list has a short name, for example "gui". For each SIG, there are three special addresses:
Mailing List Policy
Each mailing list has a policy for such things as who can join the list, or post messages, etc. In general all SIG lists have the following (fairly lax) policy. SIG owners are given their own web interface to MailMan, so they can change the policy without our help.
So you want to create a new SIG mailing list? Well here's what you have to do. Most importantly, you have to take responsibility for your list. This means we get to alias owner-<name>-firstname.lastname@example.org to your personal mailbox :-). You won't get bugged too often (hopefully), but you may occasionally have to process subscription approvals, and you will get ignorable notification messages whenever someone subscribes or unsubscribes.
You should decide what your topic is going to be and what it's scope is. Try to keep it focused, and make sure you verify that no other SIG covers your topic. You need to write two things. First, you should write a short informational blurb about your SIG; just something that can be put in a short list of SIGs, e.g. "Development of a C++ Binding."
You'll also need to write a somewhat longer blurb, which will eventually be used on the SIG's web page. Here, for example, is the info page for the meta SIG. Include as much information as you feel is necessary, but try to keep it fairly brief and concise.
You should discuss your proposed sig on the meta SIG mailing list. Introduce your proposal, and include a draft of both blurbs, so we can all discuss the merits of the new SIG. If there's a general consensus to create it (or more likely, no overt opposition), then drop us a note. We'll create then the necessary infrastructure and communicate with you about the details.