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

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

Reply via email to