On Tue, Aug 2, 2016 at 11:29 AM, Thierry Carrez <thie...@openstack.org> wrote: > > Doug Hellmann wrote: > > [...] > >> Likewise, what if the Manila project team decides they aren't interested > >> in supporting Python 3.5 or a particular greenlet library du jour that > >> has been mandated upon them? Is the only filesystem-as-a-service project > >> going to be booted from the tent? > > > > I hardly think "move off of the EOL-ed version of our language" and > > "use a library du jour" are in the same class. All of the topics > > discussed so far are either focused on eliminating technical debt > > that project teams have not prioritized consistently or adding > > features that, again for consistency, are deemed important by the > > overall community (API microversioning falls in that category, > > though that's an example and not in any way an approved goal right > > now). > > Right, the proposal is pretty clearly about setting a number of > reasonable, small goals for a release cycle that would be awesome to > collectively reach. Not really invasive top-down design mandates that we > would expect teams to want to resist. > > IMHO if a team has a good reason for not wanting or not being able to > fulfill a common goal that's fine -- it just needs to get documented and > should not result in itself in getting kicked out from anything. If a > team regularly skips on common goals (and/or misses releases, and/or > doesn't fix security issues) that's a general sign that it's not really > behaving like an OpenStack project and then a case could be opened for > removal, but there is nothing new here. >
+1 to all of this. As someone who was in leadership training with both Thierry and Doug, I just want to point out that 'reasonable, small goals' and 'support a particular library du jour or get kicked out of OpenStack' are immensely different reads on the potential of this situation. OpenStack suffers from a perception that it is not a usable, cohesive set of projects that work together. Like many perceptions out in the wild about OSS projects, that is part PR/spin/haters-gonna-hate, and part reality. Apart from PR-land, the idea of having some basic standards and cross-project goals to meet not just before a project is accepted, but also as it matures, hopefully serves the ultimate purpose of presenting an OpenStack with enough consistency and usability that it doesn't make a user/operator want to throw a server out the window. Where does the technical independence of a project begin encroaching on the ability of other projects to effectively work for their users or their developer participation? Where do the desires of a single project begin to negatively impact the entirety of OpenStack, and how does the community respond when faced with tough situations like that? The TC, as a body that oversees the overarching technical direction of the entire group of projects, has identified areas where OpenStack could be *highly* improved in its functionality and usability - those certainly, on their surface, seem like noble goals for any person creating any project with an end user that is not themselves. That the TC is the mechanism to do that unifying, helpful, future-preserving thing for OpenStack and also the same mechanism that, in the wrong hands, could be used to ask impossible things of projects (and use their failure to kick them out of the community, eventually) is totally true, but it's also always been true of the TC. That's why preserving our culture of leadership by election is so important - leaders are elected to serve their constituents - *not* the other way around. -colette/gothicmindfood __________________________________________________________________________ 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