Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180913/a09c1290/attachment.sig>