Re: [openstack-dev] [tc][all] Missing answers on Pike release goals

[Doug Hellmann]

Excerpts from John Dickinson's message of 2017-05-23 09:12:29 -0700:
> 
> I can sympathize with the "do it tomorrow" turns into 6 weeks later...
>
> Part of the issue for me, personally, is that a governance patch
> does *not* feel simple or lightweight. I assume (in part based on
> experience) that any governance patch I propose will be closely
> examined and I will be forced to justify every corner case and
> comment made. Frankly, writing the patch that will stand up too a
> critical eye will take a long time. I'll do it tomorrow...

Maybe this does point to a need to move that information somewhere else.
It would ultimately be the same people reviewing it, though. I feel
strongly that we need the review step, but if folks think a different
repository would make a difference I'd be happy to set that up.

> Let's take the py3 goal as an example. Note: I am *not* wanting
> to get into a discussion about particular py3 issues or whatever.
> This is a discussion on the goals process, and I'm only using one
> of the current goals as an example of why I haven't proposed a
> governance patch for it.

> Swift does not support Py3. So clearly, there's work to be done
> to meet the goal. I've talked with others in the community about
> some of the blockers and concerns about porting to Py3. Several of
> the concerns are not trivial and will take substantial work to
> overcome[1]. A governance patch will need to list these issues, but
> I don't know if this is a complete list. If I propose a list that's
> incomplete, I feel like I'll be judged on the list I first proposed
> ("you finished the list, why doesn't it work?") instead of being a
> more dynamic process. I need to spend more time understanding what
> the issues are to make sure I have a complete list. I'll propose
> that patch tomorrow...

The patch does not necessarily need to list every detail. The purpose
of having a list of artifacts in the goal document is so that anyone
who wants to understand the state of the implementation can go look
there.  So, for example, if you're using a wiki page or an etherpad
to keep track of the details within the team, the patch only needs
to include a link to that. Some teams have done more, linking to
specs or changes that are already under review. Exactly what type
of artifact counts for a team is really up to that team.

The point is to show that each team is aware of the goal, and that
they've put together information in a place that someone outside
of the team can find it to either help, or at least follow progress.

> The outstanding work to get Py3 support in Swift is very large.
> Yet there are more goals being discussed now, and there's no way I
> can get Py3 support in Swift in Pike. Or Queens. Or probably Rocky
> either. That's not to say it isn't an important goal, but the scope
> combined with the TC deadline means that my governance patch for
> this goal (the tl;dr version is "not gonna happen") has to address
> this in sufficient detail to stand up to review by TC members who
> are on the PSF! I guess I'll start writing that tomorrow...

Some teams have a bit of a head start, but we expect many teams to
find the Python 3 work more than can be completed in a cycle. That's
perfectly OK. At the end of the cycle, we'll see where things stand,
and determine what the next steps are. That retrospective process
will be up to the teams, but I would expect it to factor into the
TC's decisions about what goals are adopted for Queens.

We don't want to have a big pile of unmet goals that all teams are
struggling to make progress on. That's why we have been limiting
ourselves to 1-2 goals per cycle.

> While I know that Py3 support is important, I also have to
> prioritize it against other important things. My employer has
> prioritized certain features because that directly impacts our
> ability to add customers (which directly affects my ability to get
> paid). Other employers in the community are doing the same for their
> employees. In the broader community, as clusters have grown over

There is undoubtedly tension between upstream and downstream needs
in some of these areas. We see that tension a lot with cross-project
initiatives. I don't have a good generic answer to the problem of
balancing community and employer needs, so I think the conversation
will have to happen case-by-case.

If we're finding that all of the contributors to a team are discouraged
from working on technical debt issues or other community goals in,
we'll need to address that. Uncovering that bit of information would
be an important outcome for the goals process, especially if it is
stated as directly as "no team member is being given time by their
employer to work on this community goal." If there is no response
from a team at all, though, we have no idea why that is the case.

If we know a team has issues tracking the goals due to a lack of
resources, then when the Board asks "how can we help," as they do
every time we have a joint 

Re: [openstack-dev] [tc][all] Missing answers on Pike release goals

[John Dickinson]

On 23 May 2017, at 8:05, Doug Hellmann wrote:

> Excerpts from Sean McGinnis's message of 2017-05-23 08:58:08 -0500:

 - Is it that the reporting process is too heavy ? (requiring answers
 from projects that are obviously unaffected)
>>>
>>> I've thought about this, OSC was unaffected by one of the goals but
>>> not the other, so I can't really hide in this bucket.  It really is
>>> not that hard to put up a review saying "not me".
>>>
 - Is it that people ignore the deadlines and missed the reminders ?
 (some unaffected project teams also do not do releases, and therefore
 ignore the release countdown emails)
>>>
>>> In my case, not so much "ignore" but "put off until tomorrow" where
>>> tomorrow turned in to 6 weeks.  I really don't have a hard reason
>>> other than simply not prioritizing it because I knew one of the goals
>>> was going to take some coordination work
>>>
>>
>> +1 - this has been my case, unfortunately.
>>
>> A patch submission has the feeling of a major thing that goes through
>> a lot of process (at least still in my head). I wonder if we would be
>> better off tracking some of this through a wiki page or even an
>> etherpad, with just the completion of the goal being something
>> submitted to the repo. Then it would be really easy to update at any
>> point with notes like "WIP patch put up but still working on it" along
>> the way.
>
> The review process for this type of governance patch is pretty light
> (they fall under the one-week-no-objections house rule), but I
> decided to use a patch instead of the wiki specifically because it
> allows for feedback. We've had several cases where teams didn't
> provide enough detail or didn't think a goal applied to them when
> it did (deploying with WSGI came up at least once).  Wiki changes
> can be tracked, but if someone has a question they have to go track
> down the author in some other venue to get it answered.
>
> I also didn't want teams to have to keep anything up to date during
> the cycle, because I didn't want this to be yet another "status
> report". Each goal needs at most 2 patches: one at the start of the
> cycle to acknowledge and point to whatever other artifacts are being
> used for tracking the work already, and then one at the end of the
> cycle to indicate how much of the work was completed and what the
> next steps are. We tied the process deadlines to existing deadlines
> when we thought teams would already be thinking of these sorts of
> topics (most teams have spec deadlines around milestone 1 and then
> everyone has the same release date at the end of the cycle).
>

I can sympathize with the "do it tomorrow" turns into 6 weeks later...

Part of the issue for me, personally, is that a governance patch does *not* 
feel simple or lightweight. I assume (in part based on experience) that any 
governance patch I propose will be closely examined and I will be forced to 
justify every corner case and comment made. Frankly, writing the patch that 
will stand up too a critical eye will take a long time. I'll do it tomorrow...

Let's take the py3 goal as an example. Note: I am *not* wanting to get into a 
discussion about particular py3 issues or whatever. This is a discussion on the 
goals process, and I'm only using one of the current goals as an example of why 
I haven't proposed a governance patch for it.

Swift does not support Py3. So clearly, there's work to be done to meet the 
goal. I've talked with others in the community about some of the blockers and 
concerns about porting to Py3. Several of the concerns are not trivial and will 
take substantial work to overcome[1]. A governance patch will need to list 
these issues, but I don't know if this is a complete list. If I propose a list 
that's incomplete, I feel like I'll be judged on the list I first proposed 
("you finished the list, why doesn't it work?") instead of being a more dynamic 
process. I need to spend more time understanding what the issues are to make 
sure I have a complete list. I'll propose that patch tomorrow...

The outstanding work to get Py3 support in Swift is very large. Yet there are 
more goals being discussed now, and there's no way I can get Py3 support in 
Swift in Pike. Or Queens. Or probably Rocky either. That's not to say it isn't 
an important goal, but the scope combined with the TC deadline means that my 
governance patch for this goal (the tl;dr version is "not gonna happen") has to 
address this in sufficient detail to stand up to review by TC members who are 
on the PSF! I guess I'll start writing that tomorrow...

While I know that Py3 support is important, I also have to prioritize it 
against other important things. My employer has prioritized certain features 
because that directly impacts our ability to add customers (which directly 
affects my ability to get paid). Other employers in the community are doing the 
same for their employees. In the broader community, as clusters have grown over 
the 

Re: [openstack-dev] [tc][all] Missing answers on Pike release goals

[Sean McGinnis]

> > > 
> > 
> > What if we also require +1 from the "core six" projects on goal proposals?
> > If we at least have buy in from those projects, then we can know that we
> > should be able to get them as a minimum, with other projects more than
> > likely to then follow suit.
> 
> Because we do not want to structure our governance in such a way that
> some projects are more equal than others.
> 
> Everyone in the community has an opportunity to respond to the goals
> through the review process. If we don't trust the TC to take those
> responses into account, then we might as well drop the whole idea of
> community goals.

Yeah, sorry, ignore that. After I sent it I didn't think it was such a
great idea. There really shouldn't be any special emphasis on a subset
of the projects.

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] [tc][all] Missing answers on Pike release goals

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2017-05-23 08:58:08 -0500:
> > >
> > > - Is it that the reporting process is too heavy ? (requiring answers
> > > from projects that are obviously unaffected)
> > 
> > I've thought about this, OSC was unaffected by one of the goals but
> > not the other, so I can't really hide in this bucket.  It really is
> > not that hard to put up a review saying "not me".
> > 
> > > - Is it that people ignore the deadlines and missed the reminders ?
> > > (some unaffected project teams also do not do releases, and therefore
> > > ignore the release countdown emails)
> > 
> > In my case, not so much "ignore" but "put off until tomorrow" where
> > tomorrow turned in to 6 weeks.  I really don't have a hard reason
> > other than simply not prioritizing it because I knew one of the goals
> > was going to take some coordination work
> > 
> 
> +1 - this has been my case, unfortunately.
> 
> A patch submission has the feeling of a major thing that goes through
> a lot of process (at least still in my head). I wonder if we would be
> better off tracking some of this through a wiki page or even an
> etherpad, with just the completion of the goal being something
> submitted to the repo. Then it would be really easy to update at any
> point with notes like "WIP patch put up but still working on it" along
> the way.

The review process for this type of governance patch is pretty light
(they fall under the one-week-no-objections house rule), but I
decided to use a patch instead of the wiki specifically because it
allows for feedback. We've had several cases where teams didn't
provide enough detail or didn't think a goal applied to them when
it did (deploying with WSGI came up at least once).  Wiki changes
can be tracked, but if someone has a question they have to go track
down the author in some other venue to get it answered.

I also didn't want teams to have to keep anything up to date during
the cycle, because I didn't want this to be yet another "status
report". Each goal needs at most 2 patches: one at the start of the
cycle to acknowledge and point to whatever other artifacts are being
used for tracking the work already, and then one at the end of the
cycle to indicate how much of the work was completed and what the
next steps are. We tied the process deadlines to existing deadlines
when we thought teams would already be thinking of these sorts of
topics (most teams have spec deadlines around milestone 1 and then
everyone has the same release date at the end of the cycle).

> 
> > > - Is it that in periods of resource constriction, having release-wide
> > > goals is just too ambitious ? (although anecdotal data shows that most
> > > projects have already completed their goals)
> > 
> > While this may certainly be a possibility, I don't think we should
> > give in to the temptation to blame too much on losing people.  OSC was
> > hit by this too, yet the loss of core and contributors did not affect
> > the goals not getting done, that falls squarely on the PTL in this
> > case.
> > 
> > > - Is it that the goals should be more clearly owned by the community
> > > beyond just the TC? (and therefore the goals should be maintained in a
> > > repository with simpler approval rules and a larger approval group)
> > 
> > I do think that at least the perception of the goals being community
> > things should be increased if we can.  We fall in to the problem of
> > the TC proposing something and getting pushback about projects being
> > forced to do more work, yet we hear so much about how the TC needs to
> > take more leadership in technical direction (see TC vision feedback
> > for the latest round of this).
> > 
> > I'm not sure that the actual repo is the issue, are we having problems
> > getting reviews to approve these?  I don't see this but I'm also not
> > tracking the time to takes for them to get approved.
> > 
> > I believe it is just going to have to be a social thing that we need
> > to continue to push forward.
> > 
> 
> What if we also require +1 from the "core six" projects on goal proposals?
> If we at least have buy in from those projects, then we can know that we
> should be able to get them as a minimum, with other projects more than
> likely to then follow suit.

Because we do not want to structure our governance in such a way that
some projects are more equal than others.

Everyone in the community has an opportunity to respond to the goals
through the review process. If we don't trust the TC to take those
responses into account, then we might as well drop the whole idea of
community goals.

Doug

__
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] [tc][all] Missing answers on Pike release goals

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-05-23 13:57:53 +:
> On 2017-05-23 05:40:05 -0500 (-0500), Dean Troyer wrote:
> > On Tue, May 23, 2017 at 4:59 AM, Thierry Carrez  
> > wrote:
> [...]
> > > - Is it that the reporting process is too heavy ? (requiring answers
> > > from projects that are obviously unaffected)
> > 
> > I've thought about this, OSC was unaffected by one of the goals but
> > not the other, so I can't really hide in this bucket.  It really is
> > not that hard to put up a review saying "not me".
> 
> While not at all an excuse, that was entirely what I chalk my lapse
> up to this time. I had already commented on the governance reviews
> that I had discussed the proposed goals with the rest of the Infra
> team and we'd come to the conclusion that they were either
> inapplicable or already met for us. It just escaped my memory that I
> needed to go back and reassert that again once the goals were
> officially approved.
> 
> Also, I still agree that it's hard to figure out which teams
> actually are affected without asking them, and that's this step of
> the process: confirmation/denial on record.

Right. The goals process is not about anyone telling anyone else what to
do. It's about communicating with each other about a few central
priorities. Part of that communication requires going through some hoops
even when they seem trivial or unnecessary based on what you know,
because the rest of us are not inside your head and don't automatically
have that knowledge. :-)

Doug

> 
> > > - Is it that people ignore the deadlines and missed the reminders ?
> > > (some unaffected project teams also do not do releases, and therefore
> > > ignore the release countdown emails)
> [...]
> 
> Not so much ignore but because so little of the content is directly
> applicable to Infra I read them in the context of things we should
> be on the lookout for other teams working on, so I'm not in the
> mindset of expecting to actually find an action item in there. This
> is just a matter of retraining myself on what to look for in those
> announcements in the future.

__
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] [tc][all] Missing answers on Pike release goals

[Sean McGinnis]

> >
> > - Is it that the reporting process is too heavy ? (requiring answers
> > from projects that are obviously unaffected)
> 
> I've thought about this, OSC was unaffected by one of the goals but
> not the other, so I can't really hide in this bucket.  It really is
> not that hard to put up a review saying "not me".
> 
> > - Is it that people ignore the deadlines and missed the reminders ?
> > (some unaffected project teams also do not do releases, and therefore
> > ignore the release countdown emails)
> 
> In my case, not so much "ignore" but "put off until tomorrow" where
> tomorrow turned in to 6 weeks.  I really don't have a hard reason
> other than simply not prioritizing it because I knew one of the goals
> was going to take some coordination work
> 

+1 - this has been my case, unfortunately.

A patch submission has the feeling of a major thing that goes through
a lot of process (at least still in my head). I wonder if we would be
better off tracking some of this through a wiki page or even an
etherpad, with just the completion of the goal being something
submitted to the repo. Then it would be really easy to update at any
point with notes like "WIP patch put up but still working on it" along
the way.

> > - Is it that in periods of resource constriction, having release-wide
> > goals is just too ambitious ? (although anecdotal data shows that most
> > projects have already completed their goals)
> 
> While this may certainly be a possibility, I don't think we should
> give in to the temptation to blame too much on losing people.  OSC was
> hit by this too, yet the loss of core and contributors did not affect
> the goals not getting done, that falls squarely on the PTL in this
> case.
> 
> > - Is it that the goals should be more clearly owned by the community
> > beyond just the TC? (and therefore the goals should be maintained in a
> > repository with simpler approval rules and a larger approval group)
> 
> I do think that at least the perception of the goals being community
> things should be increased if we can.  We fall in to the problem of
> the TC proposing something and getting pushback about projects being
> forced to do more work, yet we hear so much about how the TC needs to
> take more leadership in technical direction (see TC vision feedback
> for the latest round of this).
> 
> I'm not sure that the actual repo is the issue, are we having problems
> getting reviews to approve these?  I don't see this but I'm also not
> tracking the time to takes for them to get approved.
> 
> I believe it is just going to have to be a social thing that we need
> to continue to push forward.
> 

What if we also require +1 from the "core six" projects on goal proposals?
If we at least have buy in from those projects, then we can know that we
should be able to get them as a minimum, with other projects more than
likely to then follow suit.

__
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] [tc][all] Missing answers on Pike release goals

[Jeremy Stanley]

On 2017-05-23 05:40:05 -0500 (-0500), Dean Troyer wrote:
> On Tue, May 23, 2017 at 4:59 AM, Thierry Carrez  wrote:
[...]
> > - Is it that the reporting process is too heavy ? (requiring answers
> > from projects that are obviously unaffected)
> 
> I've thought about this, OSC was unaffected by one of the goals but
> not the other, so I can't really hide in this bucket.  It really is
> not that hard to put up a review saying "not me".

While not at all an excuse, that was entirely what I chalk my lapse
up to this time. I had already commented on the governance reviews
that I had discussed the proposed goals with the rest of the Infra
team and we'd come to the conclusion that they were either
inapplicable or already met for us. It just escaped my memory that I
needed to go back and reassert that again once the goals were
officially approved.

Also, I still agree that it's hard to figure out which teams
actually are affected without asking them, and that's this step of
the process: confirmation/denial on record.

> > - Is it that people ignore the deadlines and missed the reminders ?
> > (some unaffected project teams also do not do releases, and therefore
> > ignore the release countdown emails)
[...]

Not so much ignore but because so little of the content is directly
applicable to Infra I read them in the context of things we should
be on the lookout for other teams working on, so I'm not in the
mindset of expecting to actually find an action item in there. This
is just a matter of retraining myself on what to look for in those
announcements in the future.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [tc][all] Missing answers on Pike release goals

[Dmitry Tantsur]

Not an offender, apparently, but lemme throw some less optimistic views here.

On 05/23/2017 12:40 PM, Dean Troyer wrote:

OK, I'll bite, being one of the until-last-week offenders...

On Tue, May 23, 2017 at 4:59 AM, Thierry Carrez  wrote:

As part of release management we remind projects of the release cycle
deadlines, including the ones regarding the release goals process.

According to [1], "each PTL is responsible for adding their planning
artifact links to the goal document before the first milestone
deadline", and "if the goal does not apply to a project or the project
has already met the goal, the PTL should explain why that is the case,
instead of linking to planning artifacts".

However, for Pike goals we are 6 weeks past the pike-1 milestone, and we
still have about half the project teams that haven't provided answers
(despite two reminders posted in the release countdown emails). Such a
large share goes beyond the usual occasional misses, and points to a
more systemic issue, that we might want to address before the Queens
campaign starts.

A few questions to bootstrap the discussion:

- Is it that the reporting process is too heavy ? (requiring answers
from projects that are obviously unaffected)


I feel like the answer is somewhere here. Maybe filling in a field in a 
spreadsheet could be easier for folks?




I've thought about this, OSC was unaffected by one of the goals but
not the other, so I can't really hide in this bucket.  It really is
not that hard to put up a review saying "not me".


- Is it that people ignore the deadlines and missed the reminders ?
(some unaffected project teams also do not do releases, and therefore
ignore the release countdown emails)


In my case, not so much "ignore" but "put off until tomorrow" where
tomorrow turned in to 6 weeks.  I really don't have a hard reason
other than simply not prioritizing it because I knew one of the goals
was going to take some coordination work


- Is it that in periods of resource constriction, having release-wide
goals is just too ambitious ? (although anecdotal data shows that most
projects have already completed their goals)


While this may certainly be a possibility, I don't think we should
give in to the temptation to blame too much on losing people.  OSC was
hit by this too, yet the loss of core and contributors did not affect
the goals not getting done, that falls squarely on the PTL in this
case.


How do you define "too much" here? We've lost all people who committed to work 
on one of the goals. Does it count?


Also, I'm sorry, but OSC is a bad example here. The WSGI goal did not apply to 
you at all, and I suspect you were already more or less (or fully) Python 3 
compatible.





- Is it that the goals should be more clearly owned by the community
beyond just the TC? (and therefore the goals should be maintained in a
repository with simpler approval rules and a larger approval group)


I do think that at least the perception of the goals being community
things should be increased if we can.  We fall in to the problem of
the TC proposing something and getting pushback about projects being
forced to do more work, yet we hear so much about how the TC needs to
take more leadership in technical direction (see TC vision feedback
for the latest round of this).


I won't be surprised to learn that these are different people :) Or at least 
that some people do not understand "provide leadership" as "ask to do more work" 
(not meaning anything negative here, especially since I believe that the goals 
we have are important indeed).


But I do agree that there don't seem to be enough buy-in from the community in 
the goals. Probably the reason is well-known: companies backing people do pay 
for that, so they have to prove that working on the goals benefits their employers.




I'm not sure that the actual repo is the issue, are we having problems
getting reviews to approve these?  I don't see this but I'm also not
tracking the time to takes for them to get approved.

I believe it is just going to have to be a social thing that we need
to continue to push forward.

dt




__
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] [tc][all] Missing answers on Pike release goals

[Dean Troyer]

OK, I'll bite, being one of the until-last-week offenders...

On Tue, May 23, 2017 at 4:59 AM, Thierry Carrez  wrote:
> As part of release management we remind projects of the release cycle
> deadlines, including the ones regarding the release goals process.
>
> According to [1], "each PTL is responsible for adding their planning
> artifact links to the goal document before the first milestone
> deadline", and "if the goal does not apply to a project or the project
> has already met the goal, the PTL should explain why that is the case,
> instead of linking to planning artifacts".
>
> However, for Pike goals we are 6 weeks past the pike-1 milestone, and we
> still have about half the project teams that haven't provided answers
> (despite two reminders posted in the release countdown emails). Such a
> large share goes beyond the usual occasional misses, and points to a
> more systemic issue, that we might want to address before the Queens
> campaign starts.
>
> A few questions to bootstrap the discussion:
>
> - Is it that the reporting process is too heavy ? (requiring answers
> from projects that are obviously unaffected)

I've thought about this, OSC was unaffected by one of the goals but
not the other, so I can't really hide in this bucket.  It really is
not that hard to put up a review saying "not me".

> - Is it that people ignore the deadlines and missed the reminders ?
> (some unaffected project teams also do not do releases, and therefore
> ignore the release countdown emails)

In my case, not so much "ignore" but "put off until tomorrow" where
tomorrow turned in to 6 weeks.  I really don't have a hard reason
other than simply not prioritizing it because I knew one of the goals
was going to take some coordination work

> - Is it that in periods of resource constriction, having release-wide
> goals is just too ambitious ? (although anecdotal data shows that most
> projects have already completed their goals)

While this may certainly be a possibility, I don't think we should
give in to the temptation to blame too much on losing people.  OSC was
hit by this too, yet the loss of core and contributors did not affect
the goals not getting done, that falls squarely on the PTL in this
case.

> - Is it that the goals should be more clearly owned by the community
> beyond just the TC? (and therefore the goals should be maintained in a
> repository with simpler approval rules and a larger approval group)

I do think that at least the perception of the goals being community
things should be increased if we can.  We fall in to the problem of
the TC proposing something and getting pushback about projects being
forced to do more work, yet we hear so much about how the TC needs to
take more leadership in technical direction (see TC vision feedback
for the latest round of this).

I'm not sure that the actual repo is the issue, are we having problems
getting reviews to approve these?  I don't see this but I'm also not
tracking the time to takes for them to get approved.

I believe it is just going to have to be a social thing that we need
to continue to push forward.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][all] Missing answers on Pike release goals

[Thierry Carrez]

Hi!

As part of release management we remind projects of the release cycle
deadlines, including the ones regarding the release goals process.

According to [1], "each PTL is responsible for adding their planning
artifact links to the goal document before the first milestone
deadline", and "if the goal does not apply to a project or the project
has already met the goal, the PTL should explain why that is the case,
instead of linking to planning artifacts".

However, for Pike goals we are 6 weeks past the pike-1 milestone, and we
still have about half the project teams that haven't provided answers
(despite two reminders posted in the release countdown emails). Such a
large share goes beyond the usual occasional misses, and points to a
more systemic issue, that we might want to address before the Queens
campaign starts.

A few questions to bootstrap the discussion:

- Is it that the reporting process is too heavy ? (requiring answers
from projects that are obviously unaffected)

- Is it that people ignore the deadlines and missed the reminders ?
(some unaffected project teams also do not do releases, and therefore
ignore the release countdown emails)

- Is it that in periods of resource constriction, having release-wide
goals is just too ambitious ? (although anecdotal data shows that most
projects have already completed their goals)

- Is it that the goals should be more clearly owned by the community
beyond just the TC? (and therefore the goals should be maintained in a
repository with simpler approval rules and a larger approval group)

- Anything else we should/could change ?

[1] https://governance.openstack.org/tc/goals/

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