On 17/10/17 14:16, Doug Hellmann wrote:
Excerpts from Zane Bitter's message of 2017-10-16 18:10:20 -0400:
On 14/10/17 11:47, Doug Hellmann wrote:
Even the rewritten question can be answered
legitimately using several different personas by people with a bit
of experience. I have worked at a public cloud provider and two
distributors with a wide range of customers, and I use OpenStack
clouds myself. I hope that all of that background feeds into my
contributions.
Yes, that's great. I think most people would agree that there's a
threshold somewhere between 'several' and 'infinity' beyond which we've
crossed over into platitudes though.
Maybe. On the other hand, TC members aren't elected to represent
specific constituencies, so there's something to be said for taking each
case as it comes and considering the users impacted by that case.
Right, so we all agree that what we *don't* want is TC candidates saying
"I'm here to represent the interests of user community X against those
of evil user community Y", all of the X users voting for X candidates
and not Y candidates, and then the elected X members voting to block
anything that only benefits Y, and vice-versa. Obviously every step of
that process is an unmitigated disaster.
So of course each TC member should consider the all of the users
impacted by any decision on a case-by-case basis. However, even if we're
only thinking purely about reactive decision-making, it's still often
not easy to know *which* users are impacted by any particular decision
unless you have someone in the room who has a deep familiarity with that
use case. That's why I'd like to see candidates saying something like "I
spend a lot of time thinking about user community X and if anything came
up that affected their use cases I'm pretty sure I'd spot it". So that I
can vote to optimise the diversity of Xs represented, where X might be
e.g. web developers, devops teams, scientific researchers, vSphere
migrants, multi-cloud users, NFV, the next
Facebook/Twitter/Snapchat/Netflix, mobile app or IoT backend developers,
kubernetes users, or something I haven't even thought of.
Possible tangent: I've always enjoyed this article (about the
Sapir-Whorf hypothesis):
http://www.nytimes.com/2010/08/29/magazine/29language-t.html
tl;dr Anybody can think about anything, regardless of the language they
speak (i.e. Sapir-Whorf is wrong). But there are things in every
language that you can't *not* think about, and they're different for
different languages.
I want to maximise the set of things the TC, collectively, can't not
think about.
Suffice to say that nobody should take my example here as anything more
than a rationale for the importance of user-centred design.
How much "design" do you think the TC is doing as a governance group?
It varies between different levels of abstraction.
At the code level, none.
At the level of setting the broad technical direction of the project,
not as much as I'd like. But y'all did pass
https://governance.openstack.org/tc/resolutions/20170317-cloud-applications-mission.html
for me (thanks!) so definitely not nothing. There are other
less-directly-relevant examples like adding etcd to the list of base
services too.
At the level of deciding what projects OpenStack consists of, and
therefore what sort of cloud you can build with it (that is to say, what
you can _use_ it for)... that's _entirely_ within the TC's purview.
At an even higher level of abstraction, deciding what OpenStack is and
what the Foundation is for, the TC has at least a significant role in
giving input to the board and delegated authority to make decisions in
some areas. Notably, discussions at this level often occur face-to-face
at TC-only events, or at board meetings where non-members aren't
entitled to speak, and which few people can and even fewer people do
attend. (I've given up a few Sunday afternoons before OpenStack Summits
that I could have spent exploring exciting foreign cities to watch the
joint TC-Board meeting, but the probability of my manager giving my
budget for a special trip to a board meeting to just listen is exactly
zero.) I'm not complaining about that, but it does make it important
that TC members themselves are capable of representing a wide range of
interests - it's not always the case that expertise will be pulled in
from the wider community automatically.
Anyway, those are all design problems in my view.
cheers,
Zane.
__________________________________________________________________________
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
