Mailing List Archive

Well Public Cloud WG has prepared the ammo as you know and to discuss with
TC on Friday :)

A hundred percent with you on this matter.

On Wed, Sep 12, 2018 at 9:47 AM Matt Riedemann <mriedemos@gmail.com> 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 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-sigs mailing list
> openstack-sigs@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>


--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhipeng@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

On Wed, Sep 12, 2018 at 3:30 PM Dan Smith <dms@danplanet.com> 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-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


--
Davanum Srinivas :: https://twitter.com/dims

On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
[...]
> 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 almost agree with you. I think the OpenStack TC members should be
actively engaged in recruiting and enabling interested people in the
community to do those things, but I don't think such work should be
solely the domain of the TC and would hate to give the impression
that you must be on the TC to have such an impact.
--
Jeremy Stanley

On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley <fungi@yuggoth.org> wrote:

> On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
> [...]
> > 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 almost agree with you. I think the OpenStack TC members should be
> actively engaged in recruiting and enabling interested people in the
> community to do those things, but I don't think such work should be
> solely the domain of the TC and would hate to give the impression
> that you must be on the TC to have such an impact.
> --
> Jeremy Stanley
>

Jeremy, this is not to say that one must be on the TC to have such an
impact, it is that TC has the duty more than anyone else to get this
specific cross-project goal done. I would even argue it is not the job
description of TC to enable/recruit, but to just do it.

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhipeng@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

On 9/12/2018 3:55 PM, Jeremy Stanley wrote:
> I almost agree with you. I think the OpenStack TC members should be
> actively engaged in recruiting and enabling interested people in the
> community to do those things, but I don't think such work should be
> solely the domain of the TC and would hate to give the impression
> that you must be on the TC to have such an impact.

See my reply to Thierry. This isn't what I'm saying. But I expect the
elected TC members to be *much* more *directly* involved in managing and
driving hard cross-project technical deliverables.

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

On 9/12/2018 5:13 PM, Jeremy Stanley wrote:
> Sure, and I'm saying that instead I think the influence of TC
> members_can_ be more valuable in finding and helping additional
> people to do these things rather than doing it all themselves, and
> it's not just about the limited number of available hours in the day
> for one person versus many. The successes goal champions experience,
> the connections they make and the elevated reputation they gain
> throughout the community during the process of these efforts builds
> new leaders for us all.

Again, I'm not saying TC members should be doing all of the work
themselves. That's not realistic, especially when critical parts of any
major effort are going to involve developers from projects on which none
of the TC members are active contributors (e.g. nova). I want to see TC
members herd cats, for lack of a better analogy, and help out
technically (with code) where possible.

Given the repeated mention of how the "help wanted" list continues to
not draw in contributors, I think the recruiting role of the TC should
take a back seat to actually stepping in and helping work on those items
directly. For example, Sean McGinnis is taking an active role in the
operators guide and other related docs that continue to be discussed at
every face to face event since those docs were dropped from
openstack-manuals (in Pike).

I think it's fair to say that the people generally elected to the TC are
those most visible in the community (it's a popularity contest) and
those people are generally the most visible because they have the luxury
of working upstream the majority of their time. As such, it's their duty
to oversee and spend time working on the hard cross-project technical
deliverables that operators and users are asking for, rather than think
of an infinite number of ways to try and draw *others* to help work on
those gaps. As I think it's the role of a PTL within a given project to
have a finger on the pulse of the technical priorities of that project
and manage the developers involved (of which the PTL certainly may be
one), it's the role of the TC to do the same across openstack as a
whole. If a PTL doesn't have the time or willingness to do that within
their project, they shouldn't be the PTL. The same goes for TC members IMO.

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

On 9/12/2018 5:32 PM, Melvin Hillsman wrote:
> We basically spent the day focusing on two things specific to what you
> bring up and are in agreement with you regarding action not just talk
> around feedback and outreach. [1]
> We wiped the agenda clean, discussed our availability (set reasonable
> expectations), and revisited how we can be more diligent and successful
> around these two principles which target your first comment, "...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 will not get into much detail because again this response is specific
> to a portion of your email so in keeping with feedback and outreach the
> UC is making it a point to be intentional. We have already got action
> items [2] which target the concern you raise. We have agreed to hold
> each other accountable and adjusted our meeting structure to facilitate
> being successful.
>
> Not that the UC (elected members) are the only ones who can do this but
> we believe it is our responsibility to; regardless of what anyone else
> does. The UC is also expected to enlist others and hopefully through our
> efforts others are encouraged participate and enlist others.
>
> [1] https://etherpad.openstack.org/p/uc-stein-ptg
> [2] https://etherpad.openstack.org/p/UC-Election-Qualifications

Awesome, thank you Melvin and others on the UC.

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

You're welcome!

--

Kind regards,

Melvin Hillsman

mrhillsman@gmail.com
mobile: (832) 264-2646

On Wed, Sep 12, 2018, 5:52 PM Matt Riedemann <mriedemos@gmail.com> wrote:

> On 9/12/2018 5:32 PM, Melvin Hillsman wrote:
> > We basically spent the day focusing on two things specific to what you
> > bring up and are in agreement with you regarding action not just talk
> > around feedback and outreach. [1]
> > We wiped the agenda clean, discussed our availability (set reasonable
> > expectations), and revisited how we can be more diligent and successful
> > around these two principles which target your first comment, "...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 will not get into much detail because again this response is specific
> > to a portion of your email so in keeping with feedback and outreach the
> > UC is making it a point to be intentional. We have already got action
> > items [2] which target the concern you raise. We have agreed to hold
> > each other accountable and adjusted our meeting structure to facilitate
> > being successful.
> >
> > Not that the UC (elected members) are the only ones who can do this but
> > we believe it is our responsibility to; regardless of what anyone else
> > does. The UC is also expected to enlist others and hopefully through our
> > efforts others are encouraged participate and enlist others.
> >
> > [1] https://etherpad.openstack.org/p/uc-stein-ptg
> > [2] https://etherpad.openstack.org/p/UC-Election-Qualifications
>
> Awesome, thank you Melvin and others on the UC.
>
> --
>
> Thanks,
>
> Matt
>

---- On Thu, 13 Sep 2018 00:47:27 +0900 Matt Riedemann <mriedemos@gmail.com> 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-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

How about stated this way,
Its the tc's responsibility to get it done. Either by delegating the activity, or by doing it themselves. But either way, it needs to get done. Its a ball that has been dropped too much in OpenStacks history. If no one is ultimately responsible, balls will keep getting dropped.

Thanks,
Kevin
________________________________________
From: Matt Riedemann [mriedemos@gmail.com]
Sent: Wednesday, September 12, 2018 4:00 PM
To: Dan Smith; Thierry Carrez
Cc: OpenStack Development Mailing List (not for usage questions); openstack-sigs@lists.openstack.org; openstack-operators@lists.openstack.org
Subject: Re: [Openstack-sigs] [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-sigs mailing list
openstack-sigs@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

On 2018-09-12 17:50:30 -0600 (-0600), Matt Riedemann wrote:
[...]
> Again, I'm not saying TC members should be doing all of the work
> themselves. That's not realistic, especially when critical parts
> of any major effort are going to involve developers from projects
> on which none of the TC members are active contributors (e.g.
> nova). I want to see TC members herd cats, for lack of a better
> analogy, and help out technically (with code) where possible.

I can respect that. I think that OpenStack made a mistake in naming
its community management governance body the "technical" committee.
I do agree that having TC members engage in activities with tangible
outcomes is preferable, and that the needs of the users of its
software should weigh heavily in prioritization decisions, but those
are not the only problems our community faces nor is it as if there
are no other responsibilities associated with being a TC member.

> Given the repeated mention of how the "help wanted" list continues
> to not draw in contributors, I think the recruiting role of the TC
> should take a back seat to actually stepping in and helping work
> on those items directly. For example, Sean McGinnis is taking an
> active role in the operators guide and other related docs that
> continue to be discussed at every face to face event since those
> docs were dropped from openstack-manuals (in Pike).

I completely agree that the help wanted list hasn't worked out well
in practice. It was based on requests from the board of directors to
provide some means of communicating to their business-focused
constituency where resources would be most useful to the project.
We've had a subsequent request to reorient it to be more like a set
of job descriptions along with clearer business use cases explaining
the benefit to them of contributing to these efforts. In my opinion
it's very much the responsibility of the TC to find ways to
accomplish these sorts of things as well.

> I think it's fair to say that the people generally elected to the
> TC are those most visible in the community (it's a popularity
> contest) and those people are generally the most visible because
> they have the luxury of working upstream the majority of their
> time. As such, it's their duty to oversee and spend time working
> on the hard cross-project technical deliverables that operators
> and users are asking for, rather than think of an infinite number
> of ways to try and draw *others* to help work on those gaps.

But not everyone who is funded for full-time involvement with the
community is necessarily "visible" in ways that make them electable.
Higher-profile involvement in such activities over time is what gets
them the visibility to be more easily elected to governance
positions via "popularity contest" mechanics.

> As I think it's the role of a PTL within a given project to have a
> finger on the pulse of the technical priorities of that project
> and manage the developers involved (of which the PTL certainly may
> be one), it's the role of the TC to do the same across openstack
> as a whole. If a PTL doesn't have the time or willingness to do
> that within their project, they shouldn't be the PTL. The same
> goes for TC members IMO.

Completely agree, I think we might just disagree on where to strike
the balance of purely technical priorities for the TC (as I
personally think the TC is somewhat incorrectly named).
--
Jeremy Stanley

Folks,

Sorry for the top post - Those of you that are still at PTG, please feel
free to drop in to the Clear Creek room today.

Thanks,
Dims

On Thu, Sep 13, 2018 at 2:44 PM Jeremy Stanley <fungi@yuggoth.org> wrote:

> On 2018-09-12 17:50:30 -0600 (-0600), Matt Riedemann wrote:
> [...]
> > Again, I'm not saying TC members should be doing all of the work
> > themselves. That's not realistic, especially when critical parts
> > of any major effort are going to involve developers from projects
> > on which none of the TC members are active contributors (e.g.
> > nova). I want to see TC members herd cats, for lack of a better
> > analogy, and help out technically (with code) where possible.
>
> I can respect that. I think that OpenStack made a mistake in naming
> its community management governance body the "technical" committee.
> I do agree that having TC members engage in activities with tangible
> outcomes is preferable, and that the needs of the users of its
> software should weigh heavily in prioritization decisions, but those
> are not the only problems our community faces nor is it as if there
> are no other responsibilities associated with being a TC member.
>
> > Given the repeated mention of how the "help wanted" list continues
> > to not draw in contributors, I think the recruiting role of the TC
> > should take a back seat to actually stepping in and helping work
> > on those items directly. For example, Sean McGinnis is taking an
> > active role in the operators guide and other related docs that
> > continue to be discussed at every face to face event since those
> > docs were dropped from openstack-manuals (in Pike).
>
> I completely agree that the help wanted list hasn't worked out well
> in practice. It was based on requests from the board of directors to
> provide some means of communicating to their business-focused
> constituency where resources would be most useful to the project.
> We've had a subsequent request to reorient it to be more like a set
> of job descriptions along with clearer business use cases explaining
> the benefit to them of contributing to these efforts. In my opinion
> it's very much the responsibility of the TC to find ways to
> accomplish these sorts of things as well.
>
> > I think it's fair to say that the people generally elected to the
> > TC are those most visible in the community (it's a popularity
> > contest) and those people are generally the most visible because
> > they have the luxury of working upstream the majority of their
> > time. As such, it's their duty to oversee and spend time working
> > on the hard cross-project technical deliverables that operators
> > and users are asking for, rather than think of an infinite number
> > of ways to try and draw *others* to help work on those gaps.
>
> But not everyone who is funded for full-time involvement with the
> community is necessarily "visible" in ways that make them electable.
> Higher-profile involvement in such activities over time is what gets
> them the visibility to be more easily elected to governance
> positions via "popularity contest" mechanics.
>
> > As I think it's the role of a PTL within a given project to have a
> > finger on the pulse of the technical priorities of that project
> > and manage the developers involved (of which the PTL certainly may
> > be one), it's the role of the TC to do the same across openstack
> > as a whole. If a PTL doesn't have the time or willingness to do
> > that within their project, they shouldn't be the PTL. The same
> > goes for TC members IMO.
>
> Completely agree, I think we might just disagree on where to strike
> the balance of purely technical priorities for the TC (as I
> personally think the TC is somewhat incorrectly named).
> --
> Jeremy Stanley
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


--
Davanum Srinivas :: https://twitter.com/dims

> 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].

As the TC is currently vouching for the goals of a cycle, I strongly
agree that there is need for the TC to be in-line with the what our
users are asking, and those converting business requirements to
technical decisions. I strongly agree the TC should be in contact with
the UC and SIGs, as both are representing user focuses (the former one
is more global, while the latter is more contextual).

> 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.

Multiple points in that.
1) I agree with the "I want my elected TC members to be pushing tangible
technical deliverables forward.".
2) I acknowledge the fact that not all the TC members are in a position
like Ildikos or Doug. I am glad I am in an employer that believe in
contributing upstream and lets me enough room to do so, being given a
good incentive to do so.
3) "Necessity" + "sufficiency" vs expectations. I'd like TC members to
give their times to push technical changes forward. But I would also
hope non TC members would doing so.
So, I am fine with Dan's opinion: _expected_ to work on improving
technically OpenStack, and therefore helping PTLs (and other people) to
focus on their work/"other side of the pond".
4) If you are to think TC as companies' project managers, I would think
this view is incomplete. At best it would be program managers and/or
product owners that can/should take a project manager role.

The problem with that notion is that project managers have 3 axis to
play with (time, scope, and cost), where TC members only have one with
community goals (scope, as time is constrained to a cycle, and cost is
unclear/outside PM hands). If you've been to that position for a long
time, you know this cannot be healthy and very demoralizing.

For me, there is a small link that can _wrongly_ be done: as the TC is
an official "organism" of OpenStack, it could as some point be expected
to deliver these projects intact in a timely fashion without having the
resources to do so.

So, for me, the best way to think the goals should be a 'best effort'
work, and everyone championing is expected to do their best. I think we
are good at that for now, and doesn't need change.

If you change the mindset into being expected to deliver (as this could
become a very strong force for openstack), I'd say there are two risks:
- More time involved in PM duties to gather resources upfront
- Less deliverables proposed, as some could be higher risk and therefore
not tried.
- Possible finger pointing to "this champion didn't manage to achieve
its goals" or diluted goals when no resource available.

I am therefore not sure we'll able to go to that mindset in the current
way OpenStack and companies are organized.

> I don't find any value in the TC debating ad nauseam about visions and
> constellations and "what is openstack?".

Agree. I have an opinion of what OpenStack is, but I don't believe
discussing it over the mailing list in this message would be helpful in
any way. We can have this chat over drinks to see if we are aligned, but
I am not sure it matters :p

> 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.
Agreed.
> 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.
Your question is unclear to me. If users want x, this is a good feedback
for TC, and therefore should be passed to projects. If x is 'how things
are done technically in a project', I do not believe TC have to deal
with that: maybe some tc members would deal with it, but not as tc
members, more said projects contributors. if x is a governance of
OpenStack topic, I would hope tc would get involved the earliest possible.
> 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.
That rises a point of having global design document and decisions, so
that we learn better. There is still a lot of tribal knowledge in
OpenStack, and we should remove that over time by setting up the right
processes. I'd be happy to discuss that with you to have a real/more
complete understanding of what you mean there.

Jean-Philippe Evrard (evrardjp)

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Hope you all safely travel back to home now.

Here is the summarize from some discussions (as much as I can trigger or
attend) in PTG for SIGs/WGs expose and some idea for action,
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134689.html

I also like the idea to at least expose the information of SIGs/WGs right
away. Feel free to give your feedback.

And not like the following message matters to anyone, but just in case. I
believe this is a goal for all group in the community so just don't let who
your duty, position, or full hand of good tasks to limit what you think
about the relative of this goal with you. Give your positive or negative
opinions to help us get a better shape.


On Wed, Sep 12, 2018 at 11:47 PM Matt Riedemann <mriedemos@gmail.com> 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 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-sigs mailing list
> openstack-sigs@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>


--
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin