Re: Proposal: Revise FESCo voting policy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/17/20 9:36 AM, Kevin Kofler wrote:
Well, I also see a strong correlation between changes being driven,
requested and/or needed by RHEL and them being accepted by FESCo, even over
predominantly negative community feedback.

I am aware that correlation does not imply causation, but it does make me
wonder where those correlations come from, and in particular, whether
conflicts of interest play a decisive role or whether there is some other
mechanism in play here.

Some of it is a matter of resources. Fedora is a community distribution, in the sense that anyone with the time and drive to contribute is able to do so in some capacity. But there's a large variation in the capacity of any individual contributor to actually make changes. People who are paid by Red Hat and other companies, or who are otherwise fortunate enough to be able to dedicate a large amount of resources to work on Fedora and related technologies, are more likely to have the time and energy to experiment with and build new tools or technologies, integrate them into the distribution, and go through the process of getting those things through the relevant hoops to be part of the core distribution. And if you're getting paid by a company to do something, it's usually because it will benefit the company in some way (those benefits don't always have to be in conflict with the goals of the distribution, but it's definitely a spectrum).

That tends to explain why Red Hat employees are driving many of the larger changes to the distribution, and why they tend to be aligned with the needs of RHEL, but not why they're being accepted by FESCo over negative community feedback. To explain that, I think we have to look at the change process itself.

The standard for accepting a change via the Change Process (which I assume to be the project mission and foundations[1] - I can't find anything specific about approval criteria in the change process documentation) is so broad that the bar for saying "no" to a change proposal is quite high. Unless negative feedback from the community can make a convincing case that a change is not technically sound (and can't be rolled back with a contingency plan), doesn't tick all of the process boxes, or doesn't _somehow_ align with the mission and foundations of the distribution, there's really no reason for FESCo to block a change.

Rich

[1] https://docs.fedoraproject.org/en-US/project/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux