On Mon, 3 Oct 2016, Clay Gerrard wrote:
I just re-read your announcement - and I couldn't be happier you're running
:D
a) Glad to hear it.
b) It's a shame these email threads didn't start last week. I
suspect many of the people reading have already voted. I think the
conversations are still valuable, both for the people who haven't
voted and to shape future discussions. It's making more things more
visible, and that's good.
I was so surprised at the fallout from your suggestion that the TC should
actively engage in more broadcasting of important topics [1] to bring in
more voices from the community early!? Links to IRC logs and Gerrit commit
history seemed to totally miss the point?
Yes, I found that surprising too. To be fair I think it probably has
a lot to do with different people's different communication styles.
For some people IRC logs and gerrit are great. For others, not so
much. This is one of the reasons for insisting that the TC have a
mixture of voices and opinions. It can be very easy to become
habituated to believing that the norm works for everyone, when it
could just be you for whom it is working.
I'm curious if any other discussions or questions on the mailing list have
excited or frustrated you in the past week? Is there any specific goals
you have for a one year term on the TC - or do you think more clarity on
past "perceived agreements" and a better focus on visibility and
communication is the more important thing to fix first?
All that is important, and (transferring gordc's question over here)
better communication will certainly enhance the TC's capability as a
responsive (seems a better term than reactive) representative body.
Good communication is effectively a requirement for doing existing
and future work correctly.
Where I want to see the TC be proactive is a long list. A sample is
below. The reason I think the TC should take a lead on these is because
the issues need attention from a group that prioritizes the entire
community, not just one project, and the members of that group must have
the time to give real attention to the issues. Very few people in
the community are licensed to legitimately use time in that fashion.
Some ideas other candidates have already stated:
* Driving community-wide goals (for example Python 3 support sooner than
later).
* Building bridges with other communities in similar spaces (for
example our pals in k8s).
I hope that neither of these are controversial. They are fundamental for
the long term health of the community and the project.
Some notions that might be subject to some disagreement:
* Putting some strength in working groups like arch-wg and api-wg so
we can start modernizing in general and in some cases correcting
past mistakes.
* Concentrating more on contributor experience. Not at the expense
of user experience, but in addition to. I think part of the role
of the TC should be something akin to a union rep. Corporate driven
open source is weird. We need to acknowledge that it presents some
challenges. We've seen some discussion dancing around the edges of
this topic in the review of the principles document linked from [1].
* Balance the needs of existing users against the needs of the users
we haven't yet acquired somewhat in favor of the many more users yet
to come. Too often we use existing users as an excuse to not make an
improvement. This is not to say we should actively punish existing
users but rather that there a multiple avenues to smooth transitions
beyond simply avoiding them.
* Put some subjectivity back into the project evaluation process.
The big tent was designed to make acceptance into the OpenStack
community more objective. That's admirable in some ways, but has led
to confusion about the identity of OpenStack. The thing is that
taste matters. OpenStack needs to have opinions about what
OpenStack is and does. We need humans to articulate those opinions
and then act on them by sometimes saying yes and sometimes saying
no. That's hard work but it pays dividends not just in community
cohesion but also in product cohesion. This will require (as
others have stated) making a real effort to set some goals on a 1, 2
and 5 year timetable. Where do we want to be? How do we get there?
What are our subjective assertions about how things should be at each
of those stages.
* And because it needs to be said somewhere: I'm pretty okay with this
whole golang thing. Requiring homogeneity is a sure fire way to
limit innovation and kill any spirit of experimentation and
exploration. We want the OpenStack community to be a place of
constant learning. People who aren't learning will go elsewhere to
do so. Do we want to lose them?
While I have opinions on all these things, and I will defend those
opinions with vigor, I want to be actively disagreed with. Active
debate is how we reach strong and reasonable compromises. I don't
want to impose my vision on OpenStack but I do want to be sure that
the vision we enact has been subject to strenuous critique.
I'm very encouraged by the large number of candidates this time around.
Not just that there are a lot of us but that so many are saying "okay,
we need to kick it up a notch and _do_ stuff". Without that attitude
none of the issues listed above will be addressed. It can be easy to
lazily think of the TC as the organization that safeguards the status
quo. That needs to stop. The world outside OpenStack is moving forward
and changing, OpenStack needs to move and change too.
Thanks for prompting this.
1. This is a great example how much this attitude of "full contact
community engagement" is *needed* and how much it's *lacking* with the
current set of representatives ->
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103223.html -
not surprisingly it took someone from "the outside" to make it happen!
--
Chris Dent ┬─┬ノ( º _ ºノ) https://anticdent.org/
freenode: cdent tw: @anticdent
__________________________________________________________________________
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
