Open Stack

Excerpts from John Dickinson's message of 2016-08-12 16:04:42 -0700:
> 
> On 12 Aug 2016, at 13:31, Doug Hellmann wrote:
> 
> > Excerpts from John Dickinson's message of 2016-08-12 13:02:59 -0700:
> >>
> >> On 12 Aug 2016, at 7:28, Doug Hellmann wrote:
> >>
> >>> Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700:
> >>>>
> >>>> On 10 Aug 2016, at 8:29, Doug Hellmann wrote:
> >>>>
> >>>>> Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400:
> >>>>>> One of the outcomes of the discussion at the leadership training
> >>>>>> session earlier this year was the idea that the TC should set some
> >>>>>> community-wide goals for accomplishing specific technical tasks to
> >>>>>> get the projects synced up and moving in the same direction.
> >>>>>>
> >>>>>> After several drafts via etherpad and input from other TC and SWG
> >>>>>> members, I've prepared the change for the governance repo [1] and
> >>>>>> am ready to open this discussion up to the broader community. Please
> >>>>>> read through the patch carefully, especially the "goals/index.rst"
> >>>>>> document which tries to lay out the expectations for what makes a
> >>>>>> good goal for this purpose and for how teams are meant to approach
> >>>>>> working on these goals.
> >>>>>>
> >>>>>> I've also prepared two patches proposing specific goals for Ocata
> >>>>>> [2][3].  I've tried to keep these suggested goals for the first
> >>>>>> iteration limited to "finish what we've started" type items, so
> >>>>>> they are small and straightforward enough to be able to be completed.
> >>>>>> That will let us experiment with the process of managing goals this
> >>>>>> time around, and set us up for discussions that may need to happen
> >>>>>> at the Ocata summit about implementation.
> >>>>>>
> >>>>>> For future cycles, we can iterate on making the goals "harder", and
> >>>>>> collecting suggestions for goals from the community during the forum
> >>>>>> discussions that will happen at summits starting in Boston.
> >>>>>>
> >>>>>> Doug
> >>>>>>
> >>>>>> [1] https://review.openstack.org/349068 describe a process for managing community-wide goals
> >>>>>> [2] https://review.openstack.org/349069 add ocata goal "support python 3.5"
> >>>>>> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo libraries"
> >>>>>>
> >>>>>
> >>>>> The proposal was discussed at the TC meeting yesterday [4], and
> >>>>> left open to give more time to comment. I've added all of the PTLs
> >>>>> for big tent projects as reviewers on the process patch [1] to
> >>>>> encourage comments from them.
> >>>>>
> >>>>> Please also look at the associated patches with the specific goals
> >>>>> for this cycle (python 3.5 support and cleaning up Oslo incubated
> >>>>> code).  So far most of the discussion has focused on the process,
> >>>>> but we need folks to think about the specific things they're going
> >>>>> to be asked to do during Ocata as well.
> >>>>>
> >>>>> Doug
> >>>>>
> >>>>> [4] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.html
> >>>>>
> >>>>> __________________________________________________________________________
> >>>>> OpenStack Development Mailing List (not for usage questions)
> >>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>>
> >>>> Commonality in goals and vision is what unites any community. I
> >>>> definitely support the TC's effort to define these goals for OpenStack
> >>>> and to champion them. However, I have a few concerns about the process
> >>>> that has been proposed.
> >>>>
> >>>> I'm concerned with the mandate that all projects must prioritize these
> >>>> goals above all other work. Thinking about this from the perspective of
> >>>> the employers of OpenStack contributors, and I'm finding it difficult
> >>>> to imagine them (particularly smaller ones) getting behind this
> >>>> prioritization mandate. For example, if I've got a user or deployer
> >>>> issue that requires an upstream change, am I to prioritize Py35
> >>>> compatibility over "broken in production"? Am I now to schedule my own
> >>>> work on known bugs or missing features only after these goals have
> >>>> been met? Is that what I should ask other community members to do too?
> >>>
> >>> There is a difference between priority and urgency. Clearly "broken
> >>> in production" is more urgent than other planned work. It's less
> >>> clear that, over the span of an entire 6 month release cycle, one
> >>> production outage is the most important thing the team would have
> >>> worked on.
> >>>
> >>> The point of the current wording is to make it clear that because these
> >>> are goals coming from the entire community, teams are expected to place
> >>> a high priority on completing them. In some cases that may mean
> >>> working on community goals instead of working on internal team goals. We
> >>> all face this tension all the time, so that's nothing new.
> >>
> >> It's not an issue of choosing to work on community goals. It's an
> >> issue of prioritizing these over things that affect current production
> >> deployments and things that are needed to increase adoption.
> >>
> >>>
> >>>> I agree with Hongbin Lu's comments that the resulting goals might fit
> >>>> into the interests of the majority but fundamentally violate the
> >>>> interests of a minority of project teams. As an example, should the TC
> >>>> decide that a future goal is for projects to implement a particular
> >>>> API-WG document, that may be good for several projects, but it might
> >>>> not be possible or advisable for others.
> >>>
> >>> Again, the goals are not coming from the TC, they are coming from the
> >>> entire community. There will be discussion sessions, mailing list
> >>> threads, experimentation, etc. before any goal is settled on. By the
> >>> time the goals for a given cycle are picked, everyone will have had a
> >>> chance to give input. That's why I'm starting this conversation now, so
> >>> far in advance of the summit.
> >>
> >> This is good, and the importance and difficulty of this is not lost on
> >> me. I'm very glad you've included community feedback as part of the
> >> process.
> >>
> >> But if a project is on the minority side of the resulting concensus,
> >> how do we protect that project from being negatively affected? Even if
> >> there are good reasons at the time for a project to not support a
> >> goal, that dissent can come back against the project negatively, even
> >> years down the road after those who dissented have left. I know this
> >> from experience.
> >>
> >>>
> >>> As far as not implementing a goal, if a team has a reason they feel a
> >>> goal does not fit with their project, then they should document that in
> >>> their response. That's part of the proposed process.
> >>>
> >>>> I know the TC has no malicious intent here, and I do support the idea
> >>>> of having cross-project goals. The first goals proposed seem like
> >>>> great goals.  And I understand the significant challenges of
> >>>> coordinating goals between a multitude of different projects. However,
> >>>> I haven't yet added my own +1 to the proposed goals because the
> >>>> current process means that I am committing that every Swift project
> >>>> team contributor is now to prioritize that work above all else, no
> >>>> matter what is happening to their customers, their products, or their
> >>>> communities.
> >>>
> >>> No, that's not what you're doing at all. You're saying that the
> >>> team, as a whole, will address the goal. That does not necessarily
> >>> mean every team member will be involved in it, any more than they
> >>> are all directly and intimately involved in every other task the
> >>> team takes on over the course of a cycle. But it does mean that
> >>> someone will sign up to do the work, and the team agrees to do
> >>> reviews or over whatever other help is needed to see it through.
> >>> And if a goal is completely outside the bounds of what the team can
> >>> agree to, then you are agreeing to document that in a sufficient
> >>> detail that the rest of the community, who asked for the goal, can
> >>> understand why, and then you move on.
> >>
> >> Let's take the example of py35 support. First, remember that I
> >> definitely support moving to py35.
> >>
> >> I've never once seen anyone stop using Swift or choose to not use Swift
> >> because Swift doesn't support py35. While getting py35 support is
> >> good, and it should be done, doing that does nothing to help increase
> >> user adoption. On the other hand, I know many people who have chosen
> >> not to use Swift (or not to use it yet) because of a missing feature
> >> or a because of a bug or a lack of some optimization. These are the
> >> things I have previously prioritized over py35 compatibility.
> >>
> >> In an open source project we can set priorities and hope, but we can
> >> never promise a deliverable at a certain time with a certain feature
> >> in it. Any person can say, "No. You don't pay me, and I don't have to
> >> do what you think is most important." Our response to this as
> >> community leaders must not be "there's the door" and chase people
> >> away. Instead our response must be to reassess our own priorities.
> >>
> >> Of course, you hope to never get to the point where community members
> >> are saying "no". That's why there's the feedback and sharing part
> >> before setting goals. However, the phrasing from the TC in response to
> >> concerns with this proposal seems to be "if you don't agree to and
> >> implement the goals, then you just might not belong in OpenStack."
> >> This troubles me.
> >
> > Please go re-read the history of this thread and the comments on
> > the patch. This isn't about showing anyone the door or kicking
> > projects out of the big tent. I'm not going to repeat all of the
> > previous assurances about that here, yet again.
> 
> This is what I saw in the review:
> 
> Hongbin Lu: the word "acknowledgement" seems to suggest that
>   individual project team are forced to accept everything, regardless of
>   the their willingness.
> 
> Doug: You have interpreted the wording exactly correctly.
> 
> Hongbin Lu: Again, I wish there are more democracy. In particular, the
>   process of defining and approving individual goal should reach
>   consensus of all the project teams, not just the TC. I demand that
>   because some goals might fit into the interests of majority but
>   fundamentally violate the interests of one or two project teams. It is
>   not fair to approve some goals that satisfies the majority by
>   sacrificing the minority.
> 
> Doug: Making it a directly-democratic decision in which everyone gets
>   an individual vote is impractical.

This was a discussion of the mechanics for making the final decision
about goals for a particular development cycle. The TC is going to
vote, based on all of the other input that is gathered in advance.
We've tried other mechanisms for establishing goals with other
people voting or writing specs or using other tools, and they haven't
been consistently successful. This is a new approach in which the
group elected by the community as leaders to consider the entire
project's needs, and not just an individual component team's needs,
will be taking a more active role.

> 
> Hongbin Lu: However, with respect, I fundamentally disagree with this
>   proposal, although I tried to suggest somethings to fix it. I think
>   the main problem of this proposal is that individual team doesn't have
>   a way to defend their interests when an adverse goal is imposed from
>   external parties via TC.
> 
> Doug: I'm concerned that you think projects need to "defend their
>   interests" from what is intended to be a community-wide goal.
> 
> Doug: There's an unhealthy obsession with "consequences" in this
>   discussion. We expect everyone to do these things. We don't expect it
>   to be a big issue...Refusing to meet goals over a period of time
>   establishes a pattern that maybe a project doesn't really want to be
>   part of the common community.

Choosing to be a part of a community comes with obligations as well
as benefits.  If, after a lengthy discussion of a community-wide
goal, involving everyone in the community, a project team is
resolutely opposed to the goal, does that not indicate that the
needs of the project team and the needs of the broader community
are at odds in some way? And if the project team's needs and the
community needs are consistently at odds, over the course of a
series of such goals, why would the project team want to constrain
itself to stay in the community?  Aren't they clearly going in
different directions?

Understand, it is not my desire to emphasize any differences of
this nature. Rather, I want to reduce them. To do that, I am proposing
a process through which common goals can be identified, described,
and put into action. I do hope, though, that through the course of
the discussion of each individual proposal everyone involved will
come to understand the idea and by the time a proposal becomes a
"goal" to be implemented I "expect" everyone to, at the very least,
understand why a goal is important to others, even if they do not
agree with it. That understanding should then lead, on the basis
of agreeing to be part of a collaborative community, to supporting
the goal.

I also expect us to discuss a lot of proposals that we do not agree
on, and that either need more time to develop or that end up finding
another path to resolution. No one seems all that concerned with
the concept that they might propose a goal that everyone else doesn't
agree with.  :-)

So, yes, by the time we pick a goal I expect teams to do the work,
because at that point in the process they will see it as the
reasonable course of action.  There is still an "escape valve" in
place for teams that, after all of the discussion and shaping of
the goals is over, still take issue with a goal. By explaining their
position in their response, we will have reference documentation
to point to when the inevitable "why doesn't X do Y" questions
arise. I will be interested to see how often we actually have to
use that.

> >> As open-source project leaders, we don't tell our community what to
> >> do; we tell the broader ecosystem what our communities are doing.
> >
> > This is a complete mischaracterization of this initiative.
> >
> > The point of this process is to identify things that our community is
> > asking us to do that we are not doing, and to encourage project teams to
> > focus on those things. I have no doubt that teams are aware of what
> > their current, immediate, users are looking for. But we also need to be
> > aware of those things that affect all of openstack, and not just an
> > individual team. We need to collaborate as a community, and not limit
> > ourselves to the narrow vision of one product team.
> 
> Yes! Let's do the things users are asking us to work on, and encourage project
> teams to work together on them!
> 
> And like you, I do not want to have one project dictate what all the other projects
> should prioritize. (Or rather, a majority impose on a minority.) Since there is such
> a large and diverse community inside of OpenStack, let's not try to dictate a
> prioritization and due date.
> 
> The proposed plan has a lot of good in it, and I'm really happy to see the TC
> working to bring common goals and vision to the entirety of the OpenStack
> community. Drop the "project teams are expected to prioritize these goals above
> all other work", and my concerns evaporate. I'd be happy to agree to that proposal.

Saying that the community has goals but that no one is expected to
act to bring them about would be a meaningless waste of time and
energy.

Doug