On Tue, 23 Jul 2024 at 21:32, Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Am Mittwoch, 24. Juli 2024 02:52:44 CEST schrieb Gary Buhrmaster: > > On Tue, Jul 23, 2024 at 10:38 PM Kevin Kofler via devel > > (*) And in addition, there is lots of cases > > where only those with negative feedback > > will decide to "opt-in" to offer an opinion, > > as they are motivated. > > If there are not enough people motivated enough to comment in favor of the > Change, this shows that the Change is not valuable enough to be > implemented. If in addition, enough people object to the Change for good > reasons, it follows that the Change should be rejected. > > The big issue with the process is that there is this ground assumption in > Fedora that change is inherently good, and hence any Change should be > approved by default. But IMHO, Fedora used to already be almost perfect, to The problem is that constant negative criticism only makes people start to instinctively choose against whatever the negative person says. The more items it is brought up, the stronger the reaction. By trying to criticize your way back to whatever was your view of perfection just creates a stronger reaction to move away from it. I am not saying silence would help but actually outlining things you may have found good or liked would have helped over the years. That said, I also find this unanimous approval problematic for a couple of reasons: 1. There are some subset of people who use Fedora because they thought it was a privacy focused distribution. Their concerns did not seem to be taken into account or it needs to be made clearer that is not what the project aims as a high priority compared to other items. Those people can then make a choice if the distribution is still what they want to use. 2. I would have liked to see a working server and infrastructure plan on who and how this service is to be run. A service needing to be run by Fedora Infrastructure usually needs a bit more time to get Yet Another Service Never Used(*3) running without problems. 3. This is collecting data which for the most part will end up like the bug reports from Koschei, Retrace, Abrt, etc.. stored somewhere with data which very few developers look at except to filter into another '/dev/null' folder .. but required to have infrastructure running for over a decade because it might still be needed. To me any of those needed to be detailed further. Where does personal privacy actually fit in the 4 F's. What happens to users if the Fedora infrastructure breaks or isn't possible to get to due to some Internet problem. What is to be done if this turns out to be not needed or useful after a release or two? Maybe those aren't FESCO issues (The first one is probably a council issue, the second one is infrastructure in some ways. but the third might be.) but I feel they need to be looked at. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
