Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals
Excerpts from Sean Dague's message of 2016-08-16 10:35:11 -0400: > On 08/16/2016 05:36 AM, Thierry Carrez wrote: > > John Dickinson wrote: > Excerpts from John Dickinson's message of 2016-08-12 16:04:42 -0700: > > [...] > > The proposed plan has a lot of good in it, and I'm really happy to see > > the TC > > working to bring common goals and vision to the entirety of the > > OpenStack > > community. Drop the "project teams are expected to prioritize these > > goals above > > all other work", and my concerns evaporate. I'd be happy to agree to > > that proposal. > > Saying that the community has goals but that no one is expected to > act to bring them about would be a meaningless waste of time and > energy. > >>> > >>> I think we can find wording that doesn't use the word "priority" (which > >>> is, I think, what John objects to the most) while still conveying that > >>> project teams are expected to act to bring them about (once they said > >>> they agreed with the goal). > >>> > >>> How about "project teams are expected to do everything they can to > >>> complete those goals within the boundaries of the target development > >>> cycle" ? Would that sound better ? > >> > >> Any chance you'd go for something like "project teams are expected to > >> make progress on these goals and report that progress to the TC every > >> cycle"? > > > > The issue with this variant is that it removes the direct link between > > the goal and the development cycle. One of the goals of these goals > > (arh) is that we should be able to collectively complete them in a given > > timeframe, so that there is focus at the same time and we have a good > > story to show at the end. Those goals are smallish development cycle > > goals. They are specifically chosen to be complete-able within a cycle > > and with a clear definition of "done". It's what differentiates them > > from more traditional cross-project specs or strategic initiatives which > > can be more long-term (and on which "reporting progress to the TC every > > cycle" could be an option). > > So, I think that's ok. But it's going to cause a least common > denominator of doable. For instance, python 3.5 is probably not doable > in Nova in a cycle. And the biggest issue is really not python 3.5 per > say, but our backlog of mox based unit tests (over a thousand), which > we've experienced are unreliable in odd ways on python3. They also tend > to be the oldest unit tests (we stopped letting people add new ones 2 > years ago), in areas of the code that have a lower rate of change, and > folks are less familiar with (like the xenserver driver which is used by > very few folks). > > So, those are getting tackled, but there is a lot there, and it will > take a while. (Note: this is one of the reasons I suggested the next > step with python3 be full stack testing, because I think we could > actually get Nova working there well in advance of the unit tests > ported, for the above issue. That however requires someone to take on > the work for full stack python3 setup and maintenance.) > Yeah, I don't think we should time-box all goals to one release cycle. Community goals should be real things that the community needs. But we can still set a time frame for a goal, like "O+1", and even try to set objectives that are single-release cycle doable. Like for Ocata we can say "All dependencies are python3.5 compatible and 80% of tests pass on python3.5". Then "Integrated gate passes using pyton3.5 in O+1". Then at the end of each release cycle, we can look at the objectives completed, and consider whether or not the goal is reached, or what we can do to make sure it is. > Maybe this process also can expose "we're going to need help to get > there" for some of these goals. Just like with the architecture working group I've been proposing, I think we need to rally resources around supporting these objectives, otherwise the TC will just sow frustration. __ 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][ptl] establishing project-wide goals
On 08/16/2016 05:36 AM, Thierry Carrez wrote: > John Dickinson wrote: Excerpts from John Dickinson's message of 2016-08-12 16:04:42 -0700: > [...] > The proposed plan has a lot of good in it, and I'm really happy to see > the TC > working to bring common goals and vision to the entirety of the OpenStack > community. Drop the "project teams are expected to prioritize these goals > above > all other work", and my concerns evaporate. I'd be happy to agree to that > proposal. Saying that the community has goals but that no one is expected to act to bring them about would be a meaningless waste of time and energy. >>> >>> I think we can find wording that doesn't use the word "priority" (which >>> is, I think, what John objects to the most) while still conveying that >>> project teams are expected to act to bring them about (once they said >>> they agreed with the goal). >>> >>> How about "project teams are expected to do everything they can to >>> complete those goals within the boundaries of the target development >>> cycle" ? Would that sound better ? >> >> Any chance you'd go for something like "project teams are expected to >> make progress on these goals and report that progress to the TC every >> cycle"? > > The issue with this variant is that it removes the direct link between > the goal and the development cycle. One of the goals of these goals > (arh) is that we should be able to collectively complete them in a given > timeframe, so that there is focus at the same time and we have a good > story to show at the end. Those goals are smallish development cycle > goals. They are specifically chosen to be complete-able within a cycle > and with a clear definition of "done". It's what differentiates them > from more traditional cross-project specs or strategic initiatives which > can be more long-term (and on which "reporting progress to the TC every > cycle" could be an option). So, I think that's ok. But it's going to cause a least common denominator of doable. For instance, python 3.5 is probably not doable in Nova in a cycle. And the biggest issue is really not python 3.5 per say, but our backlog of mox based unit tests (over a thousand), which we've experienced are unreliable in odd ways on python3. They also tend to be the oldest unit tests (we stopped letting people add new ones 2 years ago), in areas of the code that have a lower rate of change, and folks are less familiar with (like the xenserver driver which is used by very few folks). So, those are getting tackled, but there is a lot there, and it will take a while. (Note: this is one of the reasons I suggested the next step with python3 be full stack testing, because I think we could actually get Nova working there well in advance of the unit tests ported, for the above issue. That however requires someone to take on the work for full stack python3 setup and maintenance.) Maybe this process also can expose "we're going to need help to get there" for some of these goals. -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][ptl] establishing project-wide goals
John Dickinson wrote: >>> Excerpts from John Dickinson's message of 2016-08-12 16:04:42 -0700: [...] The proposed plan has a lot of good in it, and I'm really happy to see the TC working to bring common goals and vision to the entirety of the OpenStack community. Drop the "project teams are expected to prioritize these goals above all other work", and my concerns evaporate. I'd be happy to agree to that proposal. >>> >>> Saying that the community has goals but that no one is expected to >>> act to bring them about would be a meaningless waste of time and >>> energy. >> >> I think we can find wording that doesn't use the word "priority" (which >> is, I think, what John objects to the most) while still conveying that >> project teams are expected to act to bring them about (once they said >> they agreed with the goal). >> >> How about "project teams are expected to do everything they can to >> complete those goals within the boundaries of the target development >> cycle" ? Would that sound better ? > > Any chance you'd go for something like "project teams are expected to > make progress on these goals and report that progress to the TC every > cycle"? The issue with this variant is that it removes the direct link between the goal and the development cycle. One of the goals of these goals (arh) is that we should be able to collectively complete them in a given timeframe, so that there is focus at the same time and we have a good story to show at the end. Those goals are smallish development cycle goals. They are specifically chosen to be complete-able within a cycle and with a clear definition of "done". It's what differentiates them from more traditional cross-project specs or strategic initiatives which can be more long-term (and on which "reporting progress to the TC every cycle" could be an option). -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital 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][ptl] establishing project-wide goals
On 15 Aug 2016, at 1:37, Thierry Carrez wrote: > Doug Hellmann wrote: >> [...] >> Choosing to be a part of a community comes with obligations as well >> as benefits. If, after a lengthy discussion of a community-wide >> goal, involving everyone in the community, a project team is >> resolutely opposed to the goal, does that not indicate that the >> needs of the project team and the needs of the broader community >> are at odds in some way? And if the project team's needs and the >> community needs are consistently at odds, over the course of a >> series of such goals, why would the project team want to constrain >> itself to stay in the community? Aren't they clearly going in >> different directions? >> >> Understand, it is not my desire to emphasize any differences of >> this nature. Rather, I want to reduce them. To do that, I am proposing >> a process through which common goals can be identified, described, >> and put into action. I do hope, though, that through the course of >> the discussion of each individual proposal everyone involved will >> come to understand the idea and by the time a proposal becomes a >> "goal" to be implemented I "expect" everyone to, at the very least, >> understand why a goal is important to others, even if they do not >> agree with it. That understanding should then lead, on the basis >> of agreeing to be part of a collaborative community, to supporting >> the goal. >> >> I also expect us to discuss a lot of proposals that we do not agree >> on, and that either need more time to develop or that end up finding >> another path to resolution. No one seems all that concerned with >> the concept that they might propose a goal that everyone else doesn't >> agree with. :-) >> >> So, yes, by the time we pick a goal I expect teams to do the work, >> because at that point in the process they will see it as the >> reasonable course of action. There is still an "escape valve" in >> place for teams that, after all of the discussion and shaping of >> the goals is over, still take issue with a goal. By explaining their >> position in their response, we will have reference documentation >> to point to when the inevitable "why doesn't X do Y" questions >> arise. I will be interested to see how often we actually have to >> use that. > > +1 I agree, too. This is a great process that covers nearly everything. The reason the prioritization language is so important isn't so that project teams can "get around" the TC or intentionally be different or otherwise not be good community participants. I want to make sure we are not setting up a process that tells projects to "toe the line" or get out. In a community as large and diverse in scope as OpenStack, it's impossible for one person or one small group to be familiar enough with all of the OpenStack projects to understand the design decisions, trade-offs, and priorities for each one. The TC certainly doesn't want to micromanage every project. Supporting a common goal and making progress on it is much different than "prioritize these goals above all other work". Like you, I expect that all projects in OpenStack will work together for the common good. I don't think any open source project can mandate prioritization on its contributors and expect to maintain long-term growth. > >> Excerpts from John Dickinson's message of 2016-08-12 16:04:42 -0700: >>> [...] >>> The proposed plan has a lot of good in it, and I'm really happy to see the >>> TC >>> working to bring common goals and vision to the entirety of the OpenStack >>> community. Drop the "project teams are expected to prioritize these goals >>> above >>> all other work", and my concerns evaporate. I'd be happy to agree to that >>> proposal. >> >> Saying that the community has goals but that no one is expected to >> act to bring them about would be a meaningless waste of time and >> energy. > > I think we can find wording that doesn't use the word "priority" (which > is, I think, what John objects to the most) while still conveying that > project teams are expected to act to bring them about (once they said > they agreed with the goal). > > How about "project teams are expected to do everything they can to > complete those goals within the boundaries of the target development > cycle" ? Would that sound better ? Any chance you'd go for something like "project teams are expected to make progress on these goals and report that progress to the TC every cycle"? Yes, I like Thierry's proposed wording better than the originally- proposed language. --John signature.asc Description: OpenPGP digital 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][ptl] establishing project-wide goals
Doug Hellmann wrote: > [...] > Choosing to be a part of a community comes with obligations as well > as benefits. If, after a lengthy discussion of a community-wide > goal, involving everyone in the community, a project team is > resolutely opposed to the goal, does that not indicate that the > needs of the project team and the needs of the broader community > are at odds in some way? And if the project team's needs and the > community needs are consistently at odds, over the course of a > series of such goals, why would the project team want to constrain > itself to stay in the community? Aren't they clearly going in > different directions? > > Understand, it is not my desire to emphasize any differences of > this nature. Rather, I want to reduce them. To do that, I am proposing > a process through which common goals can be identified, described, > and put into action. I do hope, though, that through the course of > the discussion of each individual proposal everyone involved will > come to understand the idea and by the time a proposal becomes a > "goal" to be implemented I "expect" everyone to, at the very least, > understand why a goal is important to others, even if they do not > agree with it. That understanding should then lead, on the basis > of agreeing to be part of a collaborative community, to supporting > the goal. > > I also expect us to discuss a lot of proposals that we do not agree > on, and that either need more time to develop or that end up finding > another path to resolution. No one seems all that concerned with > the concept that they might propose a goal that everyone else doesn't > agree with. :-) > > So, yes, by the time we pick a goal I expect teams to do the work, > because at that point in the process they will see it as the > reasonable course of action. There is still an "escape valve" in > place for teams that, after all of the discussion and shaping of > the goals is over, still take issue with a goal. By explaining their > position in their response, we will have reference documentation > to point to when the inevitable "why doesn't X do Y" questions > arise. I will be interested to see how often we actually have to > use that. +1 > Excerpts from John Dickinson's message of 2016-08-12 16:04:42 -0700: >> [...] >> The proposed plan has a lot of good in it, and I'm really happy to see the TC >> working to bring common goals and vision to the entirety of the OpenStack >> community. Drop the "project teams are expected to prioritize these goals >> above >> all other work", and my concerns evaporate. I'd be happy to agree to that >> proposal. > > Saying that the community has goals but that no one is expected to > act to bring them about would be a meaningless waste of time and > energy. I think we can find wording that doesn't use the word "priority" (which is, I think, what John objects to the most) while still conveying that project teams are expected to act to bring them about (once they said they agreed with the goal). How about "project teams are expected to do everything they can to complete those goals within the boundaries of the target development cycle" ? Would that sound better ? -- 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][ptl] establishing project-wide goals
Excerpts from John Dickinson's message of 2016-08-12 16:04:42 -0700: > > On 12 Aug 2016, at 13:31, Doug Hellmann wrote: > > > Excerpts from John Dickinson's message of 2016-08-12 13:02:59 -0700: > >> > >> On 12 Aug 2016, at 7:28, Doug Hellmann wrote: > >> > >>> Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: > > On 10 Aug 2016, at 8:29, Doug Hellmann wrote: > > > Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400: > >> 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" > >> > > > > The proposal was discussed at the TC meeting yesterday [4], and > > left open to give more time to comment. I've added all of the PTLs > > for big tent projects as reviewers on the process patch [1] to > > encourage comments from them. > > > > Please also look at the associated patches with the specific goals > > for this cycle (python 3.5 support and cleaning up Oslo incubated > > code). So far most of the discussion has focused on the process, > > but we need folks to think about the specific things they're going > > to be asked to do during Ocata as well. > > > > Doug > > > > [4] > > http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.html > > > > __ > > 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 > > > Commonality in goals and vision is what unites any community. I > definitely support the TC's effort to define these goals for OpenStack > and to champion them. However, I have a few concerns about the process > that has been proposed. > > I'm concerned with the mandate that all projects must prioritize these > goals above all other work. Thinking about this from the perspective of > the employers of OpenStack contributors, and I'm finding it difficult > to imagine them (particularly smaller ones) getting behind this > prioritization mandate. For example, if I've got a user or deployer > issue that requires an upstream change, am I to prioritize Py35 > compatibility over "broken in production"? Am I now to schedule my own > work on known bugs or missing features only after these goals have > been met? Is that what I should ask other community members to do too? > >>> > >>> There is a difference between priority and urgency. Clearly "broken > >>> in production" is more urgent than other planned work. It's less > >>> clear that, over the span of an entire 6 month release cycle, one > >>> production outage is the most important thing the team would have > >>> worked on. > >>> > >>> The point of the current wording is to make it clear that because these > >>> are goals coming from the entire community, teams are expected to place > >>> a high priority on completing them. In some cases that may mean > >>> working on community goals instead of working on
Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals
Excerpts from John Dickinson's message of 2016-08-12 13:02:59 -0700: > > On 12 Aug 2016, at 7:28, Doug Hellmann wrote: > > > Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: > >> > > > >> I agree with Hongbin Lu's comments that the resulting goals might fit > >> into the interests of the majority but fundamentally violate the > >> interests of a minority of project teams. As an example, should the TC > >> decide that a future goal is for projects to implement a particular > >> API-WG document, that may be good for several projects, but it might > >> not be possible or advisable for others. > > > > Again, the goals are not coming from the TC, they are coming from the > > entire community. There will be discussion sessions, mailing list > > threads, experimentation, etc. before any goal is settled on. By the > > time the goals for a given cycle are picked, everyone will have had a > > chance to give input. That's why I'm starting this conversation now, so > > far in advance of the summit. > > This is good, and the importance and difficulty of this is not lost on > me. I'm very glad you've included community feedback as part of the > process. > > But if a project is on the minority side of the resulting concensus, > how do we protect that project from being negatively affected? Even if > there are good reasons at the time for a project to not support a > goal, that dissent can come back against the project negatively, even > years down the road after those who dissented have left. I know this > from experience. > There is no minority side of a consensus. If you can't support that goal, it's not a community goal. I know it's mind blowing, but the idea is that we actually all agree that we all should exist, and have an important shared responsibility to one another under the OpenStack banner. Rather than a divisive voting system where we can chuck our desires at the wall, and point fingers when more people have different desires, the TC has a radical idea. They'd like to actually try and have OpenStack build OpenStack _together_. There's still a position that gives more than others. This is not an equilibrium. Some projects will have more time than others to complete these goals. But the point of a consensus is that we can actually find things that we can all commit to doing. And if we can't find those things, we should spend more time figuring out why. This isn't fairy tales and rainbows. It's human communication. We actually need to spend time listening to one another here. If a project team is feeling the pressure to gain more adoption so greatly that they simply cannot commit to a goal, then the community should hear that, and respect it. Don't make that a community goal, even if the teams that want it go ahead with activities, they can do so with the knowledge that it is their own, and they cannot expect community-wide support yet. At the same time, that very busy project team, whomever they may be, needs to consider the effect their activities have on the greater effort. The discussion needs to continue, and as unsatisfying as it may feel to have an open discussion instead of a closed discussion in which there were winners and losers, it's the burden we're going to bear to be able to achieve something larger than what a single team can achieve. I for one believe in this model. I think it will require leaders to step up and help build consensus. But I think we all know that as loosely coupled as OpenStack is, there are plenty of ties that bind us together. We all wear the same t-shirts, and we should act like we want to keep doing that. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals
On 12 Aug 2016, at 13:31, Doug Hellmann wrote: > Excerpts from John Dickinson's message of 2016-08-12 13:02:59 -0700: >> >> On 12 Aug 2016, at 7:28, Doug Hellmann wrote: >> >>> Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: On 10 Aug 2016, at 8:29, Doug Hellmann wrote: > Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400: >> 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" >> > > The proposal was discussed at the TC meeting yesterday [4], and > left open to give more time to comment. I've added all of the PTLs > for big tent projects as reviewers on the process patch [1] to > encourage comments from them. > > Please also look at the associated patches with the specific goals > for this cycle (python 3.5 support and cleaning up Oslo incubated > code). So far most of the discussion has focused on the process, > but we need folks to think about the specific things they're going > to be asked to do during Ocata as well. > > Doug > > [4] > http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.html > > __ > 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 Commonality in goals and vision is what unites any community. I definitely support the TC's effort to define these goals for OpenStack and to champion them. However, I have a few concerns about the process that has been proposed. I'm concerned with the mandate that all projects must prioritize these goals above all other work. Thinking about this from the perspective of the employers of OpenStack contributors, and I'm finding it difficult to imagine them (particularly smaller ones) getting behind this prioritization mandate. For example, if I've got a user or deployer issue that requires an upstream change, am I to prioritize Py35 compatibility over "broken in production"? Am I now to schedule my own work on known bugs or missing features only after these goals have been met? Is that what I should ask other community members to do too? >>> >>> There is a difference between priority and urgency. Clearly "broken >>> in production" is more urgent than other planned work. It's less >>> clear that, over the span of an entire 6 month release cycle, one >>> production outage is the most important thing the team would have >>> worked on. >>> >>> The point of the current wording is to make it clear that because these >>> are goals coming from the entire community, teams are expected to place >>> a high priority on completing them. In some cases that may mean >>> working on community goals instead of working on internal team goals. We >>> all face this tension all the time, so that's nothing new. >> >> It's not an issue of choosing to work on community goals. It's an >> issue of prioritizing these over things that affect current production >> deployments and things that are
Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals
Excerpts from John Dickinson's message of 2016-08-12 13:02:59 -0700: > > On 12 Aug 2016, at 7:28, Doug Hellmann wrote: > > > Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: > >> > >> On 10 Aug 2016, at 8:29, Doug Hellmann wrote: > >> > >>> Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400: > 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" > > >>> > >>> The proposal was discussed at the TC meeting yesterday [4], and > >>> left open to give more time to comment. I've added all of the PTLs > >>> for big tent projects as reviewers on the process patch [1] to > >>> encourage comments from them. > >>> > >>> Please also look at the associated patches with the specific goals > >>> for this cycle (python 3.5 support and cleaning up Oslo incubated > >>> code). So far most of the discussion has focused on the process, > >>> but we need folks to think about the specific things they're going > >>> to be asked to do during Ocata as well. > >>> > >>> Doug > >>> > >>> [4] > >>> http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.html > >>> > >>> __ > >>> 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 > >> > >> > >> Commonality in goals and vision is what unites any community. I > >> definitely support the TC's effort to define these goals for OpenStack > >> and to champion them. However, I have a few concerns about the process > >> that has been proposed. > >> > >> I'm concerned with the mandate that all projects must prioritize these > >> goals above all other work. Thinking about this from the perspective of > >> the employers of OpenStack contributors, and I'm finding it difficult > >> to imagine them (particularly smaller ones) getting behind this > >> prioritization mandate. For example, if I've got a user or deployer > >> issue that requires an upstream change, am I to prioritize Py35 > >> compatibility over "broken in production"? Am I now to schedule my own > >> work on known bugs or missing features only after these goals have > >> been met? Is that what I should ask other community members to do too? > > > > There is a difference between priority and urgency. Clearly "broken > > in production" is more urgent than other planned work. It's less > > clear that, over the span of an entire 6 month release cycle, one > > production outage is the most important thing the team would have > > worked on. > > > > The point of the current wording is to make it clear that because these > > are goals coming from the entire community, teams are expected to place > > a high priority on completing them. In some cases that may mean > > working on community goals instead of working on internal team goals. We > > all face this tension all the time, so that's nothing new. > > It's not an issue of choosing to work on community goals. It's an > issue of prioritizing these over things that affect current production > deployments and things that are needed to increase adoption. > > > > >> I agree with
Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals
On 12 Aug 2016, at 7:28, Doug Hellmann wrote: > Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: >> >> On 10 Aug 2016, at 8:29, Doug Hellmann wrote: >> >>> Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400: 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" >>> >>> The proposal was discussed at the TC meeting yesterday [4], and >>> left open to give more time to comment. I've added all of the PTLs >>> for big tent projects as reviewers on the process patch [1] to >>> encourage comments from them. >>> >>> Please also look at the associated patches with the specific goals >>> for this cycle (python 3.5 support and cleaning up Oslo incubated >>> code). So far most of the discussion has focused on the process, >>> but we need folks to think about the specific things they're going >>> to be asked to do during Ocata as well. >>> >>> Doug >>> >>> [4] >>> http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.html >>> >>> __ >>> 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 >> >> >> Commonality in goals and vision is what unites any community. I >> definitely support the TC's effort to define these goals for OpenStack >> and to champion them. However, I have a few concerns about the process >> that has been proposed. >> >> I'm concerned with the mandate that all projects must prioritize these >> goals above all other work. Thinking about this from the perspective of >> the employers of OpenStack contributors, and I'm finding it difficult >> to imagine them (particularly smaller ones) getting behind this >> prioritization mandate. For example, if I've got a user or deployer >> issue that requires an upstream change, am I to prioritize Py35 >> compatibility over "broken in production"? Am I now to schedule my own >> work on known bugs or missing features only after these goals have >> been met? Is that what I should ask other community members to do too? > > There is a difference between priority and urgency. Clearly "broken > in production" is more urgent than other planned work. It's less > clear that, over the span of an entire 6 month release cycle, one > production outage is the most important thing the team would have > worked on. > > The point of the current wording is to make it clear that because these > are goals coming from the entire community, teams are expected to place > a high priority on completing them. In some cases that may mean > working on community goals instead of working on internal team goals. We > all face this tension all the time, so that's nothing new. It's not an issue of choosing to work on community goals. It's an issue of prioritizing these over things that affect current production deployments and things that are needed to increase adoption. > >> I agree with Hongbin Lu's comments that the resulting goals might fit >> into the interests of the majority but fundamentally violate the >> interests of a minority of project teams. As an example, should the TC >> decide that a future goal is for projects to implement a particular >>
Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals
Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: > > On 10 Aug 2016, at 8:29, Doug Hellmann wrote: > > > Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400: > >> 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" > >> > > > > The proposal was discussed at the TC meeting yesterday [4], and > > left open to give more time to comment. I've added all of the PTLs > > for big tent projects as reviewers on the process patch [1] to > > encourage comments from them. > > > > Please also look at the associated patches with the specific goals > > for this cycle (python 3.5 support and cleaning up Oslo incubated > > code). So far most of the discussion has focused on the process, > > but we need folks to think about the specific things they're going > > to be asked to do during Ocata as well. > > > > Doug > > > > [4] > > http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.html > > > > __ > > 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 > > > Commonality in goals and vision is what unites any community. I > definitely support the TC's effort to define these goals for OpenStack > and to champion them. However, I have a few concerns about the process > that has been proposed. > > I'm concerned with the mandate that all projects must prioritize these > goals above all other work. Thinking about this from the perspective of > the employers of OpenStack contributors, and I'm finding it difficult > to imagine them (particularly smaller ones) getting behind this > prioritization mandate. For example, if I've got a user or deployer > issue that requires an upstream change, am I to prioritize Py35 > compatibility over "broken in production"? Am I now to schedule my own > work on known bugs or missing features only after these goals have > been met? Is that what I should ask other community members to do too? There is a difference between priority and urgency. Clearly "broken in production" is more urgent than other planned work. It's less clear that, over the span of an entire 6 month release cycle, one production outage is the most important thing the team would have worked on. The point of the current wording is to make it clear that because these are goals coming from the entire community, teams are expected to place a high priority on completing them. In some cases that may mean working on community goals instead of working on internal team goals. We all face this tension all the time, so that's nothing new. > I agree with Hongbin Lu's comments that the resulting goals might fit > into the interests of the majority but fundamentally violate the > interests of a minority of project teams. As an example, should the TC > decide that a future goal is for projects to implement a particular > API-WG document, that may be good for several projects, but it might > not be possible or advisable for others. Again, the goals are not coming from the TC, they are coming from the entire community. There will be discussion sessions, mailing list threads, experimentation, etc. before any
Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals
John Dickinson wrote: > [...] > I know the TC has no malicious intent here, and I do support the idea > of having cross-project goals. The first goals proposed seem like > great goals. And I understand the significant challenges of > coordinating goals between a multitude of different projects. However, > I haven't yet added my own +1 to the proposed goals because the > current process means that I am committing that every Swift project > team contributor is now to prioritize that work above all else, no > matter what is happening to their customers, their products, or their > communities. > [...] I agree that the wording around "prioritization" is slightly suboptimal. I think the intent here is that each project team commits to getting that work done during the development cycle, barring exceptional circumstances. The way I see it, that doesn't mean you would prioritize that (as in "do it first") over urgent things like fixing a bug that results in data corruption or a significant vulnerability. It means it should be a priority to get that done over the cycle. It should be seen as a "must have" rather than a "nice to have" when you discuss cycle priorities. -- 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][ptl] establishing project-wide goals
On 10 Aug 2016, at 8:29, Doug Hellmann wrote: > Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400: >> 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" >> > > The proposal was discussed at the TC meeting yesterday [4], and > left open to give more time to comment. I've added all of the PTLs > for big tent projects as reviewers on the process patch [1] to > encourage comments from them. > > Please also look at the associated patches with the specific goals > for this cycle (python 3.5 support and cleaning up Oslo incubated > code). So far most of the discussion has focused on the process, > but we need folks to think about the specific things they're going > to be asked to do during Ocata as well. > > Doug > > [4] > http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.html > > __ > 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 Commonality in goals and vision is what unites any community. I definitely support the TC's effort to define these goals for OpenStack and to champion them. However, I have a few concerns about the process that has been proposed. I'm concerned with the mandate that all projects must prioritize these goals above all other work. Thinking about this from the perspective of the employers of OpenStack contributors, and I'm finding it difficult to imagine them (particularly smaller ones) getting behind this prioritization mandate. For example, if I've got a user or deployer issue that requires an upstream change, am I to prioritize Py35 compatibility over "broken in production"? Am I now to schedule my own work on known bugs or missing features only after these goals have been met? Is that what I should ask other community members to do too? I agree with Hongbin Lu's comments that the resulting goals might fit into the interests of the majority but fundamentally violate the interests of a minority of project teams. As an example, should the TC decide that a future goal is for projects to implement a particular API-WG document, that may be good for several projects, but it might not be possible or advisable for others. I know the TC has no malicious intent here, and I do support the idea of having cross-project goals. The first goals proposed seem like great goals. And I understand the significant challenges of coordinating goals between a multitude of different projects. However, I haven't yet added my own +1 to the proposed goals because the current process means that I am committing that every Swift project team contributor is now to prioritize that work above all else, no matter what is happening to their customers, their products, or their communities. --John signature.asc Description: OpenPGP digital 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][ptl] establishing project-wide goals
Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400: > 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" > The proposal was discussed at the TC meeting yesterday [4], and left open to give more time to comment. I've added all of the PTLs for big tent projects as reviewers on the process patch [1] to encourage comments from them. Please also look at the associated patches with the specific goals for this cycle (python 3.5 support and cleaning up Oslo incubated code). So far most of the discussion has focused on the process, but we need folks to think about the specific things they're going to be asked to do during Ocata as well. Doug [4] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.html __ 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
