Open Stack

"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."

Interestingly (and without wanting to derail the overall subject) but this
is precisely what is done by a certain individuals seeking a seat on the
board of directors. And the funny thing is that while the board of
directors is not about representing one bloc of geography, campaigning on
that issue is very effective. The tactic is gratuitous but I guess some
people highly prioritize board membership as an achievement rather than a
service to the community.

/soapbox

//adam

On Oct 18, 2017 11:11 AM, "Zane Bitter" <zbitter at redhat.com> wrote:

> 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.o
> rg/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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171019/96cccb6f/attachment.html>