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