While I am not going to defend all other approaches, I do think the Oscars (for all their well understood voting issues) do have a point that only those with experience in an area should vote for the category (for example, while everyone can vote for best picture, only those in the makeup guilds (unions) can vote for best makeup artists (they know whether the results can be reproduced by an intern with 5 minutes of training vs needing 30 years of experience and techniques). Some of the Fedora positions, arguably, need to be voted on by people who understand the requirements that the role expects, and not just by a popular vote. I am not claiming I know how that should work, but I have never been a fan of voting for certain candidates for positions I cannot fully understand their role, nor how they might be expected to fulfill them (and this has nothing to do with Fedora specifically).
This rule is actually afaik one of the reasons why this discussion has started, as it became a matter of perspective if and how this barrier is applied and thus if and when it is trivial or not. After an incident some time ago, that has shown different interpretations of how/when to enforce this rule, the Join SIG agreed that distributing memberships in their SIG to users, whom they felt to be worth to vote, is ok. So, when someone wanted to vote they felt worth it, they make them member so that they can vote, and then remove them again from the FAS once they voted â so was their agreement, it happened only once I think, but this revealed a little also that different FAS groups had big differences in when and how they allocate memberships. This âprovokesâ asymmetries we cannot measure.
I am not against your points, and I agree that Fernandoâs concerns are serious. As I wrote, I also see some entry barriers critical as they might exclude important groups, and that can be worse than including the âwrongâ ones (I simplify to illustrate:). But if we keep the system the way it is, some alignment of when and how allocate FAS memberships should be done. It can be even something very generic, but with some barriers: this example is not about if the Join SIG was right or wrong, but that blurred unclear rules, and the resulting different interpretations, can lead to problematic incidents due to different perceptions (and thus conflicts, which happened some time ago leading to this).
However, another idea to solve this by technical means would be to just add one or two conditions, such as that only people who are for over 1 year member of an FAS group can vote or so. And the condition to just logging into FAS 3 or 4+ times in the recent year (with at least 2 weeks or so in between each eligible login or so?) might even exclude 99% of those who MIGHT think of logging into their âdeadâ account solely for the purpose of voting (I agree with you the âdead votersâ are likely not relevant though). The latter unlikely would affect any ârealâ contributor, and the first might make people to get involve in Fedora and get an overview of what Fedora is and how it works before voting to FESCo â a year to âlearnâ could be desirable? Just some thoughts that might contain alternative compromises 
The example-conditions conflict with some thoughts of Fernando, but I am not sure if the average person only joining to vote for FESCo (not necessarily applicable to other boards) can be assumed to vote with predictability, which means to vote to get the result they actually want, which is not straightforward or reducible to a few sentences in the candidate introductions (a major issue in many ballot systems and origin of many contemporary issues in them). However, alternative conditions are possible too (that consider other stuff that is not necessarily bound to an FAS account or so?).
Just a thought: how would we know?
What if some group decides to stuff-the-ballot-box what would stop them?
Do we only want to react after such an unfriendly act?
I generally dislike the âWhat if..â approach in a volunteer-driven organization. It opens the door to infinite issues and adds up infinite workload. See:
What if US decides to economically block the European Union? Do we only want to react after such an unfriendly act?
All the "solutions" proposed above can be easily overcome by the new shiny AI agents whatever. We might not be even able to spot or prove that they are bots when talking to them on chats.
Sorry for these silly arguments[1] but I reject hypothetical arguments that adds up a huge amount of work and complexity to a volunteer-driven system.
By definition, volunteer-driven organization/systems work by reacting to events. It has been always like that. If someone is able to prove that this is a real issue, I will sadly accept a solution for it.
reductio ad absurdum âŠď¸
There are use cases where I agree with you and others where I think What-if is reasonable, for example with security and I suggest voting systems.
I know of a few user based organizations that changed their voting rules in order to limit the ability for board (and organization) capture after they understood the potential impacts (and believed some might be considering the strategy). And at least one organization that did not see the issue(s) coming in advance and ended up losing one of their most valuable assets. Neither (or other) cases may happen with Fedora, but the Fedora community should decide what they wish to accept.
I think the results prove that. We have barely 300 people voting and the number is trending downwards.
Yeah, that is why I think we cannot open the door for anyone to vote just by creating an account. We need some mechanism to add friction.
I think just slowing things down can be very effective. If â purely hypothetically â a popular youtuber talks about how great it would be if people cast votes in the Fedora election, a hundred or two people might try this. But if they have to do some steps, and then wait two weeks, and then do some more steps, the number that actually goes through this will probably be negligible. So overall, I think we need a little slowdown and a contribution threshold, but we should be flexible and accommodating to all kinds of contributors.
The question was meant less literal I generally agree, but the point is, there are a lot of assumptions contained: e.g., if I count all people of whom I am convinced (first assumption) they vote, I guess I will still remain below 150, so I cannot exclude that 150 are in any of the groups determined as problematic (such as dead accounts).
I donât think this is the case at the moment, but since our goal is to increase contributions: I doubt we are capable to distinguish between increasing contributor votes and, e.g., dead account votes, and with increasing numbers, this can grow to a problem at some time (the more contributors there are, the less everyone knows everyone even in engineering, but at the same time, the more important we become and thus the more attractive exploitation becomes â you mentioned yourself the youtuber example). Just wanted to highlight the assumptions and the dilemma
100%! As you are a representative in FESCo and engage/lead in abstraction layers most people of this discussion donât engage in: do you have preferences in mind? May it be such as those I mentioned in my last post, or something else?
It would be interesting if we can come up with more concrete alternatives that we can compare in the discussion to the original ideas of this topic.
Regarding data-oriented trust models (as opposed to human-oriented âvouchingâ, etc):
Measures such as âNumber of FAS Groupsâ and âRequired Badgesâ are proxies for the real question weâre trying to answer, which I believe to be: âIs the user actively contributing?â
The goal of FDWG (matrix: #data) is to be able to answer this question directly, and weâre making significant progress. It will be fairly easy for us in the near future to be able to roll things up to where we can say, âHas this user contributed to the project in at least 3 of the past 12 months?â and similar. To me, thatâs the right level of granularity to ask the question. (Though of course we can also drill down into âin what way?â and âhow much?â if necessary.)
Everything else is just asking for pain as we conflate things like authentication with activity with participation with contribution with recency.
p.s.
Join us in Matrix if you have some time and SQL skills (Postgres, DuckDB) or infra skills (ansible, k8s, etc) to help us accelerate this work.