[openstack-dev] [all][tc][ptl] establishing project-wide goals

Clint Byrum clint at fewbar.com
Sat Aug 13 14:11:51 UTC 2016

Excerpts from John Dickinson's message of 2016-08-12 13:02:59 -0700:
> On 12 Aug 2016, at 7:28, Doug Hellmann wrote:
> > Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700:
> >>
> >
> >> I agree with Hongbin Lu's comments that the resulting goals might fit
> >> into the interests of the majority but fundamentally violate the
> >> interests of a minority of project teams. As an example, should the TC
> >> decide that a future goal is for projects to implement a particular
> >> API-WG document, that may be good for several projects, but it might
> >> not be possible or advisable for others.
> >
> > Again, the goals are not coming from the TC, they are coming from the
> > entire community. There will be discussion sessions, mailing list
> > threads, experimentation, etc. before any goal is settled on. By the
> > time the goals for a given cycle are picked, everyone will have had a
> > chance to give input. That's why I'm starting this conversation now, so
> > far in advance of the summit.
> This is good, and the importance and difficulty of this is not lost on
> me. I'm very glad you've included community feedback as part of the
> process.
> But if a project is on the minority side of the resulting concensus,
> how do we protect that project from being negatively affected? Even if
> there are good reasons at the time for a project to not support a
> goal, that dissent can come back against the project negatively, even
> years down the road after those who dissented have left. I know this
> from experience.

There is no minority side of a consensus. If you can't support that goal,
it's not a community goal.

I know it's mind blowing, but the idea is that we actually all agree that
we all should exist, and have an important shared responsibility to one
another under the OpenStack banner. Rather than a divisive voting system
where we can chuck our desires at the wall, and point fingers when more
people have different desires, the TC has a radical idea. They'd like
to actually try and have OpenStack build OpenStack _together_.

There's still a position that gives more than others. This is not an
equilibrium. Some projects will have more time than others to complete
these goals. But the point of a consensus is that we can actually find
things that we can all commit to doing. And if we can't find those things,
we should spend more time figuring out why.

This isn't fairy tales and rainbows. It's human communication. We
actually need to spend time listening to one another here. If a project
team is feeling the pressure to gain more adoption so greatly that they
simply cannot commit to a goal, then the community should hear that,
and respect it. Don't make that a community goal, even if the teams that
want it go ahead with activities, they can do so with the knowledge that
it is their own, and they cannot expect community-wide support yet.

At the same time, that very busy project team, whomever they may be, needs
to consider the effect their activities have on the greater effort. The
discussion needs to continue, and as unsatisfying as it may feel to have
an open discussion instead of a closed discussion in which there were
winners and losers, it's the burden we're going to bear to be able to
achieve something larger than what a single team can achieve.

I for one believe in this model. I think it will require leaders to step
up and help build consensus. But I think we all know that as loosely
coupled as OpenStack is, there are plenty of ties that bind us together.

We all wear the same t-shirts, and we should act like we want to keep
doing that.

More information about the OpenStack-dev mailing list