Open Stack

On 15/05/18 16:31, Chris Dent wrote:
> 
> HTML: https://anticdent.org/tc-report-18-20.html
> 
> Trying to write a TC report after a gap of 3 weeks is hard enough,
> but when that gap involves some time off, the TC elections, and the
> run up to summit (next week in
> [Vancouver](https://www.openstack.org/summit/vancouver-2018/)) then
> it gets bewildering. Rather than trying to give anything like a full
> summary, I'll go for some highlights.
> 
> Be aware that since next week is summit and I'll be travelling the
> week after, there will be another gap in reports.
> 
> # Elections
> 
> The elections were for seven positions. Of those, three are new to
> the TC: Graham Hayes, Mohammed Naser, Zane Bitter. Having new people
> is _great_. There's a growing sense that the TC needs to take a more
> active role in helping adapt the culture of OpenStack to its
> changing place in the world (see some of the comments below). Having
> new people helps with that greatly.
> 
> Doug Hellman has become the chair of the TC, taking the seat long
> held by Thierry. This is the first time (that I'm aware of) that a
> non-Foundation-staff individual has been the chair.
> 
> One of the most interesting parts of the election process were the
> email threads started by Doug. There's hope that existing TC
> members that were not elected in this cycle, those that have
> departed, and anyone else will provide their answers to them too. An
> [email
> reminder](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130382.html)
> 
> exists.
> 
> # Summit
> 
> Is next week, in Vancouver. The TC has several
> [Forum](https://wiki.openstack.org/wiki/Forum/Vancouver2018)
> sessions planned including:
> 
> * [S release
>   goals](https://etherpad.openstack.org/p/YVR-S-release-goals)
> * [Project boundaries and what is
>  
> OpenStack](https://etherpad.openstack.org/p/YVR-forum-TC-project-boundaries)
> 
> * [TC
>   Retrospective](https://etherpad.openstack.org/p/YVR-tc-retrospective)
> * [Cross Community
>  
> Governance](https://etherpad.openstack.org/p/YVR-cross-osf-tech-governance)
> 
> # Corporate Foundation Contributions
> 
> There's ongoing discussion about how [to
> measure](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-24.log.html#t2018-04-24T15:43:59)
> 
> upstream contribution from corporate Foundation members and what to
> do if contribution seems lacking. Part of the reason this came up
> was because the mode of contribution from new platinum member,
> Tencent, is not clear. For a platinum member, it should be
> _obvious_.

This is a very important point. By adding a company (especially at this
level) we grant them a certain amount of our credibility. We need to
be sure that this is earned by the new member.

> # LCOO
> 
> There's been some concern expressed about the The Large Contributing
> OpenStack Operators (LCOO) group and the way they operate. They use
> an [Atlassian Wiki](https://openstack-lcoo.atlassian.net/) and
> Slack, and have restricted membership. These things tend to not
> align with the norms for tool usage and collaboration in OpenStack.
> This topic came up in [late
> April](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T14:39:36)
> 
> but is worth revisiting in Vancouver.

From what I understand, this group came into being before the UC was
created - a joint UC/TC/LCOO sync up in Vancouver is probably a good
idea.

> # Constellations
> 
> One of the things that came out in election campaigning is that
> OpenStack needs to be more clear about the many ways that OpenStack
> can be used, in part as a way of being more clear about what
> OpenStack _is_. Constellations are one way to do this and work has
> begun on one for [Scientific
> Computing](https://review.openstack.org/#/c/565466/). There's some
> discussion there on what a constellation is supposed to accomplish.
> If you have an opinion, you should comment.
> 
> # Board Meeting
> 
> The day before summit there is a "combined leadership" meeting with
> the Foundation Board, the User Committee and the Technical
> Committee. Doug has posted a [review of the
> agenda](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130336.html).
> 
> These meetings are open to any Foundation members and often involve
> a lot of insight into the future of OpenStack. And snacks.
> 
> # Feedback, Leadership and Dictatorship of the Projects
> 
> Zane started [an email
> thread](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130375.html)
> 
> about ways to replace or augment the once large and positive
> feedback loop that was present in earlier days of OpenStack. That
> now has the potential to trap us into what he describes as a "local
> maximum". The thread eventually evolved into concerns that the
> individual sub-projects in OpenStack can sometimes have too much
> power and identity compared to the overarching project, leading to
> isolation and difficulty getting overarching things done. There was a
> bit of discussion about this [in
> IRC](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-11.log.html#t2018-05-11T19:13:02)
> 
> but the important parts are in the several messages in the thread.
> 
> Some people think that the community goals help to fill some of this
> void. Others thinks this is not quite enough and perhaps project
> teams as a point of emphasis is ["no longer
> optimal"](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130436.html).
> 
> 
> But in all this talk of change, how do we do the work if we're
> already busy? What can we not do? That was a topic [Monday
> morning](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-14.log.html#t2018-05-14T09:00:00).
> 
> 
> # API Version Bumps
> 
> Also on Monday, plans [were
> made](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-14.log.html#t2018-05-14T17:27:05)
> 
> to have a session in Vancouver about how to do across-the-system
> minimum API version bumps. This started in response to a meandering
> thread [on
> twitter](https://twitter.com/robcresswell/status/994911766776877059)
> about inconsistencies in the OpenStack's APIs "never" being
> resolved.

This should be a good session, but will need serious buy in across the
project to actually make an impact. Otherwise it will be the usual
people in a room, arguing about the usual things, waiting to restart the
debate in Denver.

> # Where Now?
> 
> It's hard to make any conclusions from the election results. A
> relatively small number of people voted for a relatively small
> number of candidates. And there's always the sense that voting is
> primarily based on name recognition where platforms and policies
> have little bearing. However, if we are to take the results at face
> value then it appears that at least some of the electorate wants one
> or both of the following from the TC:
> 
> * Increased communication and engagement.

I think this is true, based on conversations with people in the last
few months. These reports really help let people know what is happening

> * Greater and more active exercising of whatever power they can
>   dredge up to help lead and change the community more directly.

Yes, with a caveat. People want the TC to use their "power" (more
ability to influence) to get things done, but may dislike where the
TC uses that influence.

> Do _you_ think this is true? What direction do things need to go?
> 
> I'm currently in the state of mind where it is critical that we
> create and maintain the big picture information artifacts
> ("OpenStack is X, Y, and Z", "OpenStack is not A, B and C", "Next
> year OpenStack will start being E but will stop being Z") that allow
> contributors of any sort to pick amongst the (too) many
> opportunities for things to do. Especially making it easier—and
> socially and professionally _safer_—to say "no" to something. This
> makes it more clean and clear to get the right things done—rather
> than context switch—and to create the necessary headspace to
> consider improvements rather than doing the same thing over again.

I think we definitely need to get to a point where we can say "no",
to both projects, and features in those projects.

"Doesn't fit with the future vision" should be something we can and do
say.

> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180515/2dc3c32d/attachment.sig>