On Wed, 24 Jul 2024 at 14:18, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > On Wed, Jul 24, 2024 at 1:46 PM Miroslav Suchý <msuchy@xxxxxxxxxx> wrote: > > > > Dne 24. 07. 24 v 12:30 odp. Joe Orton napsal(a): > > > > Having a "majority rule" vote of e.g. packagers or provenpackagers on > > major technical decisions would be far superior, in my view. Apache > > communities have worked this way forever. > > > > You can always propose this as a change to our process. > > For what it's worth, I don't believe that this process will work well. > I'm all for democracy, but direct democracy without compulsory voting > inevitably leads to "grievance-based voting", where the majority of > folks ignore the discussion and a plurality of voters with a strong > opinion effectively stuff the ballot box. The effect is to have a > tyranny of the (loud) minority. The closest we could get to > "compulsory voting" would be to require a quorum of votes to be > considered binding, but even the FESCo and Council elections > traditionally see extremely low voter turnout. I don't think we'd be > able to reach a sensible quorum on a referendum-based system. > > Beyond that, I don't think the current approach is actually broken. > People elected us to make these sorts of decisions on their behalf. If > any of us were to consistently vote in a way that the general > community members felt is not in the interests of Fedora, then I fully > expect and hope that we would not be re-elected. > Going from most social studies, the more likely alternative is that people just stop voting (which might be the reason for the low voter turnout). Many elections have about as many people as there are open seats with many of the people being the ones who have been on it already. When there are more candidates, the ones who aren't elected are usually 'unknowns' versus 'knowns'. It is easier to just not participate versus vote in an unknown (a person might not like the current people, but they don't want to be responsible for a worse selection). I don't have a voting solution to this.. term limits is the band-aid which is usually pushed but I expect it won't increase participation or change perceptions that things are rubber stamped. I also don't think Fedora would work in a direct or semi-direct democracy on these issues. I think a better solution is that votes are explained for things which are contentious (and this subject is definitely contentious..) I really have no idea WHY any of the people voted for this from the ticket.. which is a major reason it looks like a rubber stamp. Yes there were comments in threads and in previous meetings but not in the 'record of business'. changing some of the https://pagure.io/fesco/issue/3242 from +1 to "+1. I believe that the concerns brought up in previous issues have been addressed." or "+1. I think that problems with privacy are a Fedora Council issue and from an engineering perspective this proposal meets the things we approve." or even "+1. I would like to keep my job and the HAL AI they have installed says this is needed." > The current approach is the best one I can think of for our community: > we have an active feedback period where anyone can (and is encouraged) > to chime in on potential changes. I can assure you that I read that > feedback and I expect that the other members of FESCo do the same. If > you look at our meeting notes, you'll notice we often defer our > decisions when a discussion remains highly active. > > As for the accusations of "rubber stamping" all Changes, I'd like to > note that FESCo has declined to accept several Changes this cycle > based on feedback. If you look at last week's minutes, you'll note > that we discussed and rejected two proposals and approved another > reluctantly (due to a lack of better options). > > By the time issues get to a FESCo vote, they've generally run through > the discussion and have either been agreed to or the disagreement is > clearly not going to reach a compromise, at which point FESCo has to > make a decision. Sometimes that's going to be controversial (as in > this case, apparently). When voting, we don't always restate our > thought process, which admittedly means that the votes - taken in a > vacuum - can lack context and perhaps appear unconsidered. > > -- > _______________________________________________ > 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 -- 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
