Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee
On 17/09/18 5:07 PM, Jay Pipes wrote: Also, for the record, I actually wasn't referring to Adjutant specifically when I referred in my original post to "only tangentially related to cloud computing". I was referring to my recollection of fairly recent history. I remember the seemingly endless debates about whether some applicants "fit" the OpenStack ecosystem or whether the applicant was merely trying to jump on a hype bandwagon for marketing purposes. Again, I wasn't specifically referring to Adjutant here, so I apologize if my words came across that way. Thanks for the clarification. What you're referring to is also an acknowledged problem, which we discussed at the Forum and are attempting to address with the Technical Vision (which we need to find a better name for). We didn't really discuss that on the Sunday though, because it was a topic on the formal agenda for Friday. Sunday's discussion was purely a retrospective on the Adjutant application, so you should read Doug's summary in that context. cheers, Zane. __ 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] [tc] notes from stein ptg meetings of the technical committee
Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2018-09-17 17:07:43 -0400: On 09/17/2018 04:50 PM, Doug Hellmann wrote: [...] I don't remember the history quite the way Jay does, either. I remember us trying to base the decision more about what the team was doing than how the code looked or whether the implementation met anyone's idea of "good". That's why we retained the requirement that the project "aligns with the OpenStack Mission". Hmm. I very specifically remember the incubation and graduation review of Zaqar and the fact that over a couple cycles of TC elections, the "advice" given by the TC about specific technical implementation details changed, often arbitrarily, depending on who was on the TC and what day of the week it was. In fact, I pretty vividly remember this arbitrary nature of the architectural review being one of the primary reasons we switched to a purely objective set of criteria. I remember talking about objectivity, but I also remember that we stopped reviewing aspects of a project like it's architecture or implementation details to avoid having the case you describe recur. I remember that because I had a hard time coming around to that point of view, at first. You're correct, however, that the resolution we adopted as the first step toward the big tent change (https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html#recognize-all-our-community-is-a-part-of-openstack) does talk about making decisions based on team practices and projects fitting the mission as being objective requirements. And the patch that implemented the first part of the big tent change (https://review.openstack.org/#/c/145740/14) also talks about objectivity. It's interesting that we took different things away from the same discussion. :-) In any case, I think we've learned there is still quite a bit of subjectivity in the question about whether a project fits the mission. Right. Back then our goal was definitely to remove the most subjective requirements. We removed judgment on whether the project was a good idea, or whether the technical architecture was sound, or whether the project was "mature" enough. We only kept two criteria: alignment with the OpenStack culture, and alignment with the OpenStack mission. Those are not purely objective criteria though. We had cases where we had to do a leap of faith whether the project really aligns with the OpenStack culture. And we had projects that were in a grey area even with our very vague mission statement. The Adjutant discussion, in the end, was about whether it would significantly hurt interoperability, and therefore be detrimental to the OpenStack mission rather than helping it. -- 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] [tc] notes from stein ptg meetings of the technical committee
Excerpts from Jay Pipes's message of 2018-09-17 17:07:43 -0400: > On 09/17/2018 04:50 PM, Doug Hellmann wrote: > > Excerpts from Zane Bitter's message of 2018-09-17 16:12:30 -0400: > >> On 17/09/18 3:06 PM, Jay Pipes wrote: > >>> On 09/17/2018 01:31 PM, Doug Hellmann wrote: > New Project Application Process > === > > We wrapped up Sunday with a discussion of of our process for reviewing > new project applications. Zane and Chris in particular felt the > process for Adjutant was too painful for the project team because > there was no way to know how long discussions might go on and now > way for them to anticipate some of the issues they encountered. > > We talked about formalizing a "coach" position to have someone from > the TC (or broader community) work with the team to prepare their > application with sufficient detail, seek feedback before voting > starts, etc. > > We also talked about adding a time limit to the process, so that > teams at least have a rejection with feedback in a reasonable amount > of time. Some of the less contentious discussions have averaged > from 1-4 months with a few more contentious cases taking as long > as 10 months. We did not settle on a time frame during the meeting, > so I expect this to be a topic for us to work out during the next > term. > >>> > >>> So, to summarize... the TC is back to almost exactly the same point it > >>> was at right before the Project Structure Reform happened in 2014-2015 > >>> (that whole Big Tent thing). > >> > >> I wouldn't go that far. There are more easy decisions than there were > >> before the reform, but there still exist hard decisions. This is perhaps > >> inevitable. > >> > >>> The Project Structure Reform occurred because the TC could not make > >>> decisions on whether projects should join OpenStack using objective > >>> criteria, and due to this, new project applicants were forced to endure > >>> long waits and subjective "graduation" reviews that could change from > >>> one TC election cycle to the next. > >>> > >>> The solution to this was to make an objective set of application > >>> criteria and remove the TC from the "Supreme Court of OpenStack" role > >>> that new applicants needed to come before and submit to the court's > >>> judgment. > >>> > >>> Many people complained that the Project Structure Reform was the TC > >>> simply abrogating responsibility for being a judgmental body. > >>> > >>> It seems that although we've now gotten rid of those objective criteria > >>> for project inclusion and gone back to the TC being a subjective > >>> judgmental body, that the TC is still not actually willing to pass > >>> judgment one way or the other on new project applicants. > >> > >> No criteria have been gotten rid of, but even after the Project > >> Structure Reform there existed criteria that were subjective. Here is a > >> thread discussing them during the last TC election: > >> > >> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html > >> > >> (I actually think that the perception that the criteria should be > >> entirely objective might be a contributor to the problem: when faced > >> with a subjective decision and no documentation or precedent to guide > >> them, TC members can be reluctant to choose.) > > > > I think turning the decision about which projects fit the mission > > into an entirely mechanical one would be a mistake. I would prefer > > us to use, and trust, our judgement in cases where the answer needs > > some thought. > > > > I don't remember the history quite the way Jay does, either. I > > remember us trying to base the decision more about what the team > > was doing than how the code looked or whether the implementation > > met anyone's idea of "good". That's why we retained the requirement > > that the project "aligns with the OpenStack Mission". > > Hmm. I very specifically remember the incubation and graduation review > of Zaqar and the fact that over a couple cycles of TC elections, the > "advice" given by the TC about specific technical implementation details > changed, often arbitrarily, depending on who was on the TC and what day > of the week it was. In fact, I pretty vividly remember this arbitrary > nature of the architectural review being one of the primary reasons we > switched to a purely objective set of criteria. I remember talking about objectivity, but I also remember that we stopped reviewing aspects of a project like it's architecture or implementation details to avoid having the case you describe recur. I remember that because I had a hard time coming around to that point of view, at first. You're correct, however, that the resolution we adopted as the first step toward the big tent change
Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee
On 09/17/2018 04:50 PM, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-09-17 16:12:30 -0400: On 17/09/18 3:06 PM, Jay Pipes wrote: On 09/17/2018 01:31 PM, Doug Hellmann wrote: New Project Application Process === We wrapped up Sunday with a discussion of of our process for reviewing new project applications. Zane and Chris in particular felt the process for Adjutant was too painful for the project team because there was no way to know how long discussions might go on and now way for them to anticipate some of the issues they encountered. We talked about formalizing a "coach" position to have someone from the TC (or broader community) work with the team to prepare their application with sufficient detail, seek feedback before voting starts, etc. We also talked about adding a time limit to the process, so that teams at least have a rejection with feedback in a reasonable amount of time. Some of the less contentious discussions have averaged from 1-4 months with a few more contentious cases taking as long as 10 months. We did not settle on a time frame during the meeting, so I expect this to be a topic for us to work out during the next term. So, to summarize... the TC is back to almost exactly the same point it was at right before the Project Structure Reform happened in 2014-2015 (that whole Big Tent thing). I wouldn't go that far. There are more easy decisions than there were before the reform, but there still exist hard decisions. This is perhaps inevitable. The Project Structure Reform occurred because the TC could not make decisions on whether projects should join OpenStack using objective criteria, and due to this, new project applicants were forced to endure long waits and subjective "graduation" reviews that could change from one TC election cycle to the next. The solution to this was to make an objective set of application criteria and remove the TC from the "Supreme Court of OpenStack" role that new applicants needed to come before and submit to the court's judgment. Many people complained that the Project Structure Reform was the TC simply abrogating responsibility for being a judgmental body. It seems that although we've now gotten rid of those objective criteria for project inclusion and gone back to the TC being a subjective judgmental body, that the TC is still not actually willing to pass judgment one way or the other on new project applicants. No criteria have been gotten rid of, but even after the Project Structure Reform there existed criteria that were subjective. Here is a thread discussing them during the last TC election: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html (I actually think that the perception that the criteria should be entirely objective might be a contributor to the problem: when faced with a subjective decision and no documentation or precedent to guide them, TC members can be reluctant to choose.) I think turning the decision about which projects fit the mission into an entirely mechanical one would be a mistake. I would prefer us to use, and trust, our judgement in cases where the answer needs some thought. I don't remember the history quite the way Jay does, either. I remember us trying to base the decision more about what the team was doing than how the code looked or whether the implementation met anyone's idea of "good". That's why we retained the requirement that the project "aligns with the OpenStack Mission". Hmm. I very specifically remember the incubation and graduation review of Zaqar and the fact that over a couple cycles of TC elections, the "advice" given by the TC about specific technical implementation details changed, often arbitrarily, depending on who was on the TC and what day of the week it was. In fact, I pretty vividly remember this arbitrary nature of the architectural review being one of the primary reasons we switched to a purely objective set of criteria. Also, for the record, I actually wasn't referring to Adjutant specifically when I referred in my original post to "only tangentially related to cloud computing". I was referring to my recollection of fairly recent history. I remember the seemingly endless debates about whether some applicants "fit" the OpenStack ecosystem or whether the applicant was merely trying to jump on a hype bandwagon for marketing purposes. Again, I wasn't specifically referring to Adjutant here, so I apologize if my words came across that way. 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] [tc] notes from stein ptg meetings of the technical committee
Excerpts from Zane Bitter's message of 2018-09-17 16:12:30 -0400: > On 17/09/18 3:06 PM, Jay Pipes wrote: > > On 09/17/2018 01:31 PM, Doug Hellmann wrote: > >> New Project Application Process > >> === > >> > >> We wrapped up Sunday with a discussion of of our process for reviewing > >> new project applications. Zane and Chris in particular felt the > >> process for Adjutant was too painful for the project team because > >> there was no way to know how long discussions might go on and now > >> way for them to anticipate some of the issues they encountered. > >> > >> We talked about formalizing a "coach" position to have someone from > >> the TC (or broader community) work with the team to prepare their > >> application with sufficient detail, seek feedback before voting > >> starts, etc. > >> > >> We also talked about adding a time limit to the process, so that > >> teams at least have a rejection with feedback in a reasonable amount > >> of time. Some of the less contentious discussions have averaged > >> from 1-4 months with a few more contentious cases taking as long > >> as 10 months. We did not settle on a time frame during the meeting, > >> so I expect this to be a topic for us to work out during the next > >> term. > > > > So, to summarize... the TC is back to almost exactly the same point it > > was at right before the Project Structure Reform happened in 2014-2015 > > (that whole Big Tent thing). > > I wouldn't go that far. There are more easy decisions than there were > before the reform, but there still exist hard decisions. This is perhaps > inevitable. > > > The Project Structure Reform occurred because the TC could not make > > decisions on whether projects should join OpenStack using objective > > criteria, and due to this, new project applicants were forced to endure > > long waits and subjective "graduation" reviews that could change from > > one TC election cycle to the next. > > > > The solution to this was to make an objective set of application > > criteria and remove the TC from the "Supreme Court of OpenStack" role > > that new applicants needed to come before and submit to the court's > > judgment. > > > > Many people complained that the Project Structure Reform was the TC > > simply abrogating responsibility for being a judgmental body. > > > > It seems that although we've now gotten rid of those objective criteria > > for project inclusion and gone back to the TC being a subjective > > judgmental body, that the TC is still not actually willing to pass > > judgment one way or the other on new project applicants. > > No criteria have been gotten rid of, but even after the Project > Structure Reform there existed criteria that were subjective. Here is a > thread discussing them during the last TC election: > > http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html > > (I actually think that the perception that the criteria should be > entirely objective might be a contributor to the problem: when faced > with a subjective decision and no documentation or precedent to guide > them, TC members can be reluctant to choose.) I think turning the decision about which projects fit the mission into an entirely mechanical one would be a mistake. I would prefer us to use, and trust, our judgement in cases where the answer needs some thought. I don't remember the history quite the way Jay does, either. I remember us trying to base the decision more about what the team was doing than how the code looked or whether the implementation met anyone's idea of "good". That's why we retained the requirement that the project "aligns with the OpenStack Mission". > > > Is this because it is still remarkably unclear what OpenStack actually > > *is* (the whole mission/scope thing)? > > > > Or is this because TC members simply don't want to be the ones to say > > "No" to good-meaning people > > I suspect both of those reasons are probably in the mix, along with a > few others as well. There was a good deal of confusion early on about what "workflow" meant in the context of Adjutant and whether the use of workflows was overlapping unnecessarily with Mistral. After that was clarified we talked about the interoperability concerns with an API that may be different based on deployer choices. > > > that may have an idea that is only > > tangentially related to cloud computing? > > It should be noted that in this case Adjutant pretty clearly fills an > essential use case for public clouds. The debate was around whether > accepting it was likely to lead to the desired standardisation across > public OpenStack clouds or effectively act as an official endorsement > for API fragmentation. > > It's not clear that any change to the criteria could have made this > particular decision any easier. Only adding a specific rule about the API interoperability would have addressed my concern directly. I'm not sure applying such a rule
Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee
On 17/09/18 3:06 PM, Jay Pipes wrote: On 09/17/2018 01:31 PM, Doug Hellmann wrote: New Project Application Process === We wrapped up Sunday with a discussion of of our process for reviewing new project applications. Zane and Chris in particular felt the process for Adjutant was too painful for the project team because there was no way to know how long discussions might go on and now way for them to anticipate some of the issues they encountered. We talked about formalizing a "coach" position to have someone from the TC (or broader community) work with the team to prepare their application with sufficient detail, seek feedback before voting starts, etc. We also talked about adding a time limit to the process, so that teams at least have a rejection with feedback in a reasonable amount of time. Some of the less contentious discussions have averaged from 1-4 months with a few more contentious cases taking as long as 10 months. We did not settle on a time frame during the meeting, so I expect this to be a topic for us to work out during the next term. So, to summarize... the TC is back to almost exactly the same point it was at right before the Project Structure Reform happened in 2014-2015 (that whole Big Tent thing). I wouldn't go that far. There are more easy decisions than there were before the reform, but there still exist hard decisions. This is perhaps inevitable. The Project Structure Reform occurred because the TC could not make decisions on whether projects should join OpenStack using objective criteria, and due to this, new project applicants were forced to endure long waits and subjective "graduation" reviews that could change from one TC election cycle to the next. The solution to this was to make an objective set of application criteria and remove the TC from the "Supreme Court of OpenStack" role that new applicants needed to come before and submit to the court's judgment. Many people complained that the Project Structure Reform was the TC simply abrogating responsibility for being a judgmental body. It seems that although we've now gotten rid of those objective criteria for project inclusion and gone back to the TC being a subjective judgmental body, that the TC is still not actually willing to pass judgment one way or the other on new project applicants. No criteria have been gotten rid of, but even after the Project Structure Reform there existed criteria that were subjective. Here is a thread discussing them during the last TC election: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html (I actually think that the perception that the criteria should be entirely objective might be a contributor to the problem: when faced with a subjective decision and no documentation or precedent to guide them, TC members can be reluctant to choose.) Is this because it is still remarkably unclear what OpenStack actually *is* (the whole mission/scope thing)? Or is this because TC members simply don't want to be the ones to say "No" to good-meaning people I suspect both of those reasons are probably in the mix, along with a few others as well. that may have an idea that is only tangentially related to cloud computing? It should be noted that in this case Adjutant pretty clearly fills an essential use case for public clouds. The debate was around whether accepting it was likely to lead to the desired standardisation across public OpenStack clouds or effectively act as an official endorsement for API fragmentation. It's not clear that any change to the criteria could have made this particular decision any easier. Things did seem to go more smoothly after we nominated a couple of people to work directly with the project to polish their application, and in retrospect we probably should have treated it with more urgency rather than e.g. waiting for a face-to-face discussion at the Forum before attempting to make progress. Those are the lessons behind the process improvements that we discussed last week that Doug summarised above. cheers, Zane. __ 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] [tc] notes from stein ptg meetings of the technical committee
On 09/17/2018 01:31 PM, Doug Hellmann wrote: New Project Application Process === We wrapped up Sunday with a discussion of of our process for reviewing new project applications. Zane and Chris in particular felt the process for Adjutant was too painful for the project team because there was no way to know how long discussions might go on and now way for them to anticipate some of the issues they encountered. We talked about formalizing a "coach" position to have someone from the TC (or broader community) work with the team to prepare their application with sufficient detail, seek feedback before voting starts, etc. We also talked about adding a time limit to the process, so that teams at least have a rejection with feedback in a reasonable amount of time. Some of the less contentious discussions have averaged from 1-4 months with a few more contentious cases taking as long as 10 months. We did not settle on a time frame during the meeting, so I expect this to be a topic for us to work out during the next term. So, to summarize... the TC is back to almost exactly the same point it was at right before the Project Structure Reform happened in 2014-2015 (that whole Big Tent thing). The Project Structure Reform occurred because the TC could not make decisions on whether projects should join OpenStack using objective criteria, and due to this, new project applicants were forced to endure long waits and subjective "graduation" reviews that could change from one TC election cycle to the next. The solution to this was to make an objective set of application criteria and remove the TC from the "Supreme Court of OpenStack" role that new applicants needed to come before and submit to the court's judgment. Many people complained that the Project Structure Reform was the TC simply abrogating responsibility for being a judgmental body. It seems that although we've now gotten rid of those objective criteria for project inclusion and gone back to the TC being a subjective judgmental body, that the TC is still not actually willing to pass judgment one way or the other on new project applicants. Is this because it is still remarkably unclear what OpenStack actually *is* (the whole mission/scope thing)? Or is this because TC members simply don't want to be the ones to say "No" to good-meaning people that may have an idea that is only tangentially related to cloud computing? Everything old is new again. 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
