Re: [openstack-dev] [all][tc] establishing project-wide goals

[Thomas Goirand]

I'm on the same page as Doug here.

On 08/01/2016 04:23 PM, Jay Pipes wrote:
> Likewise, what if the Manila project team decides they aren't interested
> in supporting Python 3.5

Any project that is actively deciding to not support the current version
of Python must indeed be kicked out, as it becomes not maintainable (it
downstream distros or otherwise).

On 08/01/2016 04:23 PM, Jay Pipes wrote:
> or a particular greenlet library du jour

That's another story which can be debated, IMO.

Cheers,

Thomas Goirand (zigo)


__
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] [all][tc] establishing project-wide goals

[Thomas Goirand]

On 07/29/2016 10:55 PM, Doug Hellmann wrote:
> 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"

Thanks a lot for working on this. Everything is well thought. Just one
thing, probably, "release goal" would be a better fit for naming this,
so that it puts the emphasis on deliverables.

Cheers,

Thomas Goirand (zigo)


__
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] [all][tc] establishing project-wide goals

[Colette Alexander]

On Tue, Aug 2, 2016 at 11:29 AM, Thierry Carrez  wrote:
>
> Doug Hellmann wrote:
> > [...]
> >> Likewise, what if the Manila project team decides they aren't interested
> >> in supporting Python 3.5 or a particular greenlet library du jour that
> >> has been mandated upon them? Is the only filesystem-as-a-service project
> >> going to be booted from the tent?
> >
> > I hardly think "move off of the EOL-ed version of our language" and
> > "use a library du jour" are in the same class.  All of the topics
> > discussed so far are either focused on eliminating technical debt
> > that project teams have not prioritized consistently or adding
> > features that, again for consistency, are deemed important by the
> > overall community (API microversioning falls in that category,
> > though that's an example and not in any way an approved goal right
> > now).
>
> Right, the proposal is pretty clearly about setting a number of
> reasonable, small goals for a release cycle that would be awesome to
> collectively reach. Not really invasive top-down design mandates that we
> would expect teams to want to resist.
>
> IMHO if a team has a good reason for not wanting or not being able to
> fulfill a common goal that's fine -- it just needs to get documented and
> should not result in itself in getting kicked out from anything. If a
> team regularly skips on common goals (and/or misses releases, and/or
> doesn't fix security issues) that's a general sign that it's not really
> behaving like an OpenStack project and then a case could be opened for
> removal, but there is nothing new here.
>

+1 to all of this.

As someone who was in leadership training with both Thierry and Doug,
I just want to point out that 'reasonable, small goals' and 'support a
particular library du jour or get kicked out of OpenStack' are
immensely different reads on the potential of this situation.

OpenStack suffers from a perception that it is not a usable, cohesive
set of projects that work together. Like many perceptions out in the
wild about OSS projects, that is part PR/spin/haters-gonna-hate, and
part reality. Apart from PR-land, the idea of having some basic
standards and cross-project goals to meet not just before a project is
accepted, but also as it matures, hopefully serves the ultimate
purpose of presenting an OpenStack with enough consistency and
usability that it doesn't make a user/operator want to throw a server
out the window.

Where does the technical independence of a project begin encroaching
on the ability of other projects to effectively work for their users
or their developer participation? Where do the desires of a single
project begin to negatively impact the entirety of OpenStack, and how
does the community respond when faced with tough situations like that?

The TC, as a body that oversees the overarching technical direction of
the entire group of projects, has identified areas where OpenStack
could be *highly* improved in its functionality and usability - those
certainly, on their surface, seem like noble goals for any person
creating any project with an end user that is not themselves. That the
TC is the mechanism to do that unifying, helpful, future-preserving
thing for OpenStack and also the same mechanism that, in the wrong
hands, could be used to ask impossible things of projects (and use
their failure to kick them out of the community, eventually) is
totally true, but it's also always been true of the TC. That's why
preserving our culture of leadership by election is so important -
leaders are elected to serve their constituents - *not* the other way
around.

-colette/gothicmindfood

__
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] [all][tc] establishing project-wide goals

[Flavio Percoco]

On 02/08/16 17:29 +0200, Thierry Carrez wrote:

Doug Hellmann wrote:

[...]

Likewise, what if the Manila project team decides they aren't interested
in supporting Python 3.5 or a particular greenlet library du jour that
has been mandated upon them? Is the only filesystem-as-a-service project
going to be booted from the tent?


I hardly think "move off of the EOL-ed version of our language" and
"use a library du jour" are in the same class.  All of the topics
discussed so far are either focused on eliminating technical debt
that project teams have not prioritized consistently or adding
features that, again for consistency, are deemed important by the
overall community (API microversioning falls in that category,
though that's an example and not in any way an approved goal right
now).


Right, the proposal is pretty clearly about setting a number of
reasonable, small goals for a release cycle that would be awesome to
collectively reach. Not really invasive top-down design mandates that we
would expect teams to want to resist.

IMHO if a team has a good reason for not wanting or not being able to
fulfill a common goal that's fine -- it just needs to get documented and
should not result in itself in getting kicked out from anything. If a
team regularly skips on common goals (and/or misses releases, and/or
doesn't fix security issues) that's a general sign that it's not really
behaving like an OpenStack project and then a case could be opened for
removal, but there is nothing new here.


I think some flexibility on this should be considered (as mentioned by Thierry
in the previous paragraph) but I'd be quite worried of extremely special-cased
projects and I'd like us to be able to act on this cases.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] [all][tc] establishing project-wide goals

[Clint Byrum]

Excerpts from Jay Pipes's message of 2016-08-01 10:23:57 -0400:
> On 08/01/2016 08:33 AM, Sean Dague wrote:
> > On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> >> 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"
> >
> > I like the direction this is headed. And I think for the test items, it
> > works pretty well.
> 
> I commented on the reviews, but I disagree with both the direction and 
> the proposed implementation of this.
> 
> In short, I think there's too much stick and not enough carrot. We 
> should create natural incentives for projects to achieve desired 
> alignment in certain areas, but placing mandates on project teams in a 
> diverse community like OpenStack is not useful.
> 
> The consequences of a project team *not* meeting these proposed mandates 
> has yet to be decided (and I made that point on the governance patch 
> review). But let's say that the consequences are that a project is 
> removed from the OpenStack big tent if they fail to complete these 
> "shared objectives".
> 
> What will we do when Swift decides that they have no intention of using 
> oslo.messaging or oslo.config because they can't stand fundamentals 
> about those libraries? Are we going to kick Swift, a founding project of 
> OpenStack, out of the OpenStack big tent?

Membership in the tent is the carrot, and ejection is the stick. The
big tent was an acknowledgement that giving out carrots makes everyone
stronger (all these well fed projects have led to a bigger supply of
carrots in general).

I think this proposal is an attempt to manage the ensuing chaos. We've
all seen carrot farmers abandon their farms, as well as duplicated effort
leading to a confusing experience for consumers of OpenStack's products.

I think there's room to build consensus around diversity in implementation
and even culture. We don't need to be a monolith. Our Swift development
community is bringing strong, powerful insight to the overall effort,
and strengthens the OpenStack brand considerably.  Certainly we can
support projects doing things their own way in some instances if they
so choose. What we don't want, however, is projects that operate in
relative isolation, without any cohesion, even loose cohesion, with the
rest.

__
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] [all][tc] establishing project-wide goals

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-08-02 16:30:06 +:
> On 02/08/2016 16:37, Doug Hellmann wrote:
> > Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +:
> >> On 02/08/2016 14:37, Doug Hellmann wrote:
> >>> Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +:
>  On 29/07/2016 21:59, Doug Hellmann wrote:
> > 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"
> 
>  I am confused. When I proposed my patch for doing something very similar
>  (Equal Chances for all projects is basically a multiple release goal) I
>  got the following rebuttals:
> 
>   > "and it would be
>   > a mistake to try to require that because the issue is almost always
>   > lack of resources and not lack of desire. Volunteers to contribute
>   > to the work that's needed will do more to help than a
>   > one-size-fits-all policy."
> 
>   > This isn't a thing that gets fixed with policy. It gets fixed with
>   > people.
> 
>   > I am reading through the thread, and it puzzles me that I see a lot
>   > of right words about goals but not enough hints on who is going to
>   > implement that.
> 
>   > I think the right solutions here are human ones. Talk with people.
>   > Figure out how you can help lighten their load so that they have
>   > breathing space. I think hiding behind policy becomes a way to make
>   > us more separate rather than engaging folks more directly.
> 
>   > Coming at this with top down declarations of how things should work
>   > not only ignores reality of the ecosystem and the current state of
>   > these projects, but is also going about things backwards.
> 
>   > This entirely ignores that these are all open source projects,
>   > which are often very sparsely contributed to. If you have an issue
>   > with a project or the interface it provides, then contribute to it.
>   > Don't make grandiose resolutions trying to force things into what you
>   > see as an ideal state, instead contribute to help fix the problems
>   > you've identified.
> 
>  And yet, we are currently suggesting a system that will actively (in an
>  undefined way) penalise projects who do not comply with a different set
>  of proposals, done in a top down manner.
> 
>  I may be missing the point, but the two proposals seem to have
>  similarities - what is the difference?
> 
>  When I see comments like:
> 
>   > Project teams who join the big tent sign up to the rights and
>   > responsibilities that go along with membership. Those responsibilities
>   > include taking some direction from the TC, including regarding work
>   > they may not give the same priority as the broader community.
> 
>  It sounds like top down is OK, but previous ML thread / TC feedback
>  has been different.
> >>>
> >>> One difference is that these goals are not things like "the
> >>> documentation team must include every service project in the
> >>> installation guide" but rather would be phrased like "every project
> >>> must provide an installation guide". The work 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Hayes, Graham]

On 02/08/2016 16:37, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +:
>> On 02/08/2016 14:37, Doug Hellmann wrote:
>>> Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +:
 On 29/07/2016 21:59, Doug Hellmann wrote:
> 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"

 I am confused. When I proposed my patch for doing something very similar
 (Equal Chances for all projects is basically a multiple release goal) I
 got the following rebuttals:

  > "and it would be
  > a mistake to try to require that because the issue is almost always
  > lack of resources and not lack of desire. Volunteers to contribute
  > to the work that's needed will do more to help than a
  > one-size-fits-all policy."

  > This isn't a thing that gets fixed with policy. It gets fixed with
  > people.

  > I am reading through the thread, and it puzzles me that I see a lot
  > of right words about goals but not enough hints on who is going to
  > implement that.

  > I think the right solutions here are human ones. Talk with people.
  > Figure out how you can help lighten their load so that they have
  > breathing space. I think hiding behind policy becomes a way to make
  > us more separate rather than engaging folks more directly.

  > Coming at this with top down declarations of how things should work
  > not only ignores reality of the ecosystem and the current state of
  > these projects, but is also going about things backwards.

  > This entirely ignores that these are all open source projects,
  > which are often very sparsely contributed to. If you have an issue
  > with a project or the interface it provides, then contribute to it.
  > Don't make grandiose resolutions trying to force things into what you
  > see as an ideal state, instead contribute to help fix the problems
  > you've identified.

 And yet, we are currently suggesting a system that will actively (in an
 undefined way) penalise projects who do not comply with a different set
 of proposals, done in a top down manner.

 I may be missing the point, but the two proposals seem to have
 similarities - what is the difference?

 When I see comments like:

  > Project teams who join the big tent sign up to the rights and
  > responsibilities that go along with membership. Those responsibilities
  > include taking some direction from the TC, including regarding work
  > they may not give the same priority as the broader community.

 It sounds like top down is OK, but previous ML thread / TC feedback
 has been different.
>>>
>>> One difference is that these goals are not things like "the
>>> documentation team must include every service project in the
>>> installation guide" but rather would be phrased like "every project
>>> must provide an installation guide". The work is distributed to the
>>> vertical teams, and not focused in the horizontal teams.
>>
>> Well, the wording was actually "the documentation team must provide a
>> way for all projects to be included in the documentation guide". The
>> work was on the 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Jay Pipes]

On 08/02/2016 11:29 AM, Thierry Carrez wrote:

Doug Hellmann wrote:

[...]

Likewise, what if the Manila project team decides they aren't interested
in supporting Python 3.5 or a particular greenlet library du jour that
has been mandated upon them? Is the only filesystem-as-a-service project
going to be booted from the tent?


I hardly think "move off of the EOL-ed version of our language" and
"use a library du jour" are in the same class.  All of the topics
discussed so far are either focused on eliminating technical debt
that project teams have not prioritized consistently or adding
features that, again for consistency, are deemed important by the
overall community (API microversioning falls in that category,
though that's an example and not in any way an approved goal right
now).


Right, the proposal is pretty clearly about setting a number of
reasonable, small goals for a release cycle that would be awesome to
collectively reach. Not really invasive top-down design mandates that we
would expect teams to want to resist.

IMHO if a team has a good reason for not wanting or not being able to
fulfill a common goal that's fine -- it just needs to get documented and
should not result in itself in getting kicked out from anything. If a
team regularly skips on common goals (and/or misses releases, and/or
doesn't fix security issues) that's a general sign that it's not really
behaving like an OpenStack project and then a case could be opened for
removal, but there is nothing new here.


Sure, I have no disagreement with any of the above. I just see TC 
mandates as a slippery slope. I'm practicing my OpenStack civic "duty" 
to guard against the encroachment of project technical independence.


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] [all][tc] establishing project-wide goals

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +:
> On 02/08/2016 14:37, Doug Hellmann wrote:
> > Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +:
> >> On 29/07/2016 21:59, Doug Hellmann wrote:
> >>> 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"
> >>
> >> I am confused. When I proposed my patch for doing something very similar
> >> (Equal Chances for all projects is basically a multiple release goal) I
> >> got the following rebuttals:
> >>
> >>  > "and it would be
> >>  > a mistake to try to require that because the issue is almost always
> >>  > lack of resources and not lack of desire. Volunteers to contribute
> >>  > to the work that's needed will do more to help than a
> >>  > one-size-fits-all policy."
> >>
> >>  > This isn't a thing that gets fixed with policy. It gets fixed with
> >>  > people.
> >>
> >>  > I am reading through the thread, and it puzzles me that I see a lot
> >>  > of right words about goals but not enough hints on who is going to
> >>  > implement that.
> >>
> >>  > I think the right solutions here are human ones. Talk with people.
> >>  > Figure out how you can help lighten their load so that they have
> >>  > breathing space. I think hiding behind policy becomes a way to make
> >>  > us more separate rather than engaging folks more directly.
> >>
> >>  > Coming at this with top down declarations of how things should work
> >>  > not only ignores reality of the ecosystem and the current state of
> >>  > these projects, but is also going about things backwards.
> >>
> >>  > This entirely ignores that these are all open source projects,
> >>  > which are often very sparsely contributed to. If you have an issue
> >>  > with a project or the interface it provides, then contribute to it.
> >>  > Don't make grandiose resolutions trying to force things into what you
> >>  > see as an ideal state, instead contribute to help fix the problems
> >>  > you've identified.
> >>
> >> And yet, we are currently suggesting a system that will actively (in an
> >> undefined way) penalise projects who do not comply with a different set
> >> of proposals, done in a top down manner.
> >>
> >> I may be missing the point, but the two proposals seem to have
> >> similarities - what is the difference?
> >>
> >> When I see comments like:
> >>
> >>  > Project teams who join the big tent sign up to the rights and
> >>  > responsibilities that go along with membership. Those responsibilities
> >>  > include taking some direction from the TC, including regarding work
> >>  > they may not give the same priority as the broader community.
> >>
> >> It sounds like top down is OK, but previous ML thread / TC feedback
> >> has been different.
> >
> > One difference is that these goals are not things like "the
> > documentation team must include every service project in the
> > installation guide" but rather would be phrased like "every project
> > must provide an installation guide". The work is distributed to the
> > vertical teams, and not focused in the horizontal teams.
> 
> Well, the wording was actually "the documentation team must provide a
> way for all projects to be included in the documentation guide". The
> work was on the horizontal teams to provide a method, and the 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Thierry Carrez]

Doug Hellmann wrote:
> [...]
>> Likewise, what if the Manila project team decides they aren't interested 
>> in supporting Python 3.5 or a particular greenlet library du jour that 
>> has been mandated upon them? Is the only filesystem-as-a-service project 
>> going to be booted from the tent?
> 
> I hardly think "move off of the EOL-ed version of our language" and
> "use a library du jour" are in the same class.  All of the topics
> discussed so far are either focused on eliminating technical debt
> that project teams have not prioritized consistently or adding
> features that, again for consistency, are deemed important by the
> overall community (API microversioning falls in that category,
> though that's an example and not in any way an approved goal right
> now).

Right, the proposal is pretty clearly about setting a number of
reasonable, small goals for a release cycle that would be awesome to
collectively reach. Not really invasive top-down design mandates that we
would expect teams to want to resist.

IMHO if a team has a good reason for not wanting or not being able to
fulfill a common goal that's fine -- it just needs to get documented and
should not result in itself in getting kicked out from anything. If a
team regularly skips on common goals (and/or misses releases, and/or
doesn't fix security issues) that's a general sign that it's not really
behaving like an OpenStack project and then a case could be opened for
removal, but there is nothing new here.

-- 
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] [all][tc] establishing project-wide goals

[Hayes, Graham]

On 02/08/2016 14:37, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +:
>> On 29/07/2016 21:59, Doug Hellmann wrote:
>>> 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"
>>
>> I am confused. When I proposed my patch for doing something very similar
>> (Equal Chances for all projects is basically a multiple release goal) I
>> got the following rebuttals:
>>
>>  > "and it would be
>>  > a mistake to try to require that because the issue is almost always
>>  > lack of resources and not lack of desire. Volunteers to contribute
>>  > to the work that's needed will do more to help than a
>>  > one-size-fits-all policy."
>>
>>  > This isn't a thing that gets fixed with policy. It gets fixed with
>>  > people.
>>
>>  > I am reading through the thread, and it puzzles me that I see a lot
>>  > of right words about goals but not enough hints on who is going to
>>  > implement that.
>>
>>  > I think the right solutions here are human ones. Talk with people.
>>  > Figure out how you can help lighten their load so that they have
>>  > breathing space. I think hiding behind policy becomes a way to make
>>  > us more separate rather than engaging folks more directly.
>>
>>  > Coming at this with top down declarations of how things should work
>>  > not only ignores reality of the ecosystem and the current state of
>>  > these projects, but is also going about things backwards.
>>
>>  > This entirely ignores that these are all open source projects,
>>  > which are often very sparsely contributed to. If you have an issue
>>  > with a project or the interface it provides, then contribute to it.
>>  > Don't make grandiose resolutions trying to force things into what you
>>  > see as an ideal state, instead contribute to help fix the problems
>>  > you've identified.
>>
>> And yet, we are currently suggesting a system that will actively (in an
>> undefined way) penalise projects who do not comply with a different set
>> of proposals, done in a top down manner.
>>
>> I may be missing the point, but the two proposals seem to have
>> similarities - what is the difference?
>>
>> When I see comments like:
>>
>>  > Project teams who join the big tent sign up to the rights and
>>  > responsibilities that go along with membership. Those responsibilities
>>  > include taking some direction from the TC, including regarding work
>>  > they may not give the same priority as the broader community.
>>
>> It sounds like top down is OK, but previous ML thread / TC feedback
>> has been different.
>
> One difference is that these goals are not things like "the
> documentation team must include every service project in the
> installation guide" but rather would be phrased like "every project
> must provide an installation guide". The work is distributed to the
> vertical teams, and not focused in the horizontal teams.

Well, the wording was actually "the documentation team must provide a
way for all projects to be included in the documentation guide". The
work was on the horizontal teams to provide a method, and the vertical
teams to do the actual writing, as an example (that is actually
underway, so it is a bad example.)

A better example would be OSC / Horizon has to provide a way for plugins
to set quotas - it is up to the project teams to actually implement the
code the sets 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +:
> On 29/07/2016 21:59, Doug Hellmann wrote:
> > 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"
> 
> I am confused. When I proposed my patch for doing something very similar
> (Equal Chances for all projects is basically a multiple release goal) I
> got the following rebuttals:
> 
>  > "and it would be
>  > a mistake to try to require that because the issue is almost always
>  > lack of resources and not lack of desire. Volunteers to contribute
>  > to the work that's needed will do more to help than a
>  > one-size-fits-all policy."
> 
>  > This isn't a thing that gets fixed with policy. It gets fixed with
>  > people.
> 
>  > I am reading through the thread, and it puzzles me that I see a lot
>  > of right words about goals but not enough hints on who is going to
>  > implement that.
> 
>  > I think the right solutions here are human ones. Talk with people.
>  > Figure out how you can help lighten their load so that they have
>  > breathing space. I think hiding behind policy becomes a way to make
>  > us more separate rather than engaging folks more directly.
> 
>  > Coming at this with top down declarations of how things should work
>  > not only ignores reality of the ecosystem and the current state of
>  > these projects, but is also going about things backwards.
> 
>  > This entirely ignores that these are all open source projects,
>  > which are often very sparsely contributed to. If you have an issue
>  > with a project or the interface it provides, then contribute to it.
>  > Don't make grandiose resolutions trying to force things into what you
>  > see as an ideal state, instead contribute to help fix the problems
>  > you've identified.
> 
> And yet, we are currently suggesting a system that will actively (in an
> undefined way) penalise projects who do not comply with a different set
> of proposals, done in a top down manner.
> 
> I may be missing the point, but the two proposals seem to have 
> similarities - what is the difference?
> 
> When I see comments like:
> 
>  > Project teams who join the big tent sign up to the rights and
>  > responsibilities that go along with membership. Those responsibilities
>  > include taking some direction from the TC, including regarding work
>  > they may not give the same priority as the broader community.
> 
> It sounds like top down is OK, but previous ML thread / TC feedback
> has been different.

One difference is that these goals are not things like "the
documentation team must include every service project in the
installation guide" but rather would be phrased like "every project
must provide an installation guide". The work is distributed to the
vertical teams, and not focused in the horizontal teams.

Doug

> 
> - Graham
> 
> > __
> > 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Doug Hellmann]

Excerpts from Shamail's message of 2016-08-01 22:37:28 -0500:
> Thanks Doug,
> 
> > On Aug 1, 2016, at 10:44 AM, Doug Hellmann  wrote:
> > 
> > Excerpts from Shamail Tahir's message of 2016-08-01 09:49:35 -0500:
> >>> On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann  
> >>> wrote:
> >>> 
> >>> Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400:
> > On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> > 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"
>  
>  I like the direction this is headed. And I think for the test items, it
>  works pretty well.
>  
>  I'm trying to think about how we'd use a model like this to support
>  something a little more abstract such as making upgrades easier. Where
>  we've got a few things that we know get in the way (policy in files,
>  rootwrap rules, paste ini changes), as well as validation, as well as
>  configuration changes. And what it looks like for persistently important
>  items which are going to take more than a cycle to get through.
> >>> 
> >>> If we think the goal can be completed in a single cycle, then those
> >>> specific items can just be used to define "done" ("all policy
> >>> definitions have defaults in code and the service works without a policy
> >>> configuration file" or whatever). If the goal cannot be completed in a
> >>> single cycle, then it would need to be broken up in to phases.
> >>> 
>  
>  Definitely seems worth giving it a shot on the current set of items, and
>  see how it fleshes out.
>  
>  My only concern at this point is it seems like we're building nested
>  data structures that people are going to want to parse into some kind of
>  visualization in RST, which is a sub optimal parsing format. If we know
>  that people want to parse this in advance, yamling it up might be in
>  order. Because this mostly looks like it would reduce to one of those
>  green/yellow/red checker boards by project and task.
> >>> 
> >>> That's a good idea. How about if I commit to translate what we end
> >>> up with to YAML during Ocata, but we evolve the first version using
> >>> the RST since that's simpler to review for now?
> >> 
> >> We have created a tracker file[1][2] for user stories (minor changes
> >> pending based on feedback) in the Product WG repo.  We are currently
> >> working with the infra team to get a visualization tool deployed that shows
> >> the status for each artifact and provides links so that people can get more
> >> details as necessary.  Could something similar be (re)used here?
> > 
> > Possibly. I don't want to tie the governance part of the process
> > to tightly to any project management tools, since those tend to
> > change, but if the project-specific tracking artifacts exist in
> > that form then linking to them would be appropriate.
> The purpose of the tracking is to link existing project-level artifacts 
> including cross project specs and service level specs/blueprints.  Once the 
> tool is deployed, we can see if it fits this need.
> > 
> >> 
> >> I also have a general question about whether goals could be documented as
> >> 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Hayes, Graham]

On 29/07/2016 21:59, Doug Hellmann wrote:
> 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"

I am confused. When I proposed my patch for doing something very similar
(Equal Chances for all projects is basically a multiple release goal) I
got the following rebuttals:

 > "and it would be
 > a mistake to try to require that because the issue is almost always
 > lack of resources and not lack of desire. Volunteers to contribute
 > to the work that's needed will do more to help than a
 > one-size-fits-all policy."

 > This isn't a thing that gets fixed with policy. It gets fixed with
 > people.

 > I am reading through the thread, and it puzzles me that I see a lot
 > of right words about goals but not enough hints on who is going to
 > implement that.

 > I think the right solutions here are human ones. Talk with people.
 > Figure out how you can help lighten their load so that they have
 > breathing space. I think hiding behind policy becomes a way to make
 > us more separate rather than engaging folks more directly.

 > Coming at this with top down declarations of how things should work
 > not only ignores reality of the ecosystem and the current state of
 > these projects, but is also going about things backwards.

 > This entirely ignores that these are all open source projects,
 > which are often very sparsely contributed to. If you have an issue
 > with a project or the interface it provides, then contribute to it.
 > Don't make grandiose resolutions trying to force things into what you
 > see as an ideal state, instead contribute to help fix the problems
 > you've identified.

And yet, we are currently suggesting a system that will actively (in an
undefined way) penalise projects who do not comply with a different set
of proposals, done in a top down manner.

I may be missing the point, but the two proposals seem to have 
similarities - what is the difference?

When I see comments like:

 > Project teams who join the big tent sign up to the rights and
 > responsibilities that go along with membership. Those responsibilities
 > include taking some direction from the TC, including regarding work
 > they may not give the same priority as the broader community.

It sounds like top down is OK, but previous ML thread / TC feedback
has been different.

- Graham

> __
> 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Shamail]

Thanks Doug,

> On Aug 1, 2016, at 10:44 AM, Doug Hellmann  wrote:
> 
> Excerpts from Shamail Tahir's message of 2016-08-01 09:49:35 -0500:
>>> On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann  wrote:
>>> 
>>> Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400:
> On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> 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"
 
 I like the direction this is headed. And I think for the test items, it
 works pretty well.
 
 I'm trying to think about how we'd use a model like this to support
 something a little more abstract such as making upgrades easier. Where
 we've got a few things that we know get in the way (policy in files,
 rootwrap rules, paste ini changes), as well as validation, as well as
 configuration changes. And what it looks like for persistently important
 items which are going to take more than a cycle to get through.
>>> 
>>> If we think the goal can be completed in a single cycle, then those
>>> specific items can just be used to define "done" ("all policy
>>> definitions have defaults in code and the service works without a policy
>>> configuration file" or whatever). If the goal cannot be completed in a
>>> single cycle, then it would need to be broken up in to phases.
>>> 
 
 Definitely seems worth giving it a shot on the current set of items, and
 see how it fleshes out.
 
 My only concern at this point is it seems like we're building nested
 data structures that people are going to want to parse into some kind of
 visualization in RST, which is a sub optimal parsing format. If we know
 that people want to parse this in advance, yamling it up might be in
 order. Because this mostly looks like it would reduce to one of those
 green/yellow/red checker boards by project and task.
>>> 
>>> That's a good idea. How about if I commit to translate what we end
>>> up with to YAML during Ocata, but we evolve the first version using
>>> the RST since that's simpler to review for now?
>> 
>> We have created a tracker file[1][2] for user stories (minor changes
>> pending based on feedback) in the Product WG repo.  We are currently
>> working with the infra team to get a visualization tool deployed that shows
>> the status for each artifact and provides links so that people can get more
>> details as necessary.  Could something similar be (re)used here?
> 
> Possibly. I don't want to tie the governance part of the process
> to tightly to any project management tools, since those tend to
> change, but if the project-specific tracking artifacts exist in
> that form then linking to them would be appropriate.
The purpose of the tracking is to link existing project-level artifacts 
including cross project specs and service level specs/blueprints.  Once the 
tool is deployed, we can see if it fits this need.
> 
>> 
>> I also have a general question about whether goals could be documented as
>> user stories[3]?
> 
> I would expect some of the goals to come from user stories, and in
> those cases references to those stories would be appropriate.
> However, we need much more specific detail to describe "done" than
> is typically found in a user 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2016-08-01 10:23:57 -0400:
> On 08/01/2016 08:33 AM, Sean Dague wrote:
> > On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> >> 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"
> >
> > I like the direction this is headed. And I think for the test items, it
> > works pretty well.
> 
> I commented on the reviews, but I disagree with both the direction and 
> the proposed implementation of this.
> 
> In short, I think there's too much stick and not enough carrot. We 
> should create natural incentives for projects to achieve desired 
> alignment in certain areas, but placing mandates on project teams in a 
> diverse community like OpenStack is not useful.
> 
> The consequences of a project team *not* meeting these proposed mandates 
> has yet to be decided (and I made that point on the governance patch 
> review). But let's say that the consequences are that a project is 
> removed from the OpenStack big tent if they fail to complete these 
> "shared objectives".
> 
> What will we do when Swift decides that they have no intention of using 
> oslo.messaging or oslo.config because they can't stand fundamentals 
> about those libraries? Are we going to kick Swift, a founding project of 
> OpenStack, out of the OpenStack big tent?

Yes, your point about the title of that specific proposal is well
made.  I'll be renaming it to "remove obsolete incubated version
of Oslo code" or something similar in the next draft to avoid
confusion.

> Likewise, what if the Manila project team decides they aren't interested 
> in supporting Python 3.5 or a particular greenlet library du jour that 
> has been mandated upon them? Is the only filesystem-as-a-service project 
> going to be booted from the tent?

I hardly think "move off of the EOL-ed version of our language" and
"use a library du jour" are in the same class.  All of the topics
discussed so far are either focused on eliminating technical debt
that project teams have not prioritized consistently or adding
features that, again for consistency, are deemed important by the
overall community (API microversioning falls in that category,
though that's an example and not in any way an approved goal right
now).

> When it comes to the internal implementation of projects, my strong 
> belief is that we should let the project teams be laboratories of 
> innovation and avoid placing mandates on them.
> 
> Let projects choose from a set of vetted options for important libraries 
> or frameworks and allow a project to pave its own road if the project 
> team can justify a reason for that which outweighs any vetted choice 
> (Zaqar's choice to use Falcon fits this kind of thing).

We might have a goal that says projects should drop unapproved
tools. I don't think so far we've considered any that say they
should all use a specific tool that isn't already widely used. I'm
having trouble thinking of an example of that sort of thing that I
would support, but at the same time I'm not prepared to say we would
never do something like that just because of my lack of imagination
this morning. How about if we argue the merits of actual goal
proposals when they're made, instead of posing hypothetical scenarios?

> Finally, instead of these shared OpenStack-wide goals being a different 
> stick-thing for 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Doug Hellmann]

Excerpts from Shamail Tahir's message of 2016-08-01 09:49:35 -0500:
> On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann  wrote:
> 
> > Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400:
> > > On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> > > > 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"
> > >
> > > I like the direction this is headed. And I think for the test items, it
> > > works pretty well.
> > >
> > > I'm trying to think about how we'd use a model like this to support
> > > something a little more abstract such as making upgrades easier. Where
> > > we've got a few things that we know get in the way (policy in files,
> > > rootwrap rules, paste ini changes), as well as validation, as well as
> > > configuration changes. And what it looks like for persistently important
> > > items which are going to take more than a cycle to get through.
> >
> > If we think the goal can be completed in a single cycle, then those
> > specific items can just be used to define "done" ("all policy
> > definitions have defaults in code and the service works without a policy
> > configuration file" or whatever). If the goal cannot be completed in a
> > single cycle, then it would need to be broken up in to phases.
> >
> > >
> > > Definitely seems worth giving it a shot on the current set of items, and
> > > see how it fleshes out.
> > >
> > > My only concern at this point is it seems like we're building nested
> > > data structures that people are going to want to parse into some kind of
> > > visualization in RST, which is a sub optimal parsing format. If we know
> > > that people want to parse this in advance, yamling it up might be in
> > > order. Because this mostly looks like it would reduce to one of those
> > > green/yellow/red checker boards by project and task.
> >
> > That's a good idea. How about if I commit to translate what we end
> > up with to YAML during Ocata, but we evolve the first version using
> > the RST since that's simpler to review for now?
> 
> We have created a tracker file[1][2] for user stories (minor changes
> pending based on feedback) in the Product WG repo.  We are currently
> working with the infra team to get a visualization tool deployed that shows
> the status for each artifact and provides links so that people can get more
> details as necessary.  Could something similar be (re)used here?

Possibly. I don't want to tie the governance part of the process
to tightly to any project management tools, since those tend to
change, but if the project-specific tracking artifacts exist in
that form then linking to them would be appropriate.

> 
> I also have a general question about whether goals could be documented as
> user stories[3]?

I would expect some of the goals to come from user stories, and in
those cases references to those stories would be appropriate.
However, we need much more specific detail to describe "done" than
is typically found in a user story, so just having a story won't
be sufficient. It's the difference between "As a deployer, I can
run OpenStack on Python 3.5" and "There are voting gate jobs running
all of the integration tests for a project under Python 3.5."

Doug

> 
> >
> 
> > Doug
> >
> 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Shamail Tahir]

On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann  wrote:

> Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400:
> > On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> > > 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"
> >
> > I like the direction this is headed. And I think for the test items, it
> > works pretty well.
> >
> > I'm trying to think about how we'd use a model like this to support
> > something a little more abstract such as making upgrades easier. Where
> > we've got a few things that we know get in the way (policy in files,
> > rootwrap rules, paste ini changes), as well as validation, as well as
> > configuration changes. And what it looks like for persistently important
> > items which are going to take more than a cycle to get through.
>
> If we think the goal can be completed in a single cycle, then those
> specific items can just be used to define "done" ("all policy
> definitions have defaults in code and the service works without a policy
> configuration file" or whatever). If the goal cannot be completed in a
> single cycle, then it would need to be broken up in to phases.
>
> >
> > Definitely seems worth giving it a shot on the current set of items, and
> > see how it fleshes out.
> >
> > My only concern at this point is it seems like we're building nested
> > data structures that people are going to want to parse into some kind of
> > visualization in RST, which is a sub optimal parsing format. If we know
> > that people want to parse this in advance, yamling it up might be in
> > order. Because this mostly looks like it would reduce to one of those
> > green/yellow/red checker boards by project and task.
>
> That's a good idea. How about if I commit to translate what we end
> up with to YAML during Ocata, but we evolve the first version using
> the RST since that's simpler to review for now?

We have created a tracker file[1][2] for user stories (minor changes
pending based on feedback) in the Product WG repo.  We are currently
working with the infra team to get a visualization tool deployed that shows
the status for each artifact and provides links so that people can get more
details as necessary.  Could something similar be (re)used here?

I also have a general question about whether goals could be documented as
user stories[3]?


>


> Doug
>
> >
> > -Sean
> >
>
> __
> 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
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time

[1]
https://github.com/openstack/openstack-user-stories/blob/master/doc/source/tracker_overview.rst
[2]
https://github.com/openstack/openstack-user-stories/blob/master/user-story-tracker.json
[3]
https://github.com/openstack/openstack-user-stories/blob/master/user-story-template.rst
__
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] [all][tc] establishing project-wide goals

[Jay Pipes]

On 08/01/2016 08:33 AM, Sean Dague wrote:

On 07/29/2016 04:55 PM, Doug Hellmann wrote:

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"


I like the direction this is headed. And I think for the test items, it
works pretty well.


I commented on the reviews, but I disagree with both the direction and 
the proposed implementation of this.


In short, I think there's too much stick and not enough carrot. We 
should create natural incentives for projects to achieve desired 
alignment in certain areas, but placing mandates on project teams in a 
diverse community like OpenStack is not useful.


The consequences of a project team *not* meeting these proposed mandates 
has yet to be decided (and I made that point on the governance patch 
review). But let's say that the consequences are that a project is 
removed from the OpenStack big tent if they fail to complete these 
"shared objectives".


What will we do when Swift decides that they have no intention of using 
oslo.messaging or oslo.config because they can't stand fundamentals 
about those libraries? Are we going to kick Swift, a founding project of 
OpenStack, out of the OpenStack big tent?


Likewise, what if the Manila project team decides they aren't interested 
in supporting Python 3.5 or a particular greenlet library du jour that 
has been mandated upon them? Is the only filesystem-as-a-service project 
going to be booted from the tent?


When it comes to the internal implementation of projects, my strong 
belief is that we should let the project teams be laboratories of 
innovation and avoid placing mandates on them.


Let projects choose from a set of vetted options for important libraries 
or frameworks and allow a project to pave its own road if the project 
team can justify a reason for that which outweighs any vetted choice 
(Zaqar's choice to use Falcon fits this kind of thing).


Finally, instead of these shared OpenStack-wide goals being a different 
stick-thing for the TC to use, why not just make tags that projects can 
*choose* to pursue, therefore building in the incentive (as opposed to 
the punishment) to align with a direction the TC feels is a good one.


You could have tags like:

 supports:python-3.5

or

 supports:oslo-only

or things like that. Project teams could then endeavour to achieve said 
tags if they feel that such a tag absolutely aligns with the team's goals.


Just my two cents,
-jay


I'm trying to think about how we'd use a model like this to support
something a little more abstract such as making upgrades easier. Where
we've got a few things that we know get in the way (policy in files,
rootwrap rules, paste ini changes), as well as validation, as well as
configuration changes. And what it looks like for persistently important
items which are going to take more than a cycle to get through.

Definitely seems worth giving it a shot on the current set of items, and
see how it fleshes out.

My only concern at this point is it seems like we're building nested
data structures that people are going to want to parse into some kind of
visualization in RST, which is a sub optimal parsing format. If we know
that people want to parse this in advance, yamling it up might be in
order. Because this mostly looks like it would reduce to one of those
green/yellow/red checker boards by project and task.

-Sean



__
OpenStack Development Mailing 

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400:
> On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> > 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"
> 
> I like the direction this is headed. And I think for the test items, it
> works pretty well.
> 
> I'm trying to think about how we'd use a model like this to support
> something a little more abstract such as making upgrades easier. Where
> we've got a few things that we know get in the way (policy in files,
> rootwrap rules, paste ini changes), as well as validation, as well as
> configuration changes. And what it looks like for persistently important
> items which are going to take more than a cycle to get through.

If we think the goal can be completed in a single cycle, then those
specific items can just be used to define "done" ("all policy
definitions have defaults in code and the service works without a policy
configuration file" or whatever). If the goal cannot be completed in a
single cycle, then it would need to be broken up in to phases.

> 
> Definitely seems worth giving it a shot on the current set of items, and
> see how it fleshes out.
> 
> My only concern at this point is it seems like we're building nested
> data structures that people are going to want to parse into some kind of
> visualization in RST, which is a sub optimal parsing format. If we know
> that people want to parse this in advance, yamling it up might be in
> order. Because this mostly looks like it would reduce to one of those
> green/yellow/red checker boards by project and task.

That's a good idea. How about if I commit to translate what we end
up with to YAML during Ocata, but we evolve the first version using
the RST since that's simpler to review for now?

Doug

> 
> -Sean
> 

__
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] [all][tc] establishing project-wide goals

[Sean Dague]

On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> 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"

I like the direction this is headed. And I think for the test items, it
works pretty well.

I'm trying to think about how we'd use a model like this to support
something a little more abstract such as making upgrades easier. Where
we've got a few things that we know get in the way (policy in files,
rootwrap rules, paste ini changes), as well as validation, as well as
configuration changes. And what it looks like for persistently important
items which are going to take more than a cycle to get through.

Definitely seems worth giving it a shot on the current set of items, and
see how it fleshes out.

My only concern at this point is it seems like we're building nested
data structures that people are going to want to parse into some kind of
visualization in RST, which is a sub optimal parsing format. If we know
that people want to parse this in advance, yamling it up might be in
order. Because this mostly looks like it would reduce to one of those
green/yellow/red checker boards by project and task.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [all][tc] establishing project-wide goals

[Amrith Kumar]

Doug,

Thanks for doing this. In the interests of transparency and full disclosure, I 
was at the leadership training and heard about this idea there (and was 
strongly in favor of it then, as I am now).

I think it is very important that OpenStack not devolve into a loose 
confederation of bags of code that are governed in similar ways, but rather a 
collection of software that address a set of meaningful needs in a consistent 
and compatible way. The goal is that to operators and deployers, OpenStack is a 
platform consisting of projects that work well together (the thing I called 
'consistent and compatible' earlier).

I see from the comments in the review [1] that there is some concern about the 
section on 'acknowledgement'.

Of what material benefit is it if the TC were to mandate something and the 
communication to the projects is some open-loop process? The 'acknowledgement' 
that Doug refers to in the review is merely a mechanism to 'close' that loop 
and ensure that projects affirm that they have been informed of the project 
wide goals, and that the PTL's will take some concrete steps that can be 
tracked through our usual processes (bugs, reviews, and so on) to ensure that 
the mandates are met.

To a more coherent and consistent platform!

-amrith



> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: Friday, July 29, 2016 4:55 PM
> To: openstack-dev 
> Subject: [openstack-dev] [all][tc] establishing project-wide goals
> 
> 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"
> 
> __
> 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev