<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Chris - I am sure that this was said before (I do recall a mail
last week on the mailing list after you sent it out).</p>
<p>Thank you - this is awesome! <br>
</p>
<p>A great recap - please continue doing this!!</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 03/05/17 0:46, Chris Dent wrote:<br>
</div>
<blockquote
cite="mid:alpine.OSX.2.20.1705022244420.29450@shine.local"
type="cite">
<br>
# Intro
<br>
<br>
Feedback from last week's first attempt at a weekly overview of TC
<br>
activity was positive enough to continue. Suggestions on how to
make
<br>
it more useful welcome. Main change this time is that I've added
<br>
some information on stuff happened outside the meeting, a link to
<br>
the meeting minutes, and a section on stuff we talked about last
<br>
week that we said we'd pick up later but haven't yet.
<br>
<br>
# Prior to the Meeting
<br>
<br>
## Communications
<br>
<br>
Shortly after producing the first version of this newsletter last
<br>
week I was approach by Flavio who reminded me that there has been
a
<br>
communications working group for the TC that had plans to provide
<br>
regular updates on the state of things TC. We agreed that such a
<br>
thing should still happen, that I ought to be involved, but that I
<br>
would probably still to do this, so that I could editorialize
freely
<br>
if I wished.
<br>
<br>
Then in discussion of dropping the regular meetings[^1] it came up
<br>
that if we do that it will be very important to have plenty of
<br>
structured communication to the mailing list to replace some of
the
<br>
cadence marking that the meeting provides, something the TC chair
<br>
might provide . As I'm typing this, this week's meeting has
started
<br>
and it is clear (by the immediate rush of discussion) the topic is
<br>
of dropping the meetings is going to a big deal and if followed
<br>
through will be a significant shakeup to how interactions happen
<br>
within the TC and between the TC and everyone else. It is
especially
<br>
important for people who are not on the TC but want to interact
with
<br>
it regularly in a conversational way. If you have thoughts on
this,
<br>
read and respond to[^1].
<br>
<br>
## Draft Vision for the TC[^0]
<br>
<br>
This is mostly sitting idle, awaiting feedback from sessions in
<br>
Boston. The idea is to use the vision to establish some goals for
<br>
the TC and OpenStack. If you're interested or invested in that
<br>
future, your feedback is important (on the review, in email, in
the
<br>
survey that was sent out, or in the sessions next week). You might
<br>
look at what's there and think "what is all this fantasizing?". If
<br>
that's your reaction you should say so, and say what you think
<br>
should be talked about instead. Or you might love it. If you do,
you
<br>
could say why. That would be useful.
<br>
<br>
[^0]: <a class="moz-txt-link-rfc2396E" href="https://review.openstack.org/#/c/453262/"><https://review.openstack.org/#/c/453262/></a>
<br>
<br>
# This Week's Meeting
<br>
<br>
Minutes and Log:
<a class="moz-txt-link-rfc2396E" href="http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-05-02-20.01.html"><http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-05-02-20.01.html></a><br>
<br>
## Killing the Meeting[^1]
<br>
<br>
As mentioned above we leapt right into talking about killing the
<br>
meeting. Wide variety of opinions on what function the meeting is
<br>
providing in the first place, thus a broad selection of
suggestions
<br>
on what can be done instead of the meeting to serve those
functions.
<br>
Eventually we realized we weren't getting anywhere and there was a
<br>
motion to move the discussion to email because:
<br>
<br>
* it would be visible there to everyone
<br>
* gerrit is a poor medium for exploratory or expansive discussion
<br>
* email can be digested at whatever pace the reader requires
<br>
<br>
There were some ideas on how to make sure a thread moves forward
to
<br>
a conclusion. A regular summary and reality check of "is this
where
<br>
we are" every small number of days is a useful idea.
<br>
<br>
[^1]: <a class="moz-txt-link-rfc2396E" href="https://review.openstack.org/#/c/459848/"><https://review.openstack.org/#/c/459848/></a>
<br>
<br>
## Not Making Decisions Synchronously[^2]
<br>
<br>
This is related to killing the meetings; the idea is that making
<br>
decisions synchronously excludes everyone who cannot be there at
<br>
that specific moment in time or who cannot digest the language
<br>
quickly enough to participate at full speed in a synchronous
<br>
environment. There's some confusion over whether this should be a
<br>
goal for just the TC or the entire OpenStack community. We
<br>
eventually had to punt on this because we didn't really know. The
<br>
conversation will move to the review.
<br>
<br>
(In my observations of the TC for the past couple of years, this
is
<br>
a common pattern. There's often lack of clarity on intent of a
<br>
resolution or other proposal. What are the real problems it is
<br>
trying to address, or the environments it is trying to create?
<br>
People have very different interpretations and when it gets
<br>
difficult or unclear, rather than reaching the bottom of the
<br>
difference, the conversation is shifted to another time or medium.
<br>
Often this is due to time constraints, but frequently the topic is
<br>
never rejoined so incomplete understandings accumulate in a
massive
<br>
pile.)
<br>
<br>
[^2]: <a class="moz-txt-link-rfc2396E" href="https://review.openstack.org/#/c/460946/"><https://review.openstack.org/#/c/460946/></a>
<br>
<br>
## Change the target for this goal to uWSGI not Apache
mod_wsgi[^3]
<br>
<br>
General agreement about doing this change, not a big deal, but
some
<br>
concern about changing a cycle goal in the middle of the cycle
<br>
("moving the goal posts"). Agreement was that changing details of
<br>
implementation are not the same thing as changing the goal
<br>
(especially when it is a simplification) so it is okay as long as
<br>
the change is reflected in the doc, not just the git history.
<br>
<br>
[^3]: <a class="moz-txt-link-rfc2396E" href="https://review.openstack.org/#/c/460951/"><https://review.openstack.org/#/c/460951/></a>
<br>
<br>
## More on maintenance-mode
<br>
<br>
There's a newish tag called status:maintenance-mode which means
that
<br>
a project is receiving limited attention for a period of time.
<br>
There's a proposal[^4] that the TC should become core on such a
<br>
project to make sure there are people to handle urgent matters.
The
<br>
question is whether this is necessary since:
<br>
<br>
* the TC can get those privileges at any time on any project when
<br>
there is an urgent matter
<br>
* being in maintenance-mode is supposed to mean there is
sufficient
<br>
attention from project team members for urgent matters, if not
<br>
the project is abandoned
<br>
<br>
This turned out more contentious and confused than expected and it
<br>
too was punted to the review[^4].
<br>
<br>
[^4]: <a class="moz-txt-link-rfc2396E" href="https://review.openstack.org/#/c/460963/"><https://review.openstack.org/#/c/460963/></a>
<br>
<br>
## Open Discussion
<br>
<br>
The above filled pretty much the whole hour, suggesting that
perhaps
<br>
we all have a lot more to say to one another than a single hour
<br>
allows. That was acknowledged and suggestions were made that we
<br>
really need to use email more and better, even though it can be
<br>
challenging. That is, we need to level up our email skills.
<br>
<br>
To help ensure more talking to one another and do a bit of
near-term
<br>
planning, a TC gathering will happen in Boston late next week.
<br>
Evidently I will be spit-balling, and no one will be sitting near
<br>
me.
<br>
<br>
# Dropped Stuff
<br>
<br>
_A section of reminders of things we said we'd talk about more but
<br>
haven't yet._
<br>
<br>
## OpenStack moving too fast and too slow
<br>
<br>
At last week's meeting, while discussing the findings from the
user
<br>
survey there was discussion[^t] of
<br>
<br>
<blockquote type="cite">the complicated problem of OpenStack
moving both
<br>
too fast and too slow at the same time, depending on who was
<br>
looking. And the difficulty with lack of centralized control
over
<br>
the technical direction of OpenStack and (probably most
importantly)
<br>
the application of resources.
<br>
</blockquote>
<br>
that was supposed to move the mailing list[^m]. As far as I can
see
<br>
it did not. dfisher have you got the cycles to pick that up again
<br>
here on the list? Or if not you, maybe mordred, fungi or dhellman?
<br>
If it was already discussed, my apologies for losing it, can
someone
<br>
point it out to me?
<br>
<br>
[^t]:
<a class="moz-txt-link-rfc2396E" href="http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-177"><http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-177></a><br>
[^m]:
<a class="moz-txt-link-rfc2396E" href="http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-259"><http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-259></a><br>
<br>
# Colophon
<br>
<br>
This is an opinionated overview of Technical Committee activity
from
<br>
my perspective. As such it is subjective and potentially wrong
<br>
enough to cause disagreements. That's a good thing if it leads to
<br>
discussions that make things better or more correct.
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Best Regards,<br>
Maish Saidel-Keesing</div>
</body>
</html>