#358 Proposal: abolish FESCo ratification requirement for FPC guidelines
Closed None Opened 14 years ago by kkofler.

= Proposal topic =

This proposal is to abolish the FESCo ratification requirement for packaging guidelines passed by the FPC, fully delegating the authority to the FPC.

= Overview =

Currently, any changes to the packaging guidelines have to be not only passed by FPC, but also formally ratified by FESCo (usually a pure formality). Instead, I propose for the act of the guideline being passed by FPC to automatically constitute ratification. In case of a concrete complaint about a guideline, the issue can of course be escalated to FESCo which may vote to overturn, suspend or amend the guideline by the usual majority vote. The only change would be for guidelines to be considered passed by default so we don't waste time with pure formailities.

= Problem space =

  • Currently, we regularly have to spend meeting time discussing packaging guideline approvals. In practically all cases, the decision was to approve the guideline, and often there was not a single packager publicly objecting to the change. Thus we are wasting our valuable time with a pure bureaucratic formality. In those cases where there are objections to a particular guideline, any maintainer objecting to the guideline could ask for the issue to be considered in the next FESCo meeting.
  • The FPC is a committee of people we trust who have been delegated some important powers by FESCo. Why should that trust not extend to ratifying guideline changes, which is straight in FPC's domain of expertise?
  • The ratification process delays approval of guideline changes for no good reason (given that it is a pure formality).
  • The ratification process complicates the issue of documenting the changes, as the relevant wiki pages are under FPC's control, so any changes have to go through FPC for initial approval, then through FESCo for ratification and then back to FPC for documentation. In several cases in the past, the guideline was stuck somewhere beween ratification and documentation, FPC has recently published a huge set of ratified, but previously undocumented guideline changes. Skipping the middle step would save a roundtrip and ensure changes would get documented in a more timely manner.
  • Our meetings are always very long, to the point where we felt a need to limit discussions to 15 minutes/item by default. Not having to worry about pure formalities would leave us more time to discuss more pressing issues.
  • The proposed change in process would also encourage maintainers to concretely and explicitly voice any objections to packaging guideline changes to FESCo rather than silently hoping we'll veto them (which in practice almost never happens), therefore providing a boost to community involvement.

= Solution Overview =

  • Delegate the authority to formally ratify packaging guidelines to FPC, recommending that ratification should become an automatic and immediate consequence of the FPC passing the guideline under its current process.
  • Announce this process change on fedora-devel-announce.
  • In the announcement, make it clear that the possibility of escalating issues to FESCo exists as always and that maintainers objecting to any announced packaging guideline change should file an objection in FESCo's Trac.

= Active Ingredients =

FESCo, FPC

= Owners =

kkofler


FWIW, a proposal similar to this is in the fesco archives. It seemed to be generally approved of. Then fesco was distracted by other things and it didn't get implemented.

Replying to [comment:2 toshio]:

FWIW, a proposal similar to this is in the fesco archives. It seemed to be generally approved of. Then fesco was distracted by other things and it didn't get implemented.

If I remember correctly, we talked about doing this in the past, but the FPC didn't want to drop the FESCo ratification requirement. Might want to check with Tibbs or Spot to verify that since I'm going from memory, and could be wrong. ;-)

Here's a little backstory to explain:

One of the earliest actions of the Fedora Board was to give me permission to write the packaging guidelines for Fedora. Once the initial guidelines were setup, I created the Fedora Packaging Committee structure to not only check that power, but also to provide more eyes upon the proposed changes. However, given that the FPC could still just make changes at will, I wanted to impose an additional layer of sanity check upon the decisions of the FPC. It seemed appropriate for FESCo to have some oversight in the changing of the Fedora Packaging Guidelines.

In the past, this has been beneficial, as FESCo has identified areas of concern and disagreement. I would like to continue operating in this fashion, as I see that it is generally productive. The fact that we are usually in regular agreement is not a negative statement, and it should not take up too much of FESCo's time. We send in tickets with links to the pending guideline changes in advance of the FESCo meeting, so FESCo members should be able to review them beforehand.

Also, FESCo is not the reason for the delay in writing up guidelines. That delay is solely my fault.

Well, FPC responds to FESCo anyway, in that any actual concrete issues with the guidelines can be escalated to us anyway, I don't see why we need to rubberstamp each and every guideline, it's just a waste of our time, and IMHO also qualifies as Useless Bureaucracy (TM). ;-)

You folks did great work so far, I think this is strong evidence that you can handle this on your own.

As a general idea, I think it's not useful to concentrate all the power into 1 or 2 (with the Board) committees and to have that/those committee(s)'(s) meetings take hours. It would be much more efficient to spread leadership to technical committees such as FPC and to SIGs, each focusing on their own domain of expertise. (For example, I'm trying to think of how a decentralized feature process could look like. I could imagine the Feature Wrangler assigning features to a responsible SIG (or technical committee, for example features about changes to RPM could be assigned to FPC), who would decide on their own on approval/rejection, with FESCo only being the fallback if no responsible SIG can be found. But I'm only going to come up with a formal proposal if there's any interest.)

PS: I believe meetings should be used to discuss important things which really need discussion. Anything that looks like a routine item smells like something inappropriate as a meeting item, and some more efficient (ideally less centralized) process should be used.

Replying to [comment:5 kkofler]:

I could imagine the Feature Wrangler assigning features to a responsible SIG (or technical committee, for example features about changes to RPM could be assigned to FPC), who would decide on their own on approval/rejection, with FESCo only being the fallback if no responsible SIG can be found. But I'm only going to come up with a formal proposal if there's any interest.)

Not a new idea. FESCo has discussed doing that about a year ago or so. I'd have to go back and look at the meeting minutes to remember why it was decided not to go that route.

Replying to [comment:4 spot]:
(Quoting a little out of order):

Also, FESCo is not the reason for the delay in writing up guidelines. That delay is solely my fault.

It's true that delays in writing up the guidelines fall on FPC but there is also a delay between FPC approval and fesco ratification that has hit us in the past. Maybe because I'm often the one drafting Guidelines/Guideline Proposals that come in from package maintainers I see more of it but a common problem is: draft is written because package maintainers have an issue that's blocked on the guidelines being updated; FPC meeting occurs and FPC approves; wait another week just to make sure FESCo will ratify; finally package maintainers can start using the new Guideline with confidence that it won't be changed.

Also, I think Kevin is correct that roundtripping from FPC to FESCo and back to FPC makes a difference. FPC used to have the members driving the draft do the writeup but with FPC ratification, things started falling through the cracks because people lost track of things they were supposed to write up week to week. If they could do it right after the meeting it would make documenting happen faster.

In the past, this has been beneficial, as FESCo has identified areas of concern and disagreement. I would like to continue operating in this fashion, as I see that it is generally productive. The fact that we are usually in regular agreement is not a negative statement, and it should not take up too much of FESCo's time. We send in tickets with links to the pending guideline changes in advance of the FESCo meeting, so FESCo members should be able to review them beforehand.

The precise method of ratification doesn't need to stay the same, though. Here's my summary of the workflow currently, the proposal here, and the previous proposal:
* Currently: FPC approves; ~ 1 week later fesco meeting occurs and members vote either on the whole guidelines update or the pieces thereof; goes back to FPC to writeup as Guideline instead of draft but the Guidelines are in effect at this time, whether taken out of draft form or not
* This proposal: FPC approves; FPC announces and writes up -- Guideline is in effect whether taken out of draft form or not; at some point maintainers complain and put in a ticket to fesco; fesco decides the Guideline needs to be rewritten or dropped and hands complaints back to FPC -- at this point, Guideline may be suspended or left in effect until new one is written at fesco's discretion; FPC tries to resolve problems in Guideline. -- note that the maintainer complaint => FPC review is already in place as normal part of conflict resolution between FPC and maintainers.
* Previous proposal: FPC approves; ~ 1 week later fesco has a meeting; simply ask any objections? If no objections, no vote, discussion, etc, merely move on to the next agenda item. Guideline is considered in effect at this point; Goes back to FPC for writeup/announce

Things I like about either proposal to change: Make the FESCo meeting go faster by eliminating a vote + count step.

Things I like about Kevin's proposal: keeps the FPC tasks grouped together so they should theoretically get done right after an FPC meeting. Elminates one of the wait periods where maintainers can't rely upon the new Guidelines even though, in practice, the new Guidelines are almost always going to be ratified. Merges the ratification process with the existing -- what to do if you strongly disagree with Guidelines mandated by FPC process which simplifies what a maintainer needs to know. Allows relevant FPC members to be at a fesco meeting where a specific guideline is discussed; currently FPC doesn't know if a Guideline will be questioned so the relevant people aren't there. (I've had to try to explain rationale for guidelines to fesco that I've voted against at FPC on several occasions which is highly undesirable)

Things I don't like: FESCo is currently supposed to actively have read the changes approved by FPC in order to vote to ratify (but this doesn't always happen in practice... see the comments for ratifying the python3 guidelines). Like spot, I think there's value in having another set of eyes on this (although I'm not sure how much -- from a maintainers perspective we're taking too much time already to get a Guideline fully approved so sending Guidelines back to FPC without figuring out how to reduce the time in other places is detrimental). A mitigating factor is IIRC anytime a guideline has been sent back to FPC it's been because problems were raised on the mailing lists and fesco has picked out what it considered the relevant arguments to be fixed from those discussions. That seems to fit with Kevin's proposal to escalate issues with the Guidelines rather than to require ratification of the changes.

Also note that FPC has been given the ability to make "minor" changes without going through the ratification process, where FPC decides what "minor" is. We do things like fix typos and will on rare occasions change things that are obviously wrong because of other changes elsewhere in the distro without going through FESCo. FESCo could conceivably raise the limit from "minor" to "non-controversial" or somesuch.

I'd still want to get FESCo approval for things where we're proposing to force changes to many packages or adding work for packagers, but I don't see a reason to take FESCo's time to add a guideline such as "RPM adds a %clean section automatically; there is no need to have it in your .spec for F-13 and later" or some initial guidelines for, say, lua packages which were developed along with the main lua packagers in the distro.

This proposal was not approved.

We will try and have FPC file tickets for each guideline change and vote in ticket. This way approval can be out of band and not take up meeting time.

Login to comment on this ticket.

Metadata