[openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?
doug at doughellmann.com
Tue Oct 17 18:16:41 UTC 2017
Excerpts from Zane Bitter's message of 2017-10-16 18:10:20 -0400:
> On 14/10/17 11:47, Doug Hellmann wrote:
> > Excerpts from Zane Bitter's message of 2017-10-13 15:21:14 -0400:
> >> Replying to myself here, to avoid singling anyone in particular out. I
> >> want to rephrase the question, because people are overwhelmingly either
> >> failing to understand or refusing to answer it in the way I intended it.
> >> Most of the candidates are essentially saying that the answer is 'everyone'.
> >> I'm glad that we have such a bunch of next-level geniuses running for
> >> the TC that they are able to analyse the needs of all 7 billion people
> >> and evaluate every decision they make against all of them in real time.
> >> Me, I'm just an ordinary guy who can only hold a few things in his head
> >> at once, so I just try to focus on those and collaborate with people who
> >> have different perspectives to make sure that a range of needs are
> >> covered. This is kind of the founding principle of the Open Source
> >> (note: not Free Software) movement, actually. None of us is as smart as
> >> all of us (present company excepted, apparently). So it's good, but
> >> somewhat surprising that y'all are still here, given that you would be
> >> guaranteed insta-billionaires if you went out and started a proprietary
> >> software company.
> >> All sarcasm aside though, 'everyone' is a BS non-answer. It's the
> >> politician's answer.
> > Blaming the respondents for answering a imprecisely worded question
> > in a way other than it was intended? We can do better.
> I honestly didn't feel it was an imprecisely worded question - I
> included an example, and carefully defined things such as "By 'users'
> here I mean end-users, the actual consumers of OpenStack APIs".
> Nevertheless, I have no problem admitting that I was wrong. Allowing for
> that possibility was the reason I rephrased the question.
> > Your original question "Who are _you_ building OpenStack for?" was
> > much more vague than the rephrasing below that specifically asks
> > about advocacy.
> I agree, reading your and Ildiko's and James's responses it's now clear
> to me that this was the root of the problem. It was too easy to
> interpret this as the entirety of the question, rather than just a glib
> way of summing up the actual question immediately preceding it, the
> paragraph of exposition before that, and the example that followed. I
> regret muddying the waters by tacking it on the end.
> > 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.
> >> Not only because engineering trade-offs are a real thing, and some use
> >> cases will *definitely* be excluded in order to better serve others, but
> >> because the average user doesn't exist. If you design for the 'average'
> >> user then you are designing for nobody, because nobody is the average
> >> user. We shouldn't be designing for 'everybody' (aka nobody in
> >> particular), but for a large variety of somebodies.
> >> As an example, look at the Keystone discussion that I linked below.
> >> - If you were designing Keystone for an individual user, you'd might
> >> just have one account per tenant.
> >> - If you were designing Keystone for a team deploying semi-autonomous
> >> apps, you might design a way for multiple agents to authenticate to each
> >> tenant.
> >> - If you were designing Keystone for 'everyone', you might have a matrix
> >> of users, tenants and roles - the most generic solution, right? - and
> >> spend half a decade polishing it without ever realising that individual
> >> users don't need it and teams can't use it.
> > Or you might conclude that the real problem isn't in the identity
> > service data model, but in the services that don't yet have an
> > operation to transfer ownership of resources when a user is
> > deactivated.
> Sure, although note that Keystone itself would have to be one of those
> services - you'd have to be able to transfer ownership of trusts for it
> to work.
Sure. I think changing ownership is a new concept across the board.
> 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?
> Specifically, nobody should take it, or anything else that fits in 3
> sentences, as a prescription for the successful design of an identity
> management service - a topic which is vast, complex, intricate, and at
> times highly unintuitive.
>  https://en.wikipedia.org/wiki/User-centered_design
More information about the OpenStack-dev