Hi everyone, Once upon a time we only had one governance construct to recognize activity in OpenStack, and that was the upstream project teams. As a result, we created teams for everything.
However with the introduction of SIGs, we have a new construct for activities that are not mainly about producing OpenStack software bits (for which we should continue to use project teams) or directly related to a specific governance body (for which we should continue to use "working groups"). SIGs are especially good when the activity is centered around a topic or practice that spans all our community (developers, operators, end users...), forming a guild of people with a shared interest. Security IMHO is a great example of such a topic. The Security team's raison-d'être is the production of software, but more generally the improvement of the state of security in all aspects of OpenStack. It can gather all security-conscious people in all our community. So I think the Security project team would benefit from becoming a proper SIG. You might say, but it also produces software (anchor, bandit, syntribos...). You would be right, but (1) SIGs can totally have software by-products and own git repositories, and (2) that software is more about security in general than a piece of OpenStack itself. You might wonder, will that result in losing ATC status (TC voting rights) ? Well no, the plan being to consider SIGs in the same way as project teams as far as voting rights are concerned. What do you think ? -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
