Open Stack

On Tue, Feb 25, 2020 at 11:27 AM 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.
>
> 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).

I personally agree with this option as that seems like the best possible
option moving forwards.

> Thoughts ?
>
> --
> Thierry Carrez
>