= phenomenon = We already have Working Groups responsible for each of the Fedora Products. The WGs have power to make decisions with regard to the product they are responsible for. When Changes (mainly system-wide ones) are proposed for next Fedora, the Change is formally approved only by FESCo and there is no requirement for formal approval from each WG. Thus the FESCo's decision does not have much of a meaning if the WGs decide they don't want the change in their product. In some cases the issues were discovered late in the release process forcing the changes to be postponed to next Fedora release. This seems to be mostly a communication issue.
= background analysis = The wiki page http://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes doesn't mention approval from WGs explicitly. I know that everyone is expected to discuss the change with affected WGs, however this may not really happen to the necessary extent.
= implementation recommendation = I think the Changes Process (at least for system-wide changes) should be updated to reflect existence of WGs. The idea is that the change owners would have to get formal approval from each WG that the change is OK and what are the possible constrains from the WG point of view. If the Change does not effect the WG, then this basically means the Change is OK. I think it is important to get decision from WG even though the Change owner thinks the change does not affect the WG.
Since some WGs don't have ticketing system, the FESCo ticket could be used for the decision from WG.
I think the new process for system-wide changes should be something like (changes are bold):
TL;DR I am against this proposal.
background analysis The wiki page http://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes doesn't mention approval from WGs explicitly. I know that everyone is expected to discuss the change with affected WGs, however this may not really happen to the necessary extent.
background analysis
The wiki page http://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes doesn't mention approval from WGs explicitly. I know that everyone is expected to discuss the change with affected WGs, however this may not really happen to the necessary extent.
This paragraph defies the whole proposal. If I, as a package maintainer, decide to do something against guidelines, there must be
No matter how many policies you write, there will be always somebody who will do something against them (probably unknowingly).
The only thing which helps is '''communication''', good luck writing policy about it ...
I feel that should be the work of WG liaison to establish a bridge between Fesco/WG.
I'm not against this proposal as it explicits the importance of WG in the change process, we need to refine the proposal.
If we are honest about reflecting the existence of working groups, then we have to give their representative(s) a full FESCo seat and a more direct stake in how things are run. Having a liaison is nice, but it also adds a layer of complexity. Very few people know every single thing that goes into Fedora at the same level of detail, which means that FESCo is already biased depending on each member's background / involvement in Fedora.
So, it is pointless to pretend that having a totally "neutral" FESCo, plus some extra process on top, somehow ensures better technical decision making. One way or the other, we are all biased, and nobody likes more process. Let's try to cut down on needless bureaucracy, and ensure that Fedora Engineering Steering Committee's biases are representative of the actual products that Fedora claims to ship.
Of course, FESCo should continue to have some non-WG seats so that the larger Fedora community is represented and issues outside the direct interest of the WGs can be addressed.
Replying to [comment:3 hguemar]:
That is just needless bureaucracy.
This is the most important sentence: "Thus the FESCo's decision does not have much of a meaning if the WGs decide they don't want the change in their product."
What is the point of having an engineering steering committee if the people doing the products that we ship don't agree with it? That is why WG liaisons should be full members of FESCo and nominated by each WG.
The most logical choice is to drop the entire system wide process ( and arguably the entire feature process since people have been bypassing it for quite awhile ) since in reality it has not existed since the introduction of the WG's and products.
Instead people with change proposals should open a dialog with the affected WG's and they together reach a conclusion if said change should be implemented in the affected product(s).
If the proposed change is approved and implemented in the product(s) it should be noted in the products highlights at release time and that's it.
This should result in reduced overall community bureaucracy and required resources to sustain such unnecessary bureaucracy.
Replying to [comment:5 rishi]:
Replying to [comment:3 hguemar]: I feel that should be the work of WG liaison to establish a bridge between Fesco/WG. That is just needless bureaucracy. This is the most important sentence: "Thus the FESCo's decision does not have much of a meaning if the WGs decide they don't want the change in their product." What is the point of having an engineering steering committee if the people doing the products that we ship don't agree with it? That is why WG liaisons should be full members of FESCo and nominated by each WG.
Or the entire purpose and role of FESCo re-evaluated since the WG's fully control their products which they have to be to be able to deliver it as they envision it.
Replying to [comment:6 johannbg]:
The most logical choice is to drop the entire system wide process ( and arguably the entire feature process since people have been bypassing it for quite awhile ) since in reality it has not existed since the introduction of the WG's and products. Instead people with change proposals should open a dialog with the affected WG's and they together reach a conclusion if said change should be implemented in the affected product(s). If the proposed change is approved and implemented in the product(s) it should be noted in the products highlights at release time and that's it. This should result in reduced overall community bureaucracy and required resources to sustain such unnecessary bureaucracy. ... Or the entire purpose and role of FESCo re-evaluated since the WG's fully control their products which they have to be to be able to deliver it as they envision it.
...
I think you make some excellent points. I'm not sure that the "system-wide" process hasn't existed though. There are definitely some points that are CLEARLY system-wide (in the sense that they have a wide impact on rel-eng, docs and QA). But there's definitely a middle-ground missing where a change could be Edition-wide without being Fedora-wide.
You are probably right that FESCo's role is reduced from where it once was (and I'd argue that's a good thing; more on that below). We've delegated a lot of the decision-making to the WGs already. FESCo ''does'' need to hang around for a few cases, most notably dealing with inter-Edition disagreements (such as whether we want to assert some minimal level of functionality between them all, or rule that they may not do certain things, etc.) It's an interesting question where this falls in a world with a more involved Council and a Base WG as well, but I think that FESCo still has a part to play.
As for why I think it's good that FESCo's role is reduced? In the past, FESCo was essentially the highest authority in the land (on technical issues) and thus effectively mandated that everyone on FESCo needed to become at least familiar with every aspect of the project, which is not particularly realistic. In this new setup, I rather see FESCo as sort of a village council with a support system of advisors in the forms of the WGs to help them make informed decisions.
So I think the simplest small change we could make here is to add an Edition Change between self-contained and system-wide that FESCo would delegate the decision on to the affected Edition WG.
The most logical choice is to drop the entire system wide process ( and arguably the entire feature process since people have been bypassing it for quite awhile ) since in reality it has not existed since the introduction of the WG's and products. Instead people with change proposals should open a dialog with the affected WG's and they together reach a conclusion if said change should be implemented in the affected product(s).
While I agree that this may be a way, you still need some entity to go to for approval for non-products. Like spins and non-product installation of Fedora in general.
Replying to [comment:4 rishi]:
If we are honest about reflecting the existence of working groups, then we have to give their representative(s) a full FESCo seat and a more direct stake in how things are run. Having a liaison is nice, but it also adds a layer of complexity. Very few people know every single thing that goes into Fedora at the same level of detail, which means that FESCo is already biased depending on each member's background / involvement in Fedora. So, it is pointless to pretend that having a totally "neutral" FESCo, plus some extra process on top, somehow ensures better technical decision making. One way or the other, we are all biased, and nobody likes more process. Let's try to cut down on needless bureaucracy, and ensure that Fedora Engineering Steering Committee's biases are representative of the actual products that Fedora claims to ship. Of course, FESCo should continue to have some non-WG seats so that the larger Fedora community is represented and issues outside the direct interest of the WGs can be addressed.
I disagree with reserving any seats for WG members in FESCo. Anyone can nominate themselves into FESCo, so also a WG member.
Replying to [comment:10 thozza]:
Replying to [comment:4 rishi]: If we are honest about reflecting the existence of working groups, then we have to give their representative(s) a full FESCo seat and a more direct stake in how things are run. Having a liaison is nice, but it also adds a layer of complexity. Very few people know every single thing that goes into Fedora at the same level of detail, which means that FESCo is already biased depending on each member's background / involvement in Fedora. So, it is pointless to pretend that having a totally "neutral" FESCo, plus some extra process on top, somehow ensures better technical decision making. One way or the other, we are all biased, and nobody likes more process. Let's try to cut down on needless bureaucracy, and ensure that Fedora Engineering Steering Committee's biases are representative of the actual products that Fedora claims to ship. Of course, FESCo should continue to have some non-WG seats so that the larger Fedora community is represented and issues outside the direct interest of the WGs can be addressed. I disagree with reserving any seats for WG members in FESCo. Anyone can nominate themselves into FESCo, so also a WG member.
I am too having same opinion of not to reserve any seats for WG members in FESCo. They can nominate themselves into FESCo.
This may be hopelessly naive, but I would primarily expect the WG members to be active on devel@ when the Change is originally announced, and be a part of the conversation in there. ''That's'' where the proposal should ideally be discussed and improved.
In the ideal case, the FESCo vote would ''only'' be a formal recognition of a consensus about the best approach that could be found on devel@. Sure, the FESCo process and ticket allows for a sanity check by experienced members of the community, ensures someone takes a look even if nobody at devel@ finds it inherently interesting, and gives a way to resolve disputes by voting when a consensus can not be achieved, but those are all second-best options.
The proposed two-step/multi-party approval process goes in the opposite direction, moving from a single discussion in the wide community towards a set of individual rubber stamps, where the Change owner may be left playing a messenger between the various committees and trying to satisfy, or negotiate with, every rubber-stamp-giver individually, when it would be much more efficient for all of the interested ones to just meet in one place and one (virtual) time and find the best solution. At the moment the time and place we have is devel@, one week between announcement and FESCo vote.
It’s likely we can improve the process; I don’t think atomizing this into independent approvals would be the right direction. (As a counter-proposal of sorts, if the working group members are not usually present at devel@, perhaps they can ask their liaisons to watch the incoming stream of Changes and point out those where the WG members should participate.)
Replying to [comment:8 sgallagh]:
Replying to [comment:6 johannbg]: The most logical choice is to drop the entire system wide process ( and arguably the entire feature process since people have been bypassing it for quite awhile ) since in reality it has not existed since the introduction of the WG's and products. Instead people with change proposals should open a dialog with the affected WG's and they together reach a conclusion if said change should be implemented in the affected product(s). If the proposed change is approved and implemented in the product(s) it should be noted in the products highlights at release time and that's it. This should result in reduced overall community bureaucracy and required resources to sustain such unnecessary bureaucracy. ... Or the entire purpose and role of FESCo re-evaluated since the WG's fully control their products which they have to be to be able to deliver it as they envision it. I think you make some excellent points. I'm not sure that the "system-wide" process hasn't existed though. There are definitely some points that are CLEARLY system-wide (in the sense that they have a wide impact on rel-eng, docs and QA). But there's definitely a middle-ground missing where a change could be Edition-wide without being Fedora-wide. You are probably right that FESCo's role is reduced from where it once was (and I'd argue that's a good thing; more on that below). We've delegated a lot of the decision-making to the WGs already. FESCo ''does'' need to hang around for a few cases, most notably dealing with inter-Edition disagreements (such as whether we want to assert some minimal level of functionality between them all, or rule that they may not do certain things, etc.) It's an interesting question where this falls in a world with a more involved Council and a Base WG as well, but I think that FESCo still has a part to play.
I'm not saying FESCo is irrelevant since there still exists ( few ) use cases ( like merging back the role that FPC is currently has ) for it's existence but in it's current form it's purpose is completely out of sync with what is and has been happing in the project ( as is the feature process and the release schedule ).
From my point of view you cannot assert some minimal functionality on the products ( at least not as they are now and have evolved to. BaseWG would for example have to be based on the absolute lowest common denominator between the wg's as opposed be that dumping ground for WG's for components they dont know what to do with or maintain) nor can you rule what they can or cannot do since in doing so you interfere with their indented outcome, it's purpose and it's target audience.
As for why I think it's good that FESCo's role is reduced? In the past, FESCo was essentially the highest authority in the land (on technical issues) and thus effectively mandated that everyone on FESCo needed to become at least familiar with every aspect of the project, which is not particularly realistic.
Not familiar with but possess the in depth knowledge to make enlighten and informed decision and that requirement is never going to change as is the fact the rarely elected individuals live up to that requirement
In this new setup, I rather see FESCo as sort of a village council with a support system of advisors in the forms of the WGs to help them make informed decisions.
That makes no sense to me since you could just as well use the exciting council for such "advisory" role.
If you do that you still have that bureaucrat overhead as opposed to just have the individual(s) contact and collaborate with the WG's directly. Currently and for quite sometime the feature process has been nothing but marketing gimmick ( just like the release milestones alpha, beta final are etc the ).
Replying to [comment:9 thozza]:
Replying to [comment:6 johannbg]: The most logical choice is to drop the entire system wide process ( and arguably the entire feature process since people have been bypassing it for quite awhile ) since in reality it has not existed since the introduction of the WG's and products. Instead people with change proposals should open a dialog with the affected WG's and they together reach a conclusion if said change should be implemented in the affected product(s). While I agree that this may be a way, you still need some entity to go to for approval for non-products. Like spins and non-product installation of Fedora in general.
There is no "non-product installation of Fedora" other than the "generic" kind, which the "ring" proposal has yet to eliminate, which in turn makes all that effort just effectively be dressing Fedora in the emperor's new clothes but people have hard time seeing that as well as realizing that spins are the community made products and always have been, they have not just been made by Red Hat to push it's early adoption and testing of it's products like the WG's are currently doing hence spins never have had any official rubber stamp on them like those do.
And since "spins" and "products" are effectively the same thing, those two should be using the same "process" either by merging them ( which means spins become products on par with the exciting ones ) or by continuing using the distinct separation of what the community makes vs what Red Hat makes and is pushing for adoption ( and continue treating the community made ones as second class citizens in the process ).
Anyone can nominate themselves into FESCo, so also a WG member.
That is clearly false, because I had to get elected in order to become part of the committee. I didn't just nominate myself into it.
What anyone can do, is run for the FESCo elections and convince people to vote for her.
I don't think Fedora's highest engineering body needs to be a free-for-all popularity contest. Well run free software projects usually tend to be meritocracies instead of democracies, in my experience. Even the Fedora Council is not a 100% democratically elected body, so why should a technical committee be so?
To be fair, even in its current form, usually technically competent people who are deeply involved in Fedora tend to get elected to FESCo. Regardless, it is unrealistic to expect every member of the committee to have an equal understanding of every aspect of the project. Each individual brings with herself a certain skill set.
Fedora builds, designs and markets three different products now. For FESCo to stay relevant in this context, we should ensure that they are equally represented, instead of having a free-for-all election and hoping that it will all work out in the end. This isn't so different from the Council's membership.
Of course, this doesn't mean that FESCo should be exclusively made up of WG representatives. We should continue to have elected seats from the wider community to deal with issues that are not WG/product-specific. eg., release engineering, spins, testing, etc..
Replying to [comment:16 rishi]:
Replying to [comment:10 thozza]: Anyone can nominate themselves into FESCo, so also a WG member. That is clearly false, because I had to get elected in order to become part of the committee. I didn't just nominate myself into it. What anyone can do, is run for the FESCo elections and convince people to vote for her.
This is pretty much what I meant. I think my point remains valid. The need to be elected was implied.
The WG liason is there for the exact purpose of making sure they raise concerns over issues or concerns that the WG may have. It covers concerns with the Changes also so there is nothing that needs changed here. However the liasons should with changes. (+6)
I typoed, so let me try again:
The WG liason is there for the exact purpose of making sure they raise concerns over issues or concerns that the WG may have. It covers concerns with the Changes also so there is nothing that needs changed here. However the liasons should be reminded to look at the FESCo agenda and raise any concerns they have with changes. (+6)
Login to comment on this ticket.