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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
