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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev