Haïkel,
thank you for your ticket - I was about to report my own ticket to FESCo/Board soon after talking to a few community members - as it's not only about FPC being bottleneck but also Fedora with introduction of products and working groups, changed the way how it's organized. We're moving to offload decision making from bodies to groups that actually do the job, where the expertise is, as you pointed out.

== Proposal ==
Split FPC competencies to the specific groups withing Fedora Project, namely working groups and FESCo. Optionally FPC can stay as FESCo subproject to deal with potential conflicting guidelines, same as FESCo does for development and to coordinate on guidelines effort that spans through several different areas, appointed by WGs/FESCo.

Possible split:
Base WG for naming, licensing, guidelines that apply to everything in Base (and packages that do not fit any of following area specific groups). Base WG could take full responsibilities if FPC will be dismissed. This will give Base opportunity to steer Base OS development and prepare common ground for highlevel projects on top of it.
Workstation WG for desktop packaging, GUI frameworks, GUI applications
Env & Stacks WG for languages and other SW stacks (LAMP), Docker
SIGs to propose guidelines to relevant WGs/Base WG/FPC/FESCo

Optionally:
* Fedora Legal and Board to take care of licensing

Documentation team could take responsibility for technical writing of guidelines, I know pmkovar is interested in this role.

== Background Analysis ==
WGs have enough responsibility to do changes in products, but do not have power to change guidelines
Guidelines should be prepared and approved by experts in particular area
FPC is known to be overloaded, this restructuralization should help to deliver things quicker and thus be able to compete quickly enough (remember: "fail fast, succeed faster")
We have process of System Wide Changes that should serve as breaking mechanism for more dramatic changes in packaging, as Change Wrangler, I'm more than happy to extend the process to be more guidelines friendly. Btw. I think it should be used even now.
minor statistics for the last half a year period: FPC touched approx. 65 issues, 26 would probably be part of Env&Stacks responsibility, 39 are more general (often systemd - related) provided by hhorak.
There is always possibility to return back if a new system proves to not work
* Of course there could be overlaps in competencies, same as for products/working groups but for them, it proved to work and led to better communication within the Fedora Project

I also like the fast track process you proposed and other parts of your proposal actually complements this proposal. So this is definitely not a couter-proposal!

The last thought - I'd like to say big thanks to all FPC members all the times, as Fedora now has very one of the best guidelines in open source world! Many folks, even from upstreams, contacted me to say how great we are (and sometimes even we inside community don't see it).

Getting away from a specific solution and toward the overall problem space: I think it's important to realize that Fedora.next as conceived by sgallagher and mattdm has a natural inclination toward different packaging approaches. Currently we have only one: approved or verboten. That doesn't seem scalable with the ring-based model that Matthew talked about at recent Flock and elsewhere. So I think this is a problem worth solving, and shouldn't be dismissed out of hand as too revolutionary or disruptive.

I think one of our greatest assets is our strong and well reasoned packaging guidelines. I think we all want to keep quality and consistency high in our main package collection.

Historically the reason the FPC was setup as it's own separate comittee was that for things like packaging guidelines you want lots of people who know the history of things and are consistent over time, not changing all the time due to elections or the like.

The first thing I think we should do here is talk with the FPC (perhaps we could invite them to attend the next FESCo meeting? or hold a special meeting?) and identify the bottlenecks and see what they are willing to do to break down some of those.

I don't think we should change guidelines or quality on our main collection of packages, but there are things like the Stacks&Env working groups playground repo. I think different guidelines there are fine as long as expectations are set clearly.

I think one of the biggest problems is that people have an expectation that they want guidelines for something and can just ask FPC to investigate and draft and approve things, where the real situation is that FPC expects new guidelines drafts to have champions that do the investiation and propose drafts. (ie, who is doing the work). Not sure in the case of GO, but for SCLs there didn't seem to be a champion from the SCL side (I could be wrong, but thats the impression I got).

Anyhow, I think we can improve things here, and should talk to FPC about ways to do that and measure if things are less bottlenecked.

While I appreciate that the FPC may not be ideal, I really think going directly to FESCo without discussing your issues on the packaging mailing list or notifying current FPC members about this ticket is not excellent behaviour.

Replying to [comment:7 pfrields]:

Getting away from a specific solution and toward the overall problem space: I think it's important to realize that Fedora.next as conceived by sgallagher and mattdm has a natural inclination toward different packaging approaches. Currently we have only one: approved or verboten. That doesn't seem scalable with the ring-based model that Matthew talked about at recent Flock and elsewhere. So I think this is a problem worth solving, and shouldn't be dismissed out of hand as too revolutionary or disruptive.

Good point and I think the proposal above actually matches the initial Fedora.next proposal, where Base is tied with strict policies to make building blocks high quality and then loose policies for top layers govern by relevant WGs.

Replying to [comment:9 rathann]:

While I appreciate that the FPC may not be ideal, I really think going directly to FESCo without discussing your issues on the packaging mailing list or notifying current FPC members about this ticket is not excellent behaviour.

Well, my proposal above is really meant to start discussion and to be honest, I did not plan to go out with it as early without talking to FPC/WGs etc. but I was pointed to this ticket and seemed to be a good place where to start and engage more folks.

If FPC will be invited to the FESCo meeting, I definitely will join but also I'd like to see input from WGs first. Especially with the relevance to what Paul sent here. Do no try to fix FPC/old processes FPC was designed for but do the move Fedora.Next direction.

During our weekly Base WG meeting jreznik brought up this ticket as an agenda point.

Depending on whether Fedora will go head with jreznik's proposal (or a similar version of it) the Base WG would like to official extend and invitation to the FPC members to join the Base WG as representatives.

This would allow us to keep the Base packaging guidelines fairly strict and we would welcome the expertise and knowhow the FPC member would bring to ensuring that. Other WGs could then of course leverage from that and either adapt their guidelines, use a subset of the strict ones or coordinate and collaborate with the Base WG on adding, modifying or removing guidelines.

Replying to [comment:16 pknirsch]:

Depending on whether Fedora will go head with jreznik's proposal (or a similar version of it) the Base WG would like to official extend and invitation to the FPC members to join the Base WG as representatives.
[...snip...]

Phil, thanks for this input. I think this goes right to Kevin's point that we should not be loosening guidelines in the core of packages that are the basis for the platform. At the same time we need to recognize that the current model of having a historical base of knowledge contained in a few people doesn't scale well. I think there are a combination of issues to consider:

• We need to make possible the Fedora.next "ring" model, which in concept foresees more flexibility and variance moving outward from the core. I don't see a way for that to avoid some revision to our packaging strategy.
• We need to ensure rationale for packaging decisions appears consistently in published guidelines. That would allow community members with packaging interest to more easily understand why decisions were made previously and avoid the "eaten by raptors" problem of institutional knowledge.

Adding meeting keyword as this was missed at our last few meetings.

I've also reached out to FPC in their last meeting and there was some discussion. They are trying to fill empty seats and hope that doing so will get them quorum more often so they can move forward on things. Beyond that they have no great interest in writing the guidelines for things that are not the main fedora collection itself, so things like playground repo, etc are probibly outside their scope.

Replying to [ticket:1346 hguemar]:

= implementation recommendation =

I advise that after F21 release, FeSCo audit FPC.
Few suggestions:
Bundled library exceptions should follow a fast-track processus modelled on provenpackager/sponsor processus (+3 and no -1 => granted after 1 or 2 weeks, else should be examined or flat out refused)
Improve the packaging guidelines workflow so that FPC doesn't have to waste time on incomplete drafts. There should be a timeout on all guidelines review, and escalation to FeSCo when it is problematic (ie: SCL)
I would rather expect FPC to be able to do these process changes itself.

• Improve recruitment model and regular membership renewal.
  Worth considering.

• Having a FeSCo member serving as a liaison (or chairman) to coordinate between FeSCo and FPC.
  We haven’t had that much need of coordination. If you mean “oversight”, say so ☺

About packaging guidelines, some suggested to provide different level of repository:
trusted: packages following packaging guidelines, actively maintained
staging: packages actively maintained, but with relaxed packaging guidelines
* contrib: use at your own risk (unmaintained, FTBFS are regularly removed)

Something like that is sadly likely to be the default because it, in the grand scheme, easiest to do. However I find it rather unsatisfactory: we are giving up consistency and integration (= the very purpose of a distribution) and getting very little in return (e.g. considering the golang example that hasn’t actually been blocked).

Replying to [comment:4 jreznik]:

== Proposal ==
Split FPC competencies to the specific groups withing Fedora Project, namely working groups and FESCo. Optionally FPC can stay as FESCo subproject to deal with potential conflicting guidelines, same as FESCo does for development and to coordinate on guidelines effort that spans through several different areas, appointed by WGs/FESCo.

I don’t see this as a good match; for a lack of better terminology, the Products are “applications” on top of the common “operating system”, and the overlap in packaging, compared to the WG-specific areas, is almost overwhelming.

For example, we ''should'' be solving the parallel-installability of Python[23], Ruby{1.8,1.9}, Rails[234], and GTK[23], and packaging of applications that depend on these things, consistently between all of them. The really WG-specific packaging areas are, AFAICT, pretty much limited to desktop-specific mechanisms for application and mime type and icon registration (which all have fairly strict upstream standards), and the like.

• Base WG for naming, licensing, guidelines that apply to everything in Base (and packages that do not fit any of following area specific groups).
  The Base package set is far too small; or alternatively, “and packages that do not fit …” is far too large.

• SIGs to propose guidelines to relevant WGs/Base WG/FPC/FESCo
  Well which one? There isn’t really a good owner for e.g. Erlang or R guidelines in this model.

• We have process of System Wide Changes that should serve as breaking mechanism for more dramatic changes in packaging, as Change Wrangler, I'm more than happy to extend the process to be more guidelines friendly. Btw. I think it should be used even now.

Yes. Changing guidelines and updating packages should go hand in hand.

Replying to [comment:7 pfrields]:

Getting away from a specific solution and toward the overall problem space: I think it's important to realize that Fedora.next as conceived by sgallagher and mattdm has a natural inclination toward different packaging approaches.

I don’t quite see that. If anything, there is a strong inclination to ''hide'' packaging from the end product (and instead shipping Docker/Atomic/Cloud images, which are a result of packaging ''and'' installation).

The vague consensus about being more open to supporting use language-native packaging tools (e,g. pip/gem) is pretty much ''irrelevant'' to the question of how should the same upstream modules be packaged to RPMs ''for those that we need to package''.

As for a way forward: Repeating myself one more time this week.

I will no longer tolerate/support any packaging guideline changes which, without expanding Fedora to an entirely new ecosystem/use case, add manual packaging or package review work. We are software developers, and the way we solve problems in our area and in this century is by writing software.

We have always talked about more packaging automation but it never “just happened”. If this ticket ended up reinvigorating the FPC as it exists today, it would likely not “just happen” in the future either.

And if we ended up splitting the FPC responsibilities to the WGs, moving to more automation would become even harder in the future.

I think we should be thinking hard about what would it take to achieve more automation, and ''only then'' discuss governance/authority/division of responsibilities.

Last weeks meeting we decided:

AGREED: jreznik to open discussion on devel