<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 13, 2017 at 9:21 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
Most of the candidates are essentially saying that the answer is 'everyone'.<br>
<br>
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.<br>
<br>
All sarcasm aside though, 'everyone' is a BS non-answer. It's the politician's answer.<br>
<br>
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.<br>
<br>
As an example, look at the Keystone discussion that I linked below.<br>
- If you were designing Keystone for an individual user, you'd might just have one account per tenant.<br>
- 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.<br>
- 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.<br>
<br>
One of these solutions works for both individuals and teams. The other two only work for individuals. As an added bonus, one of those is also expensive to develop and hard to operate. That's why we should design for someones, not for 'everyone'. This is not a problem limited to Keystone - throughout OpenStack we often fail to develop solutions that can actually be used by the people whom we say we're building them for, IMHO.<br>
<br>
I'm not asking y'all to say that some group of end-users is unimportant even though the question is trying to keep the bar extremely low by asking about only one group. Nor am I asking y'all to say that operators are unimportant, even though the question is *explicitly* *NOT* about operators.<br>
<br>
I'm asking if you can describe, to a modest level of detail, even one *end* user persona for OpenStack that you're familiar enough with to be comfortable advocating for on the TC.<br>
<br>
So far the answer I'm hearing mostly translates as 'no'. (Props to the folks who did actually answer though!) Does anybody want to try again?<br>
<br>
cheers,<br>
Zane.<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
On 12/10/17 12:51, Zane Bitter wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In my head, I have a mental picture of who I'm building OpenStack for. When I'm making design decisions I try to think about how it will affect these hypothetical near-future users. By 'users' here I mean end-users, the actual consumers of OpenStack APIs. What will it enable them to do? What will they have to work around? I think we probably all do this, at least subconsciously. (Free tip: try doing it consciously.)<br>
<br>
So my question to the TC candidates (and incumbent TC members, or anyone else, if they want to answer) is: what does the hypothetical OpenStack user that is top-of-mind in your head look like? Who are _you_ building OpenStack for?<br>
<br>
There's a description of mine in this email, as an example:<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2017-October/123312.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pip<wbr>ermail/openstack-dev/2017-Octo<wbr>ber/123312.html</a><br>
<br>
To be clear, for me at least there's only one wrong answer ("person who needs somewhere to run their IRC bouncer"). What's important in my opinion is that we have a bunch of people with *different* answers on the TC, because I think that will lead to better discussion and hopefully better decisions.<br>
<br>
Discuss.<br>
<br>
cheers,<br>
Zane.<br>
</blockquote>
<br></div></div></blockquote><div>What an interesting thread this has been. Thanks to Doug for speaking up - it's unfair to pose a very general question, say "there are no wrong answers", and then call everyone out for getting the answer wrong.</div><div><br></div><div>It's still a good question, though, since it was designed to expose the fact that most of us are building clouds for operators, not for the end-users. Certainly I'll admit that the majority of "users" I talk to as a deployer developer are the cloud operators, not their customers.</div><div><br></div><div>To answer your rephrased question, the end-users I think about most are scientists at research and educational institutions, who are often sharing resources between their sister institutions and public clouds. These researchers are competent with Python because of its scientific applications but most would not classify themselves as "developers". They can't spend time adjusting their scripts to work on different clouds, that would take time away from their research goals. For these people, identity federation is incredibly important, as is interoperability. That is who I try to think about when working on keystone.</div><div><br></div><div>Colleen</div></div></div></div>