Re: [openstack-dev] [all][tc] establishing project-wide goals
I'm on the same page as Doug here. On 08/01/2016 04:23 PM, Jay Pipes wrote: > Likewise, what if the Manila project team decides they aren't interested > in supporting Python 3.5 Any project that is actively deciding to not support the current version of Python must indeed be kicked out, as it becomes not maintainable (it downstream distros or otherwise). On 08/01/2016 04:23 PM, Jay Pipes wrote: > or a particular greenlet library du jour That's another story which can be debated, IMO. Cheers, Thomas Goirand (zigo) __ 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
On 07/29/2016 10:55 PM, 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" Thanks a lot for working on this. Everything is well thought. Just one thing, probably, "release goal" would be a better fit for naming this, so that it puts the emphasis on deliverables. Cheers, Thomas Goirand (zigo) __ 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
On Tue, Aug 2, 2016 at 11:29 AM, Thierry Carrez 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
On 02/08/16 17:29 +0200, Thierry Carrez 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. I think some flexibility on this should be considered (as mentioned by Thierry in the previous paragraph) but I'd be quite worried of extremely special-cased projects and I'd like us to be able to act on this cases. Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
Excerpts from Jay Pipes's message of 2016-08-01 10:23:57 -0400: > On 08/01/2016 08:33 AM, Sean Dague wrote: > > On 07/29/2016 04:55 PM, 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 like the direction this is headed. And I think for the test items, it > > works pretty well. > > I commented on the reviews, but I disagree with both the direction and > the proposed implementation of this. > > In short, I think there's too much stick and not enough carrot. We > should create natural incentives for projects to achieve desired > alignment in certain areas, but placing mandates on project teams in a > diverse community like OpenStack is not useful. > > The consequences of a project team *not* meeting these proposed mandates > has yet to be decided (and I made that point on the governance patch > review). But let's say that the consequences are that a project is > removed from the OpenStack big tent if they fail to complete these > "shared objectives". > > What will we do when Swift decides that they have no intention of using > oslo.messaging or oslo.config because they can't stand fundamentals > about those libraries? Are we going to kick Swift, a founding project of > OpenStack, out of the OpenStack big tent? Membership in the tent is the carrot, and ejection is the stick. The big tent was an acknowledgement that giving out carrots makes everyone stronger (all these well fed projects have led to a bigger supply of carrots in general). I think this proposal is an attempt to manage the ensuing chaos. We've all seen carrot farmers abandon their farms, as well as duplicated effort leading to a confusing experience for consumers of OpenStack's products. I think there's room to build consensus around diversity in implementation and even culture. We don't need to be a monolith. Our Swift development community is bringing strong, powerful insight to the overall effort, and strengthens the OpenStack brand considerably. Certainly we can support projects doing things their own way in some instances if they so choose. What we don't want, however, is projects that operate in relative isolation, without any cohesion, even loose cohesion, with the rest. __ 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
Excerpts from Hayes, Graham's message of 2016-08-02 16:30:06 +: > On 02/08/2016 16:37, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +: > >> On 02/08/2016 14:37, Doug Hellmann wrote: > >>> Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +: > 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. > >>> > >>> One difference is that these goals are not things like "the > >>> documentation team must include every service project in the > >>> installation guide" but rather would be phrased like "every project > >>> must provide an installation guide". The work
Re: [openstack-dev] [all][tc] establishing project-wide goals
On 02/08/2016 16:37, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +: >> On 02/08/2016 14:37, Doug Hellmann wrote: >>> Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +: 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. >>> >>> One difference is that these goals are not things like "the >>> documentation team must include every service project in the >>> installation guide" but rather would be phrased like "every project >>> must provide an installation guide". The work is distributed to the >>> vertical teams, and not focused in the horizontal teams. >> >> Well, the wording was actually "the documentation team must provide a >> way for all projects to be included in the documentation guide". The >> work was on the hori
Re: [openstack-dev] [all][tc] establishing project-wide goals
On 08/02/2016 11:29 AM, Thierry Carrez 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. Sure, I have no disagreement with any of the above. I just see TC mandates as a slippery slope. I'm practicing my OpenStack civic "duty" to guard against the encroachment of project technical independence. Best, -jay __ 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +: > On 02/08/2016 14:37, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +: > >> 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. > > > > One difference is that these goals are not things like "the > > documentation team must include every service project in the > > installation guide" but rather would be phrased like "every project > > must provide an installation guide". The work is distributed to the > > vertical teams, and not focused in the horizontal teams. > > Well, the wording was actually "the documentation team must provide a > way for all projects to be included in the documentation guide". The > work was on the horizontal teams to provide a method, and the vertic
Re: [openstack-dev] [all][tc] establishing project-wide goals
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. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
On 02/08/2016 14:37, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +: >> 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. > > One difference is that these goals are not things like "the > documentation team must include every service project in the > installation guide" but rather would be phrased like "every project > must provide an installation guide". The work is distributed to the > vertical teams, and not focused in the horizontal teams. Well, the wording was actually "the documentation team must provide a way for all projects to be included in the documentation guide". The work was on the horizontal teams to provide a method, and the vertical teams to do the actual writing, as an example (that is actually underway, so it is a bad example.) A better example would be OSC / Horizon has to provide a way for plugins to set quotas - it is up to the project teams to actually implement the code the sets quo
Re: [openstack-dev] [all][tc] establishing project-wide goals
Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +: > 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. One difference is that these goals are not things like "the documentation team must include every service project in the installation guide" but rather would be phrased like "every project must provide an installation guide". The work is distributed to the vertical teams, and not focused in the horizontal teams. Doug > > - 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
Excerpts from Shamail's message of 2016-08-01 22:37:28 -0500: > Thanks Doug, > > > On Aug 1, 2016, at 10:44 AM, Doug Hellmann wrote: > > > > Excerpts from Shamail Tahir's message of 2016-08-01 09:49:35 -0500: > >>> On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann > >>> wrote: > >>> > >>> Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400: > > On 07/29/2016 04:55 PM, 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 like the direction this is headed. And I think for the test items, it > works pretty well. > > I'm trying to think about how we'd use a model like this to support > something a little more abstract such as making upgrades easier. Where > we've got a few things that we know get in the way (policy in files, > rootwrap rules, paste ini changes), as well as validation, as well as > configuration changes. And what it looks like for persistently important > items which are going to take more than a cycle to get through. > >>> > >>> If we think the goal can be completed in a single cycle, then those > >>> specific items can just be used to define "done" ("all policy > >>> definitions have defaults in code and the service works without a policy > >>> configuration file" or whatever). If the goal cannot be completed in a > >>> single cycle, then it would need to be broken up in to phases. > >>> > > Definitely seems worth giving it a shot on the current set of items, and > see how it fleshes out. > > My only concern at this point is it seems like we're building nested > data structures that people are going to want to parse into some kind of > visualization in RST, which is a sub optimal parsing format. If we know > that people want to parse this in advance, yamling it up might be in > order. Because this mostly looks like it would reduce to one of those > green/yellow/red checker boards by project and task. > >>> > >>> That's a good idea. How about if I commit to translate what we end > >>> up with to YAML during Ocata, but we evolve the first version using > >>> the RST since that's simpler to review for now? > >> > >> We have created a tracker file[1][2] for user stories (minor changes > >> pending based on feedback) in the Product WG repo. We are currently > >> working with the infra team to get a visualization tool deployed that shows > >> the status for each artifact and provides links so that people can get more > >> details as necessary. Could something similar be (re)used here? > > > > Possibly. I don't want to tie the governance part of the process > > to tightly to any project management tools, since those tend to > > change, but if the project-specific tracking artifacts exist in > > that form then linking to them would be appropriate. > The purpose of the tracking is to link existing project-level artifacts > including cross project specs and service level specs/blueprints. Once the > tool is deployed, we can see if it fits this need. > > > >> > >> I also have a general question about whether goals could be documented as > >> user stories[3]? > > > > I would expect some of t
Re: [openstack-dev] [all][tc] establishing project-wide goals
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
Re: [openstack-dev] [all][tc] establishing project-wide goals
Thanks Doug, > On Aug 1, 2016, at 10:44 AM, Doug Hellmann wrote: > > Excerpts from Shamail Tahir's message of 2016-08-01 09:49:35 -0500: >>> On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann wrote: >>> >>> Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400: > On 07/29/2016 04:55 PM, 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 like the direction this is headed. And I think for the test items, it works pretty well. I'm trying to think about how we'd use a model like this to support something a little more abstract such as making upgrades easier. Where we've got a few things that we know get in the way (policy in files, rootwrap rules, paste ini changes), as well as validation, as well as configuration changes. And what it looks like for persistently important items which are going to take more than a cycle to get through. >>> >>> If we think the goal can be completed in a single cycle, then those >>> specific items can just be used to define "done" ("all policy >>> definitions have defaults in code and the service works without a policy >>> configuration file" or whatever). If the goal cannot be completed in a >>> single cycle, then it would need to be broken up in to phases. >>> Definitely seems worth giving it a shot on the current set of items, and see how it fleshes out. My only concern at this point is it seems like we're building nested data structures that people are going to want to parse into some kind of visualization in RST, which is a sub optimal parsing format. If we know that people want to parse this in advance, yamling it up might be in order. Because this mostly looks like it would reduce to one of those green/yellow/red checker boards by project and task. >>> >>> That's a good idea. How about if I commit to translate what we end >>> up with to YAML during Ocata, but we evolve the first version using >>> the RST since that's simpler to review for now? >> >> We have created a tracker file[1][2] for user stories (minor changes >> pending based on feedback) in the Product WG repo. We are currently >> working with the infra team to get a visualization tool deployed that shows >> the status for each artifact and provides links so that people can get more >> details as necessary. Could something similar be (re)used here? > > Possibly. I don't want to tie the governance part of the process > to tightly to any project management tools, since those tend to > change, but if the project-specific tracking artifacts exist in > that form then linking to them would be appropriate. The purpose of the tracking is to link existing project-level artifacts including cross project specs and service level specs/blueprints. Once the tool is deployed, we can see if it fits this need. > >> >> I also have a general question about whether goals could be documented as >> user stories[3]? > > I would expect some of the goals to come from user stories, and in > those cases references to those stories would be appropriate. > However, we need much more specific detail to describe "done" than > is typically found in a user story, so just having a story won't > be suffici
Re: [openstack-dev] [all][tc] establishing project-wide goals
Excerpts from Jay Pipes's message of 2016-08-01 10:23:57 -0400: > On 08/01/2016 08:33 AM, Sean Dague wrote: > > On 07/29/2016 04:55 PM, 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 like the direction this is headed. And I think for the test items, it > > works pretty well. > > I commented on the reviews, but I disagree with both the direction and > the proposed implementation of this. > > In short, I think there's too much stick and not enough carrot. We > should create natural incentives for projects to achieve desired > alignment in certain areas, but placing mandates on project teams in a > diverse community like OpenStack is not useful. > > The consequences of a project team *not* meeting these proposed mandates > has yet to be decided (and I made that point on the governance patch > review). But let's say that the consequences are that a project is > removed from the OpenStack big tent if they fail to complete these > "shared objectives". > > What will we do when Swift decides that they have no intention of using > oslo.messaging or oslo.config because they can't stand fundamentals > about those libraries? Are we going to kick Swift, a founding project of > OpenStack, out of the OpenStack big tent? Yes, your point about the title of that specific proposal is well made. I'll be renaming it to "remove obsolete incubated version of Oslo code" or something similar in the next draft to avoid confusion. > 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). > When it comes to the internal implementation of projects, my strong > belief is that we should let the project teams be laboratories of > innovation and avoid placing mandates on them. > > Let projects choose from a set of vetted options for important libraries > or frameworks and allow a project to pave its own road if the project > team can justify a reason for that which outweighs any vetted choice > (Zaqar's choice to use Falcon fits this kind of thing). We might have a goal that says projects should drop unapproved tools. I don't think so far we've considered any that say they should all use a specific tool that isn't already widely used. I'm having trouble thinking of an example of that sort of thing that I would support, but at the same time I'm not prepared to say we would never do something like that just because of my lack of imagination this morning. How about if we argue the merits of actual goal proposals when they're made, instead of posing hypothetical scenarios? > Finally, instead of these shared OpenStack-wide goals being a different > stick-thing for the
Re: [openstack-dev] [all][tc] establishing project-wide goals
Excerpts from Shamail Tahir's message of 2016-08-01 09:49:35 -0500: > On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann wrote: > > > Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400: > > > On 07/29/2016 04:55 PM, 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 like the direction this is headed. And I think for the test items, it > > > works pretty well. > > > > > > I'm trying to think about how we'd use a model like this to support > > > something a little more abstract such as making upgrades easier. Where > > > we've got a few things that we know get in the way (policy in files, > > > rootwrap rules, paste ini changes), as well as validation, as well as > > > configuration changes. And what it looks like for persistently important > > > items which are going to take more than a cycle to get through. > > > > If we think the goal can be completed in a single cycle, then those > > specific items can just be used to define "done" ("all policy > > definitions have defaults in code and the service works without a policy > > configuration file" or whatever). If the goal cannot be completed in a > > single cycle, then it would need to be broken up in to phases. > > > > > > > > Definitely seems worth giving it a shot on the current set of items, and > > > see how it fleshes out. > > > > > > My only concern at this point is it seems like we're building nested > > > data structures that people are going to want to parse into some kind of > > > visualization in RST, which is a sub optimal parsing format. If we know > > > that people want to parse this in advance, yamling it up might be in > > > order. Because this mostly looks like it would reduce to one of those > > > green/yellow/red checker boards by project and task. > > > > That's a good idea. How about if I commit to translate what we end > > up with to YAML during Ocata, but we evolve the first version using > > the RST since that's simpler to review for now? > > We have created a tracker file[1][2] for user stories (minor changes > pending based on feedback) in the Product WG repo. We are currently > working with the infra team to get a visualization tool deployed that shows > the status for each artifact and provides links so that people can get more > details as necessary. Could something similar be (re)used here? Possibly. I don't want to tie the governance part of the process to tightly to any project management tools, since those tend to change, but if the project-specific tracking artifacts exist in that form then linking to them would be appropriate. > > I also have a general question about whether goals could be documented as > user stories[3]? I would expect some of the goals to come from user stories, and in those cases references to those stories would be appropriate. However, we need much more specific detail to describe "done" than is typically found in a user story, so just having a story won't be sufficient. It's the difference between "As a deployer, I can run OpenStack on Python 3.5" and "There are voting gate jobs running all of the integration tests for a project under Python 3.5." Doug > > > > > > Doug > > > > > > > > -Sean > >
Re: [openstack-dev] [all][tc] establishing project-wide goals
On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400: > > On 07/29/2016 04:55 PM, 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 like the direction this is headed. And I think for the test items, it > > works pretty well. > > > > I'm trying to think about how we'd use a model like this to support > > something a little more abstract such as making upgrades easier. Where > > we've got a few things that we know get in the way (policy in files, > > rootwrap rules, paste ini changes), as well as validation, as well as > > configuration changes. And what it looks like for persistently important > > items which are going to take more than a cycle to get through. > > If we think the goal can be completed in a single cycle, then those > specific items can just be used to define "done" ("all policy > definitions have defaults in code and the service works without a policy > configuration file" or whatever). If the goal cannot be completed in a > single cycle, then it would need to be broken up in to phases. > > > > > Definitely seems worth giving it a shot on the current set of items, and > > see how it fleshes out. > > > > My only concern at this point is it seems like we're building nested > > data structures that people are going to want to parse into some kind of > > visualization in RST, which is a sub optimal parsing format. If we know > > that people want to parse this in advance, yamling it up might be in > > order. Because this mostly looks like it would reduce to one of those > > green/yellow/red checker boards by project and task. > > That's a good idea. How about if I commit to translate what we end > up with to YAML during Ocata, but we evolve the first version using > the RST since that's simpler to review for now? We have created a tracker file[1][2] for user stories (minor changes pending based on feedback) in the Product WG repo. We are currently working with the infra team to get a visualization tool deployed that shows the status for each artifact and provides links so that people can get more details as necessary. Could something similar be (re)used here? I also have a general question about whether goals could be documented as user stories[3]? > > Doug > > > > > -Sean > > > > __ > 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 > -- Thanks, Shamail Tahir t: @ShamailXD tz: Eastern Time [1] https://github.com/openstack/openstack-user-stories/blob/master/doc/source/tracker_overview.rst [2] https://github.com/openstack/openstack-user-stories/blob/master/user-story-tracker.json [3] https://github.com/openstack/openstack-user-stories/blob/master/user-story-template.rst __ 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
On 08/01/2016 08:33 AM, Sean Dague wrote: On 07/29/2016 04:55 PM, 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 like the direction this is headed. And I think for the test items, it works pretty well. I commented on the reviews, but I disagree with both the direction and the proposed implementation of this. In short, I think there's too much stick and not enough carrot. We should create natural incentives for projects to achieve desired alignment in certain areas, but placing mandates on project teams in a diverse community like OpenStack is not useful. The consequences of a project team *not* meeting these proposed mandates has yet to be decided (and I made that point on the governance patch review). But let's say that the consequences are that a project is removed from the OpenStack big tent if they fail to complete these "shared objectives". What will we do when Swift decides that they have no intention of using oslo.messaging or oslo.config because they can't stand fundamentals about those libraries? Are we going to kick Swift, a founding project of OpenStack, out of the OpenStack big tent? 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? When it comes to the internal implementation of projects, my strong belief is that we should let the project teams be laboratories of innovation and avoid placing mandates on them. Let projects choose from a set of vetted options for important libraries or frameworks and allow a project to pave its own road if the project team can justify a reason for that which outweighs any vetted choice (Zaqar's choice to use Falcon fits this kind of thing). Finally, instead of these shared OpenStack-wide goals being a different stick-thing for the TC to use, why not just make tags that projects can *choose* to pursue, therefore building in the incentive (as opposed to the punishment) to align with a direction the TC feels is a good one. You could have tags like: supports:python-3.5 or supports:oslo-only or things like that. Project teams could then endeavour to achieve said tags if they feel that such a tag absolutely aligns with the team's goals. Just my two cents, -jay I'm trying to think about how we'd use a model like this to support something a little more abstract such as making upgrades easier. Where we've got a few things that we know get in the way (policy in files, rootwrap rules, paste ini changes), as well as validation, as well as configuration changes. And what it looks like for persistently important items which are going to take more than a cycle to get through. Definitely seems worth giving it a shot on the current set of items, and see how it fleshes out. My only concern at this point is it seems like we're building nested data structures that people are going to want to parse into some kind of visualization in RST, which is a sub optimal parsing format. If we know that people want to parse this in advance, yamling it up might be in order. Because this mostly looks like it would reduce to one of those green/yellow/red checker boards by project and task. -Sean __ OpenStack Development Mailing L
Re: [openstack-dev] [all][tc] establishing project-wide goals
Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400: > On 07/29/2016 04:55 PM, 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 like the direction this is headed. And I think for the test items, it > works pretty well. > > I'm trying to think about how we'd use a model like this to support > something a little more abstract such as making upgrades easier. Where > we've got a few things that we know get in the way (policy in files, > rootwrap rules, paste ini changes), as well as validation, as well as > configuration changes. And what it looks like for persistently important > items which are going to take more than a cycle to get through. If we think the goal can be completed in a single cycle, then those specific items can just be used to define "done" ("all policy definitions have defaults in code and the service works without a policy configuration file" or whatever). If the goal cannot be completed in a single cycle, then it would need to be broken up in to phases. > > Definitely seems worth giving it a shot on the current set of items, and > see how it fleshes out. > > My only concern at this point is it seems like we're building nested > data structures that people are going to want to parse into some kind of > visualization in RST, which is a sub optimal parsing format. If we know > that people want to parse this in advance, yamling it up might be in > order. Because this mostly looks like it would reduce to one of those > green/yellow/red checker boards by project and task. That's a good idea. How about if I commit to translate what we end up with to YAML during Ocata, but we evolve the first version using the RST since that's simpler to review for now? Doug > > -Sean > __ 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
On 07/29/2016 04:55 PM, 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 like the direction this is headed. And I think for the test items, it works pretty well. I'm trying to think about how we'd use a model like this to support something a little more abstract such as making upgrades easier. Where we've got a few things that we know get in the way (policy in files, rootwrap rules, paste ini changes), as well as validation, as well as configuration changes. And what it looks like for persistently important items which are going to take more than a cycle to get through. Definitely seems worth giving it a shot on the current set of items, and see how it fleshes out. My only concern at this point is it seems like we're building nested data structures that people are going to want to parse into some kind of visualization in RST, which is a sub optimal parsing format. If we know that people want to parse this in advance, yamling it up might be in order. Because this mostly looks like it would reduce to one of those green/yellow/red checker boards by project and task. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [all][tc] establishing project-wide goals
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 > 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 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-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