Re: [openstack-dev] Open letter/request to TC candidates (and existing elected officials)
On Thu, 13 Sep 2018 00:47:27 +0900 Matt Riedemann wrote > Rather than take a tangent on Kristi's candidacy thread [1], I'll bring > this up separately. > > Kristi said: > > "Ultimately, this list isn’t exclusive and I’d love to hear your and > other people's opinions about what you think the I should focus on." > > Well since you asked... > > Some feedback I gave to the public cloud work group yesterday was to get > their RFE/bug list ranked from the operator community (because some of > the requests are not exclusive to public cloud), and then put pressure > on the TC to help project manage the delivery of the top issue. I would > like all of the SIGs to do this. The upgrades SIG should rank and > socialize their #1 issue that needs attention from the developer > community - maybe that's better upgrade CI testing for deployment > projects, maybe it's getting the pre-upgrade checks goal done for Stein. > The UC should also be doing this; maybe that's the UC saying, "we need > help on closing feature gaps in openstack client and/or the SDK". I > don't want SIGs to bombard the developers with *all* of their > requirements, but I want to get past *talking* about the *same* issues > *every* time we get together. I want each group to say, "this is our top > issue and we want developers to focus on it." For example, the extended > maintenance resolution [2] was purely birthed from frustration about > talking about LTS and stable branch EOL every time we get together. It's > also the responsibility of the operator and user communities to weigh in > on proposed release goals, but the TC should be actively trying to get > feedback from those communities about proposed goals, because I bet > operators and users don't care about mox removal [3]. I agree on this and i feel this is real value we can add with current situation where contributors are less in almost all of the projects. When we set goal for any cycle, we should have user/operator/SIG weightage on priority in selection checklist and categorize the goal into respective category/tag something like "user-oriented" or "coding-oriented"(only developer/maintaining code benefits). And then we concentrate more on first category and leave second one more on project team. Project team further can plan the second catagory items as per their bandwidth and priority. I am not saying code/developer oriented goals should not be initiated by TC but those should be on low priority list kind of. -gmann > > I want to see the TC be more of a cross-project project management > group, like a group of Ildikos and what she did between nova and cinder > to get volume multi-attach done, which took persistent supervision to > herd the cats and get it delivered. Lance is already trying to do this > with unified limits. Doug is doing this with the python3 goal. I want my > elected TC members to be pushing tangible technical deliverables forward. > > I don't find any value in the TC debating ad nauseam about visions and > constellations and "what is openstack?". Scope will change over time > depending on who is contributing to openstack, we should just accept > this. And we need to realize that if we are failing to deliver value to > operators and users, they aren't going to use openstack and then "what > is openstack?" won't matter because no one will care. > > So I encourage all elected TC members to work directly with the various > SIGs to figure out their top issue and then work on managing those > deliverables across the community because the TC is particularly well > suited to do so given the elected position. I realize political and > bureaucratic "how should openstack deal with x?" things will come up, > but those should not be the priority of the TC. So instead of > philosophizing about things like, "should all compute agents be in a > single service with a REST API" for hours and hours, every few months - > immediately ask, "would doing that get us any closer to achieving top > technical priority x?" Because if not, or it's so fuzzy in scope that no > one sees the way forward, document a decision and then drop it. > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html > [2] > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html > [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html > > -- > > Thanks, > > Matt > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] Open letter/request to TC candidates (and existing elected officials)
On 9/12/2018 3:30 PM, Dan Smith wrote: I'm just a bit worried to limit that role to the elected TC members. If we say "it's the role of the TC to do cross-project PM in OpenStack" then we artificially limit the number of people who would sign up to do that kind of work. You mention Ildiko and Lance: they did that line of work without being elected. Why would saying that we_expect_ the TC members to do that work limit such activities only to those that are on the TC? I would expect the TC to take on the less-fun or often-neglected efforts that we all know are needed but don't have an obvious champion or sponsor. I think we expect some amount of widely-focused technical or project leadership from TC members, and certainly that expectation doesn't prevent others from leading efforts (even in the areas of proposing TC resolutions, etc) right? Absolutely. I'm not saying the cross-project project management should be restricted to or solely the responsibility of the TC. It's obvious there are people outside of the TC that have already been doing this - and no it's not always elected PTLs either. What I want is elected TC members to prioritize driving technical deliverables to completion based on ranked input from operators/users/SIGs over philosophical debates and politics/bureaucracy and help to complete the technical tasks if possible. -- Thanks, Matt __ 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] Open letter/request to TC candidates (and existing elected officials)
On Wed, Sep 12, 2018 at 3:30 PM Dan Smith wrote: > > I'm just a bit worried to limit that role to the elected TC members. If > > we say "it's the role of the TC to do cross-project PM in OpenStack" > > then we artificially limit the number of people who would sign up to do > > that kind of work. You mention Ildiko and Lance: they did that line of > > work without being elected. > > Why would saying that we _expect_ the TC members to do that work limit > such activities only to those that are on the TC? I would expect the TC > to take on the less-fun or often-neglected efforts that we all know are > needed but don't have an obvious champion or sponsor. > > I think we expect some amount of widely-focused technical or project > leadership from TC members, and certainly that expectation doesn't > prevent others from leading efforts (even in the areas of proposing TC > resolutions, etc) right? > +1 Dan! > --Dan > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] Open letter/request to TC candidates (and existing elected officials)
> I'm just a bit worried to limit that role to the elected TC members. If > we say "it's the role of the TC to do cross-project PM in OpenStack" > then we artificially limit the number of people who would sign up to do > that kind of work. You mention Ildiko and Lance: they did that line of > work without being elected. Why would saying that we _expect_ the TC members to do that work limit such activities only to those that are on the TC? I would expect the TC to take on the less-fun or often-neglected efforts that we all know are needed but don't have an obvious champion or sponsor. I think we expect some amount of widely-focused technical or project leadership from TC members, and certainly that expectation doesn't prevent others from leading efforts (even in the areas of proposing TC resolutions, etc) right? --Dan __ 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] Open letter/request to TC candidates (and existing elected officials)
Matt Riedemann wrote: > [...] > I want to see the TC be more of a cross-project project management > group, like a group of Ildikos and what she did between nova and cinder > to get volume multi-attach done, which took persistent supervision to > herd the cats and get it delivered. Lance is already trying to do this > with unified limits. Doug is doing this with the python3 goal. I want my > elected TC members to be pushing tangible technical deliverables forward. > > I don't find any value in the TC debating ad nauseam about visions and > constellations and "what is openstack?". Scope will change over time > depending on who is contributing to openstack, we should just accept > this. And we need to realize that if we are failing to deliver value to > operators and users, they aren't going to use openstack and then "what > is openstack?" won't matter because no one will care. > [...] I agree that we generally need more of those cross-project champions, and generally TC members are in a good position to do that kind of work. The TC itself is also in a good position to "bless" those initiatives and give them some amount of priority (with our limited influence). I'm just a bit worried to limit that role to the elected TC members. If we say "it's the role of the TC to do cross-project PM in OpenStack" then we artificially limit the number of people who would sign up to do that kind of work. You mention Ildiko and Lance: they did that line of work without being elected. So I would definitely support having champions to drive SIG cross-project priorities, and use the TC both to support them and as a natural pool of champion candidates -- I would just avoid tying the role to the elected group? -- 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
[openstack-dev] Open letter/request to TC candidates (and existing elected officials)
Rather than take a tangent on Kristi's candidacy thread [1], I'll bring this up separately. Kristi said: "Ultimately, this list isn’t exclusive and I’d love to hear your and other people's opinions about what you think the I should focus on." Well since you asked... Some feedback I gave to the public cloud work group yesterday was to get their RFE/bug list ranked from the operator community (because some of the requests are not exclusive to public cloud), and then put pressure on the TC to help project manage the delivery of the top issue. I would like all of the SIGs to do this. The upgrades SIG should rank and socialize their #1 issue that needs attention from the developer community - maybe that's better upgrade CI testing for deployment projects, maybe it's getting the pre-upgrade checks goal done for Stein. The UC should also be doing this; maybe that's the UC saying, "we need help on closing feature gaps in openstack client and/or the SDK". I don't want SIGs to bombard the developers with *all* of their requirements, but I want to get past *talking* about the *same* issues *every* time we get together. I want each group to say, "this is our top issue and we want developers to focus on it." For example, the extended maintenance resolution [2] was purely birthed from frustration about talking about LTS and stable branch EOL every time we get together. It's also the responsibility of the operator and user communities to weigh in on proposed release goals, but the TC should be actively trying to get feedback from those communities about proposed goals, because I bet operators and users don't care about mox removal [3]. I want to see the TC be more of a cross-project project management group, like a group of Ildikos and what she did between nova and cinder to get volume multi-attach done, which took persistent supervision to herd the cats and get it delivered. Lance is already trying to do this with unified limits. Doug is doing this with the python3 goal. I want my elected TC members to be pushing tangible technical deliverables forward. I don't find any value in the TC debating ad nauseam about visions and constellations and "what is openstack?". Scope will change over time depending on who is contributing to openstack, we should just accept this. And we need to realize that if we are failing to deliver value to operators and users, they aren't going to use openstack and then "what is openstack?" won't matter because no one will care. So I encourage all elected TC members to work directly with the various SIGs to figure out their top issue and then work on managing those deliverables across the community because the TC is particularly well suited to do so given the elected position. I realize political and bureaucratic "how should openstack deal with x?" things will come up, but those should not be the priority of the TC. So instead of philosophizing about things like, "should all compute agents be in a single service with a REST API" for hours and hours, every few months - immediately ask, "would doing that get us any closer to achieving top technical priority x?" Because if not, or it's so fuzzy in scope that no one sees the way forward, document a decision and then drop it. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html [2] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html -- Thanks, Matt __ 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
