Open Stack

Option 1 is definitely the fastest though I do wish we could have a more
unified name for the group. It's not just a UC issue of not having enough
people to run, the last TC election I believe did not have an actual vote
after nominations.

Either we have a unified group that oversees the direction of the community
or keep them separate as they are now.

OPS Meetup reports to the UC in a sense and is not a totally different
group.

Amy (spotz)

On Tue, Feb 25, 2020 at 9:23 AM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

> ---- 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
>  >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200225/9f6f2e8f/attachment-0001.html>