Open Stack

---- On Tue, 25 Feb 2020 04:23:56 -0600 Thierry Carrez <thierry at openstack.org> wrote ----
 > Hi all,
 > 
 > When our current project governance was established in 2012, we defined 
 > two separate bodies. The Technical Committee represented developers / 
 > code contributors to the open source project(s), while the User 
 > Committee represented the operators running the resulting software, as 
 > well as users of the APIs.
 > 
 > That setup served us well in those early days. The focus on the upstream 
 > side was strongly around *development* of code, we did not have that 
 > many users, and even less users directly involved in upstream 
 > development. A separate User Committee resulted in the formation of an 
 > engaged community of users, and ensured that our community in general 
 > (and our events in particular) took the needs of operators into account.
 > 
 > Fast-forward to 2020: the upstream focus is more on maintenance. We now 
 > have a lot of users, and thanks to the efforts of the UC they are 
 > increasingly directly involved in the open source project development, 
 > with several operators leading upstream project teams directly. There is 
 > now limited UC-specific activity, and as such it is struggling to get 
 > volunteers to step up for it: nobody nominated themselves for the last 
 > round of election.
 > 
 > Keeping two separate bodies to represent them maintains the illusion 
 > that devs and ops are different breeds, and sometimes discourages 
 > operators from running for the TC and more directly influence the shape 
 > of the software. If anything, we need more ops representation at the TC, 
 > and seeing people like mnaser being elected at (and chairing) the TC was 
 > a great experience. I discussed the situation with the current UC 
 > members, and we decided it's time to consider having a single 
 > "community" and a single body to represent it.
 > 
 > That body would tackle the traditional TC tasks (open source project 
 > governance and stewardship) but also the UC tasks (user survey, 
 > ambassador program...). That body would be elected by contributors, in a 
 > large sense that includes the AUC definition. I feel like that would 
 > help remove the artificial barriers discouraging users to get more 
 > directly involved with software development and maintenance.
 > 
 > There are multiple ways to achieve that, in increasing order of 
 > complexity and bylaws changes needed:
 > 
 > 1- No bylaws change
 > As bylaws changes take a lot of time and energy, the simplest approach 
 > would be to merge the TC and UC without changing the bylaws at all. The 
 > single body (called TC) would incorporate the AUC criteria by adding all 
 > AUC members as extra-ATC. It would tackle all aspects of our community. 
 > To respect the letter of the bylaws, the TC would formally designate 5 
 > of its members to be the 'UC' and those would select a 'UC chair'. But 
 > all tasks would be handled together.

Thanks a lot, ttx for starting this thread.

option 1 looks more feasible way but few question/feedback:
- How we will execute the "designate 5 members from TC and select UC chair"?

If by volunteer call from TC?
I think this can lead to the current situation where very few members are interested to
serve as UC.  I am afraid that we will get 5 volunteers and a chair.

If by force?
I do not think this is or should be an option :). But if then how we make sure the TC
members are ok/good to handle the UC tasks on the non-technical side for example
ambassador program.

- Will there be any change in TC elections, votes weightage and nomination? by this change
of a new subteam under TC? 

- I think along with the merging proposal, we should distribute the current tasks handled by UC
among TC, Ops group, foundation etc. For example, the ambassador program, local user group
interaction or any other managerial tasks should be excluded from TC scope. 
If we would like to merge all then I think we should rename TC to Steering Committee or
something which is option 3.

- What about merging UC into Ops team, they are more close to users/operators and active
in terms of the meetup and providing feedback etc.

-gmann

 > 
 > 2- Minimal bylaws change
 > Same, but all mentions of the UC would be removed from the bylaws 
 > (affecting sections 4.12, 4.14, and Appendix 10). This would require a 
 > simple vote by the Board of Directors, and would avoid some confusion 
 > and having to formally designate a subset of the TC to respect the 
 > letter of the bylaws.
 > 
 > 3- Maximal bylaws change
 > Create a new body ("steering committee" for example) replacing the TC 
 > and the UC. This would require changing sections 4.1, 4.12, 4.13, 4.14, 
 > 4.20, 7.1.b, 7.4, 9.1, 9.2.d, and Appendixes 4 and 10. Section 4.13, 7.1 
 > and 7.4 being heavily protected in the bylaws, they require special 
 > votes by each class of Foundation members, probably a multi-year effort. 
 > A lot of documentation would also need to be changed in case the TC is 
 > renamed.
 > 
 > I personally don't think the benefit of the change offsets the large 
 > cost of option (3). Given the current vacancy in the UC makeup I would 
 > recommend we pursue option 1 immediately (starting at the next TC 
 > election in April), and propose minimal bylaws change to the board in 
 > parallel (option 2).
 > 
 > Thoughts ?
 > 
 > -- 
 > Thierry Carrez
 > 
 >