Rico Lin wrote:
The question I would like to ask is, what else we can do here to help SIGs to have a better life? What can we do from here? And is there any feedback regarding on experience of participate a SIG or chairing one?
I think the best thing we can do to help SIGs to have a better life is to make it as lightweight as possible to run one.
For some work in progress (or completed) actions: I'm working on a guideline for SIGs ( https://etherpad.openstack.org/p/SIGs-guideline%C2%A0)%C2%A0because I believe it might provide some value for SIGs, especially new-formed SIGs. Please kindly provide your feedback on it. Will send a patch to update current document under governance-sigs once we got good enough confident on it.
In the spirit of keeping things lightweight, I feel like this document is already overwhelming. I understand it's meant as a resource guide in case SIGs need guidance, but as it stands it looks a bit intimidating, with its 7 bullet points for "Creating a SIG". Actually the only thing needed to create a SIG is the first bullet point (patch to governance-sigs), everything else is VERY optional.
I wonder if this should not be made a SIG guide (under the model of the Project Team Guide), with:
1. When to create a SIG 1.1 What's a SIG 1.2 SIGs compared to other working groups in OpenStack
2. Process to create a SIG (file that patch, with name, lead(s) and scope)
3. Optional resources available to SIGs 3.1 Communications 3.2 Meetings (in person and online) 3.3 Documentation (wiki...) 3.4 Git Repositories 3.5 Task tracker
4. SIG lifecycle 4.1 Keeping SIG leads and URLs up to date 4.2 Marking SIGs inactive 4.3 Removing a SIG
While it would make a larger document overall, it would IMHO make it clearer what's necessary and what's guidance / optional.
I'm happy to help setting this up as a separate documentation repo, if that sounds like a good idea.