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
[openstack-dev] [tc] notes from stein ptg meetings of the technical committee
The TC held meetings on 2 days at the Stein PTG in Denver. On Sunday 9 September, we met for a few hours in the afternoon to discuss introspective topics. On Friday 14 September, we met for a full day to discuss community topics. Below is a summary of my notes. Please let me know if I omitted or misremembered anything. Agenda and notes: https://etherpad.openstack.org/p/tc-stein-ptg Backlog Review == We started the Sunday meeting with a review of all of the work that TC members are doing outside of the TC. This gave us a clearer view of what we could expect to be able to do as a group, given time constraints. With that grounding, we reviewed our backlog (https://wiki.openstack.org/wiki/Technical_Committee_Tracker) and removed many items that we either felt were completed, would not be completed, or were ongoing monitoring and did not need to be tracked as specific tasks. We also agreed to try to work together as a group on a smaller number of initiatives, rather than maintaining a long list of open items in the tracker. The python 2.7 deprecation timeline has been documented (https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html) and we saw no need to be more formal about documenting expectations for new projects joining the community, so we removed that item from the tracker. We have discussed building a set of documentation around project constellations, but decided the information we hoped to convey in constellations would better be conveyed through the software section of the foundation web site. Now that the data for that section is being moved to a repository that anyone in the community can update, we no longer felt it was necessary for the TC to commit to writing constellation documentation (although we would support someone else picking up that work). We dropped this item from the tracker. We had completed the item to add a key manager to the base services list when we added "a castellan-compatible" service, but not removed it from the backlog because there was also some discussion about adding Barbican specifically. Work on that is on hold, so we removed the item from the tracker for now and will add it back in the future if we decide to move ahead with adding Barbican. We removed the item for improving the visibility of status updates because we considered it an ongoing task. We will still be working on the problem, but since it may never be done we didn't feel like tracking it as a "task" made sense. Doug, Thierry, and Jeremy talked with the Infra team about upgrading and adding tools later in the week. We removed StarlingX from the tracker because the work on that project are happening out in the open more so we felt the initial status check was sufficiently completed. We removed the item for clarifying the terms of service for hosted projects on openstack.org infrastructure because that work is now being done by the team soon-to-be-called OpenDev. We removed the item that called for a review of the status of the electorate. The election officials produce some statistics after each election and they offered to add any details we thought were useful. Since this is a recurring item managed by the election team, we do not need to track it ourselves. We removed the item for improving the help-wanted list because it wasn't clear that the TC was the best group to manage a list of "roles" or other more detailed information. We discussed placing that information into team documentation or hosting it somewhere outside of the governance repository where more people could contribute. The kubernetes community has set up a forum, for example. We removed the task of updating the PTI for translation and PDF support in documentation builds because we worked out a way to do that without a governance change. http://lists.openstack.org/pipermail/openstack-dev/2018-September/134609.html Joint Leadership Meeting in Berlin == Alan Clark, chair of the Foundation board of directors, was present for the meeting, and asked that we include an agenda item to start planning for the joint leadership meeting with the board, UC, Foundation staff, and representatives from other projects being piloted by the Foundation. We spent a little bit of time discussing the previous meeting, including some feedback from TC members that the project announcements made that morning caused some distraction during the day. Jonathan Bryce indicated that they will time those announcements better to avoid that problem, and that with the new process being developed there should be fewer surprises in the future. Alan also gave us the feedback that with the ongoing evolution of the OpenStack project, the board is going to expect the TC to start providing more strategic planning information. He recommended that we be ready to discuss major themes of ongoing work and give the board members the information they need to project a positive image to the