Open Stack

On 21/01/16 11:55 +0100, Thierry Carrez wrote:
>Flavio Percoco wrote:
>>[...]
>>So, the above sounds quite vague, still but that's the idea. This email
>>is not a formal proposal but a starting point to move this conversation forward.
>>Is this something other teams would be interested in? Is this something some
>>teams would be entirely against? Why?
>>
>>From a governance perspective, projects are already empowered to do this and
>>they don't (and won't) need to be granted permission to have stabilization
>>cycles. However, the TC could work on formalizing this process so that teams
>>have a reference to follow when they want to have one.
>
>I think "stabilization cycles" will come in all shapes and form, so 
>it's hard to standardize them (and provides little value). They will 
>mean different things and happen at different times for every project, 
>and that is fine.
>
>As you said, projects can already decide to restrict feature 
>development in a given cycle, so this is nothing new. We only need to 
>communicate more aggressively that it is perfectly fine (and even 
>encouraged) to define the amount of feature work that is acceptable 
>for a project for a given cycle.

++

Precisely my point. If there's a way, from a governance perspective, to help
communicate and encourage folks to do this, I wan't to take it. It was mentioned
that some teams didn't know this was possible others that felt it was going to
be really hard w/o any support from the governance team, hence this email and
effort.

>>For example, we would
>>have to formalize how projects announce they want to have a
>>stabilization cycle
>>(I believe it should be done before the mid-term of the ongoing cycle).
>
>While I understand the value of announcing this "cycle feature 
>strategy" beforehand, this comes slightly at odds with our PTL 
>rotation every cycle: one PTL would announce a more stable cycle and 
>then the next one would have to execute on a choice that may not be 
>his.
>
>I actually wouldn't mind if that feature strategy decision was part of 
>the PTL election platform -- it sounds like that would trigger 
>interesting discussions.


I wouldn't mind it either. However, I'd like us to stop having such a hard
separation between current PTL's plans and future PTL's. As a community, I'd
like us to work harder on building new leaders and a better community. I'd like
current PTLs to find in the community who would like to run for the PTL role
(regardless of the current PTL planning re-election) and work with them towards
having a better long term plan for the project. We should really stop thinking
that our responsibilities as PTLs start when the cycle begins and end when our
term ends. At least, I don't believe that.

That is to say, I'd like these plans to be discussed with the community in
advance because I believe the project will benefit from proper communication.

If I run for PTL and win because I proposed a stabilization cycle, I might end
up with a good plan and no ppl due to their tasks being re-scheduled because
their management doesn't want them to spend so much time "just fixing bugs".

>>Thoughts? Feedback?
>
>Just an additional thought. It is not entirely impossible that due to 
>events organization we'll accidentally have a shorter cycle (say, 4 
>months instead of 6) in the future here and there. I could totally see 
>projects take advantage of such a short cycle to place a 
>"stabilization cycle" or another limited-feature-addition period.

++

As I mentioned in a previous reply, I think projects could also have a
stabilization milestone rather than a full cycle.

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160121/2f36bce7/attachment.pgp>