Discussion:
[openstack-dev] [tc] [all] TC Report 18-20
Chris Dent
2018-05-15 15:31:52 UTC
Permalink
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_.

# 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.

# 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.

# 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.
* Greater and more active exercising of whatever power they can
dredge up to help lead and change the community more directly.

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.
--
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent tw: @anticdent
Graham Hayes
2018-05-15 16:20:00 UTC
Permalink
Post by Chris Dent
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)
* [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.
Post by Chris Dent
# 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.
Post by Chris Dent
# 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.
Post by Chris Dent
# 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
* 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
Post by Chris Dent
* 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.
Post by Chris Dent
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.
Post by Chris Dent
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Tim Bell
2018-05-15 16:33:23 UTC
Permalink
From my memory, the LCOO was started in 2015 or 2016. The UC was started at the end of 2012, start of 2013 (https://www.openstack.org/blog/?p=3777) with Ryan, JC and I.

Tim

-----Original Message-----
From: Graham Hayes <***@ham.ie>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-***@lists.openstack.org>
Date: Tuesday, 15 May 2018 at 18:22
To: "openstack-***@lists.openstack.org" <openstack-***@lists.openstack.org>
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-20

......
Post by Chris Dent
# 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.




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://list
Graham Hayes
2018-05-15 16:40:32 UTC
Permalink
Post by Tim Bell
From my memory, the LCOO was started in 2015 or 2016. The UC was started at the end of 2012, start of 2013 (https://www.openstack.org/blog/?p=3777) with Ryan, JC and I.
Tim
Yeap - I miss read what mrhillsman said [0].

The point still stands - I think this does need to be discussed, and the
outcome published to the list.

Any additional background on why we allowed LCOO to operate like this
would help a lot.

- Graham

0 -
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T15:03:54
Post by Tim Bell
-----Original Message-----
Date: Tuesday, 15 May 2018 at 18:22
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-20
......
Post by Chris Dent
# 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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Davanum Srinivas
2018-05-15 16:44:50 UTC
Permalink
fyi Jay tried to once -
http://lists.openstack.org/pipermail/openstack-dev/2017-February/thread.html#111511
Post by Graham Hayes
Post by Tim Bell
From my memory, the LCOO was started in 2015 or 2016. The UC was started at the end of 2012, start of 2013 (https://www.openstack.org/blog/?p=3777) with Ryan, JC and I.
Tim
Yeap - I miss read what mrhillsman said [0].
The point still stands - I think this does need to be discussed, and the
outcome published to the list.
Any additional background on why we allowed LCOO to operate like this
would help a lot.
- Graham
0 -
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T15:03:54
Post by Tim Bell
-----Original Message-----
Date: Tuesday, 15 May 2018 at 18:22
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-20
......
Post by Chris Dent
# 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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Davanum Srinivas :: https://twitter.com/dims

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/lis
Davanum Srinivas
2018-05-15 16:44:50 UTC
Permalink
fyi Jay tried to once -
http://lists.openstack.org/pipermail/openstack-dev/2017-February/thread.html#111511
Post by Graham Hayes
Post by Tim Bell
From my memory, the LCOO was started in 2015 or 2016. The UC was started at the end of 2012, start of 2013 (https://www.openstack.org/blog/?p=3777) with Ryan, JC and I.
Tim
Yeap - I miss read what mrhillsman said [0].
The point still stands - I think this does need to be discussed, and the
outcome published to the list.
Any additional background on why we allowed LCOO to operate like this
would help a lot.
- Graham
0 -
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T15:03:54
Post by Tim Bell
-----Original Message-----
Date: Tuesday, 15 May 2018 at 18:22
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-20
......
Post by Chris Dent
# 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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Davanum Srinivas :: https://twitter.com/dims

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/lis
Thierry Carrez
2018-05-16 07:39:08 UTC
Permalink
Post by Graham Hayes
Any additional background on why we allowed LCOO to operate like this
would help a lot.
We can't prevent any group of organizations to work in any way they
prefer -- we can, however, deny them the right to be called an OpenStack
workgroup if they fail at openly collaborating. We can raise the topic,
but in the end it is a User Committee decision though, since the LCOO is
a User Committee-blessed working group.

Source: https://governance.openstack.org/uc/
--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.o
Loading...