Doug, Thanks for doing this. In the interests of transparency and full disclosure, I was at the leadership training and heard about this idea there (and was strongly in favor of it then, as I am now).
I think it is very important that OpenStack not devolve into a loose confederation of bags of code that are governed in similar ways, but rather a collection of software that address a set of meaningful needs in a consistent and compatible way. The goal is that to operators and deployers, OpenStack is a platform consisting of projects that work well together (the thing I called 'consistent and compatible' earlier). I see from the comments in the review [1] that there is some concern about the section on 'acknowledgement'. Of what material benefit is it if the TC were to mandate something and the communication to the projects is some open-loop process? The 'acknowledgement' that Doug refers to in the review is merely a mechanism to 'close' that loop and ensure that projects affirm that they have been informed of the project wide goals, and that the PTL's will take some concrete steps that can be tracked through our usual processes (bugs, reviews, and so on) to ensure that the mandates are met. To a more coherent and consistent platform! -amrith > -----Original Message----- > From: Doug Hellmann [mailto:d...@doughellmann.com] > Sent: Friday, July 29, 2016 4:55 PM > To: openstack-dev <openstack-...@lists.openstack.org> > Subject: [openstack-dev] [all][tc] establishing project-wide goals > > 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" > > __________________________________________________________________________ > 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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
