#1134 Strategy for Self Contained change to System Wide change escalation
Closed None Opened 10 years ago by jreznik.

During Fedora 19 cycle, we did not have two categories of features and thus FESCo just picked up features that needed coverage (FESCo members wanted to cover it, info missing etc) on the meeting and approved it explicitly.

Now we have these two categories - the idea behind was - there's no need for such detailed Change page for Self Contained changes as for System Wide ones, to make it easier for developers to fill it in and also the list of Self Contained changes should be approved by FESCo in a batch (and off load it from FESCo hands).

There are cases, where the discussion on mailing list leads to consensus that the proposed change should be declared as System Wide. For such cases, there's an escalation process in the policy. But we have not yet defined the exact steps how to escalate it. Can anyone escalate it in the mailing list? Or should it be FESCo on the meeting while approving the list of Self Contained changes?

For the second option:
1. change is announced on devel-announce as Self Contained one
2. under discussion it turns out that change should be probably System Wide
3. it's submitted to FESCo approval on the list of Self Contained changes
4. the change could be taken off from the list by FESCo (it does not have to be) based on feedback, the rest is approved implicitly

So far, it's similar to F19 with one difference - the page itself has to be updated with more details. That's the reason why Self Contained and System Wide pages use the same template - to make it super easy to fill in full System Wide page details.

  1. Change owner is asked to provide more details based on the mailing list/FESCo complaints
  2. change is re-announced as System Wide - I'd say it could be for less than 7 days, so it hits the next FESCo meeting (update could take some time but discussion already happened)
  3. FESCo discuss it as System Wide change -> standard process

I'd expect that in most cases the escalation decision would not be controversial; in that case the Change should be escalated/expanded already based on the mailing list review and never appear on FESCo meeting agenda in the "self-contained" version.

Only if FESCo needed to vote on escalating the Change would something like the above process happen. In such cases I agree generally we should usually be able to discuss it at the next meeting, so the re-announcement can be a little less than 7 days - while in some cases the added information will require sufficient time for fedora-devel. I think it makes most sense to default to "next meeting"; FESCo has in any case the discretion to defer the decision if it feels that more discussion is needed.

Replying to [comment:1 mitr]:

I'd expect that in most cases the escalation decision would not be controversial; in that case the Change should be escalated/expanded already based on the mailing list review and never appear on FESCo meeting agenda in the "self-contained" version.

Looking on current Self Contained changes under discussion, the border between these two categories could be pretty low and it does not have be very clear from the discussion itself. And that lead to this ticket - who should decide it? And based on what (metrics)?

info APPROVED: (+1:8, 0:0, -1:0) any fesco member or the wrangler can decide to escalate a self-contained feature to systemwide by noting that they're escalating it as part of the mailing list discussion.

Login to comment on this ticket.

Metadata