[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Proposal: Revise FESCo voting policy
From:       Rich Mattes <richmattes () gmail ! com>
Date:       2020-05-17 15:21:10
Message-ID: 92fba258-577a-3748-9a61-440195db4908 () gmail ! com
[Download RAW message or body]

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@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]