[openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

Zane Bitter zbitter at redhat.com
Wed Oct 18 18:11:11 UTC 2017


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.



More information about the OpenStack-dev mailing list