On 29/07/2016 21:59, Doug Hellmann wrote: > One of the outcomes of the discussion at the leadership training > session earlier this year was the idea that the TC should set some > community-wide goals for accomplishing specific technical tasks to > get the projects synced up and moving in the same direction. > > After several drafts via etherpad and input from other TC and SWG > members, I've prepared the change for the governance repo [1] and > am ready to open this discussion up to the broader community. Please > read through the patch carefully, especially the "goals/index.rst" > document which tries to lay out the expectations for what makes a > good goal for this purpose and for how teams are meant to approach > working on these goals. > > I've also prepared two patches proposing specific goals for Ocata > [2][3]. I've tried to keep these suggested goals for the first > iteration limited to "finish what we've started" type items, so > they are small and straightforward enough to be able to be completed. > That will let us experiment with the process of managing goals this > time around, and set us up for discussions that may need to happen > at the Ocata summit about implementation. > > For future cycles, we can iterate on making the goals "harder", and > collecting suggestions for goals from the community during the forum > discussions that will happen at summits starting in Boston. > > Doug > > [1] https://review.openstack.org/349068 describe a process for managing > community-wide goals > [2] https://review.openstack.org/349069 add ocata goal "support python 3.5" > [3] https://review.openstack.org/349070 add ocata goal "switch to oslo > libraries"
I am confused. When I proposed my patch for doing something very similar (Equal Chances for all projects is basically a multiple release goal) I got the following rebuttals: > "and it would be > a mistake to try to require that because the issue is almost always > lack of resources and not lack of desire. Volunteers to contribute > to the work that's needed will do more to help than a > one-size-fits-all policy." > This isn't a thing that gets fixed with policy. It gets fixed with > people. > I am reading through the thread, and it puzzles me that I see a lot > of right words about goals but not enough hints on who is going to > implement that. > I think the right solutions here are human ones. Talk with people. > Figure out how you can help lighten their load so that they have > breathing space. I think hiding behind policy becomes a way to make > us more separate rather than engaging folks more directly. > Coming at this with top down declarations of how things should work > not only ignores reality of the ecosystem and the current state of > these projects, but is also going about things backwards. > This entirely ignores that these are all open source projects, > which are often very sparsely contributed to. If you have an issue > with a project or the interface it provides, then contribute to it. > Don't make grandiose resolutions trying to force things into what you > see as an ideal state, instead contribute to help fix the problems > you've identified. And yet, we are currently suggesting a system that will actively (in an undefined way) penalise projects who do not comply with a different set of proposals, done in a top down manner. I may be missing the point, but the two proposals seem to have similarities - what is the difference? When I see comments like: > Project teams who join the big tent sign up to the rights and > responsibilities that go along with membership. Those responsibilities > include taking some direction from the TC, including regarding work > they may not give the same priority as the broader community. It sounds like top down is OK, but previous ML thread / TC feedback has been different. - Graham > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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
