Defining a "Fedora Verified" Membership

[jflory7 (Justin Wheeler)]

Following the Fedora Council 2026 Strategy Summit (FCSS 2026), the Council has been working on a proposal to evolve how we recognize and empower our community members. As our project community ages and grows, we want to modernize our legal foundations (moving from a manual FPCA signing process to implicit consent via FAS authentication) and establish a new, human-centric tier of recognition: Fedora Verified.

The goal of “Fedora Verified” is to secure our governance (voting and running in elections) and shared resources through mutual trust, rather than relying strictly on cold metrics. We are real people with complex lives, and we want a system that honors the “invisible work” (like mentoring, docs, and design) that automated scripts often miss.

Tonight at the SCaLE 23x Fedora community dinner, I handed out a printed “strawman” proposal to 13 contributors to get their gut-check on some of the initial concepts. Their feedback was insightful, honest, and clearly showed where we need to adjust our thinking.

Here is what we proposed, what the Fedora community at SCaLE 23x told us, and where we need your help next.

---

1. The Quantifiable Baseline: We Need a Filter, But Our Numbers Were Too High

What we proposed

Before asking for a human vouch, we suggested a data baseline to show foundational project experience: A FAS account older than 6 months, 15 Fedora Badges, and membership in at least 5 FAS groups (“CLA+5”).

What we heard

The consensus was “MAYBE.” Almost everyone agreed that a baseline filter is necessary to verify legitimate contributions. However, Fedora contributors at SCaLE 23x told us that 15 badges and 5 groups is a massively high bar that risks becoming elitist. Furthermore, contributors pointed out technical blind spots: CentOS SIGs affect FAS groups, and simply put, not everyone cares about Fedora Badges.

The Takeaway

We need to lower the barrier to something much more reasonable and welcoming for newcomers.

---

2. Human Validation: Committees Are Out, Grassroots Are In

What we proposed

We offered two paths for human validation:

• Option A: Grassroots (gather 5 vouches from existing Verified members).
• Option B: An Elected Membership Committee.

What we heard

Grassroots won by a landslide at the SCaLE 23x dinner (12 to 1). The community strongly prefers decentralized, peer-to-peer validation. Some respondents rightly pointed out that an elected committee might not actually be familiar with a contributor’s specific area of work. However, the feedback also highlighted that finding five people to vouch for you is too difficult, especially for new folks trying to break into the community.

The Takeaway

We will focus on a grassroots vouching model, but we need to reduce the required number of vouches to a more accessible number (e.g., three).

---

3. Phasing Out & Rebuilding Trust: Security is Vital, but Telemetry is Flawed

What we proposed

To protect our ecosystem from supply-chain attacks (like the xz incident), we proposed that dormant accounts lose Verified status after 12 months of inactivity on the fedora-messaging bus. Returning contributors are always welcome back, but would need to participate a bit to re-earn their status.

What we heard

12 months is fair, but the message bus is not the whole story.

There was overwhelming support for the 12-month expiration timeline as a necessary security hygiene practice. However, several veterans gave us a critical technical warning: the fedora-messaging bus is not a reliable single source of truth. Time-based metrics can put a profile in front of a human for review, but there are massive amounts of vital contribution that the bus simply does not measure.

The Takeaway

We agree on the 12-month security timeline, but we must find a better, more holistic way to define “activity” so we don’t accidentally penalize active contributors whose work happens off the bus.

---

Where We Need Your Voice

This is where the broader Fedora community comes in. We are building this together, and we want to ensure this membership model truly reflects our Four Foundations. I would love to hear your thoughts on the following questions:

1. Finding the Baseline: If 15 Badges and 5 Groups is too high, what is a fair “minimum viable baseline” to filter out spam without gatekeeping genuine newcomers?
2. The Vouching Sweet Spot: If 5 vouches is too many, how many human vouches feels right to you?
3. Measuring Presence: How can we accurately and fairly measure “activity” for our 12-month security check without relying entirely on the fedora-messaging bus?

I’m looking forward to reading your thoughts and iterating on this together. Let’s build a model that keeps our ecosystem secure while celebrating the humans behind the code!

[jflory7 (Justin Wheeler)]

Here are the AI-generated printable sheets that I shared with Fedora contributors at the SCaLE 23x community dinner. I spent not a lot of time condensing a long time’s worth of discussion into these sheets. They have flaws and they are not perfect, but they were useful conversation starts.

Sharing here as a reference, for the benefit of anyone who was not there but is curious, and for anyone who wants to answer any of the questions shown in the form!

[leigh123linux (Leigh Scott)]

@jflory7

The Vouching Sweet Spot: If 5 vouches is too many, how many human vouches feels right to you?

I don’t think non-packagers should get a vote for FESCo elections.

[py0xc3 (Chris)]

protect our ecosystem from supply-chain attacks (like the xz incident), we proposed that dormant accounts lose Verified status after 12 months of inactivity

I’m not sure if the xzutils incident has a relation to dormant user accounts (maybe I missed something off the cuff?). In xzutils it would have been more collaboration and/or exchange with Product Security that would have made an impact and could solve the issues we had in future

Finding the Baseline: If 15 Badges and 5 Groups is too high, what is a fair “minimum viable baseline” to filter out spam without gatekeeping genuine newcomers?

We would more actively need to enforce that FAS groups are used for everything that is a team (which currently it is not, many FAS groups are effectively orphaned even if the teams still exist, other teams never had that), and in a more standardized way. Otherwise that would be likely disproportionate for different types of developers: some teams take new members after a few posts, others expect long regular reliable contributions before adding to FAS (I’m not questioning any of the two, just mentioning, both can have reasons).

Maybe different ways to achieve the baseline might make sense? There are numbers of badges and types of badges (I actually would differ among different types of badges) in which I would say ABSOLUTELY YES, ADD THEM! But as already said, there are people not caring much for badges. So implement different tracks. What I had in mind off the cuff, e.g., …

• This number of FAS groups (e.g., 3 or 4?) (and keep in mind some teams/groups can impose so much work that 1 or 2 FAS groups already exhaust the capabilities of an contributor) OR
• This number of badges from this group of badges (I would be selective in badges as some are effectively without value) OR
• This number of git commits in a repo of ours OR
• This number of packages actively maintained (e.g., I would complement this with a measurable action that has to be done regularly)
• This number of bug reports against the product “Fedora”
• This number of solutions in Discourse
• Opening git issues that fulfill certain criteria (e.g., are allocated any tag before closing indicates it to be somehow useful; though that contains many assumptions)
• Processed flags in Discourse
• (any means to measure contributions in Matrix and in Discrouse’s Project Discussion?)

… or achieve ANY 2 or 3 of them → its just examples, there are many more ways.

In any case, with badges keep in mind they are not just of very different value, but also some badges are awarded not regularly (e.g., if someone chairs a meeting weekly of an important team, this indicates important involvements, but they get only one badge at all - for ALL meetings they chaired)

The Vouching Sweet Spot: If 5 vouches is too many, how many human vouches feels right to you?

Again, I would not limit it to this specific criteria, but allow to complement different ones, and the sum must be reasonable to avoid to become to rigid. I’m not sure there is just the one type of human validation.

It makes also a difference what I can vouch for: e.g., if I met someone in person at a conference, some interactions might rise that give me the possibility to vouch for more than just their posts (I exaggerate:)

Also, I find it reasonable that someone who just signed up cannot get a human validation → I mean, that’s the sense of it, isn’t it? So I’m not sure if 5 in cases in which I do not know the person are too high. If people met someone in conferences, it might be possible to replace twice 2 votes by 1 met in person? So 2 vouches from people who met someone in person plus any 3rd one?

On the other hand, many different groups might have different ideas when to vouch for someone. Based on existing policies of adding people to groups in the past, I’d say a few posts in Discourse could suffice for some people to vouch. This is not criticism nor shall it imply that is wrong! But I would also add some criteria that are obligatory for those vouching: give them questions they have to answer all with yes. So to get some common ground for vouching: otherwise, the lowest barrier will apply and might develop to a race to the bottom for getting contributors or so (we introduce something that I hope we know can cause very complex und hard-to-foresee social dynamics).

And this is the point at which I refer to XZUtils, and remind on how that happened (despite the chain of trust and assumed human validation) → my point here is, ensure a standard for validation that cannot be easily bypassed by social means and economics if you want to prevent supply chain attacks and such I think the XZUtils “social vulnerability” would be easy to exploit if we just introduce “any 5 contributors to do any 5 vouches” or so.

Supplement: You can also use the “in person conference” stuff as a criteria for vouching: you can vouch for someone if you can say YES to any 3 of X questions about this account/person: one of the questions can be to have “met in person at a conference and the person confirmed they are the person behind this account”. Stuff like that.

Measuring Presence: How can we accurately and fairly measure “activity” for our 12-month security check without relying entirely on the fedora-messaging bus?

Automated, might be …

• contribution in any git repo
• opening git issues
• posts in git issues
• posts in discourse
• bugzilla reports against product “Fedora”
• mailing list emails
• posts with their Fedora account in matrix, but I’m not sure if it can be measured if they post anything anywhere in the Fedora space

We should implement different ways for different types of contributors, complemented with OR → fulfill e.g. any 2 of them.

That would be possible automated, but I didn’t check if/how complex that would be. Off the cuff, I’d say it might be reasonable

In any case, for the sake of different cultures, I’d not gather new information but only use the information that we “have to get” for technical reasons anyway. Gathering additional information can cause too many social and legal implications.

---

---

In any case, I would in all variants offer some flexibility, set multiple criteria that should allow every type of contributor to fulfill X out of Y possibilities. And whatever possibilities we set, they should be either somehow standardized and exist at the expected places (e.g., FAS groups), or be easily replacable to avoid disadvantaging some contributors. And we should avoid criterias that can lead to races to the bottom and different interpretations.

As my points suggest, the criteria might be overlapping.

Keep in mind that this (including my variants) can become very dangerous, because just like badges can disproportionate cause contributions in some areas for “badge hunters” and even encourage cheating (e.g., get karma for tests that cannot be verified), so can this concept achieve the same but also the opposite, and at the worst get rid of some groups/types of contributors at all, and that what makes me worry most about these types of approaches: we cannot verify in advance (which does not imply they are a bad compromise or so). I would leave an (intentional social:) backdoor open to allow to identify + adjust once introducing something like the suggested approaches, and allow people who find that this does not behave as it should at some places to make aware easily and quickly.

@leigh123linux

I don’t think non-packagers should get a vote for FESCo elections.

There are other groups who should be eligible, as packagers are not the sole experienced people with implications around a Linux OS.

But I agree that it can be questioned if everyone who makes any type of contribution can be eligible for a FESCo election once that contribution reaches a certain amount.

[py0xc3 (Chris)]

I forgot, I suggest to develop test cases: take all teams you think have necessary value/supply, identify roughly the different types of contributors these teams have (some teams have different types of contributors who will achieve different criteria) and thus whom you want to include in any case, and then check if they fulfill your criteria or if you “kick” them by accident out. That can help to mitigate some types of issues.

[jspaleta (Jef Spaleta)]

Hmm.

if FESCO chooses to limit its representation to rpm packagers, then we will have to discuss how to renegotiate FESCOs delegated authority as it relates to technical oversight beyond rpm packaging.

Honestly I see benefits to both possible futures. One future where FESCO is more narrowly scoped, with tighter representational authority, and we empower other governance structures as part of a more granular self-governance model. The other future where FESCO continues to be technical oversight broadly where all technical aspects of the project roll into scope, and is representative of contribution interests in a very broad sense.

[gtb (Gary Buhrmaster)]

@jflory7

Before asking for a human vouch, we suggested a data baseline to show foundational project experience: A FAS account older than 6 months, 15 Fedora Badges, and membership in at least 5 FAS groups (“CLA+5”).

While I recognize it is acknowledged the numbers were too high, I decided to go check my status, and I am only a member of CLA+4 groups, so I would, in that scenario, not be able to vote in FESCo elections (even though one of the groups is packager).

[theprogram (MatH)]

First, I would suggest everyone to read the Council’s posts from their recent meeting in Tirana.

@bookwar

We started the conversation with an attempt to list all possible contributions to the Fedora Project, so that we can find a way to successfully track each of them. That exercise proved to be futile. There are many different ways people contribute to the project. Even if we list the current known ways, we don’t want to restrict people’s creativity. We actually want to encourage people to come up with other ways and show us what can be done.

From Fedora Council 2026 Strategy Summit daily briefings & summaries (@ Tirana, Albania) - #17 by bookwar

Second - what is our motivation for “evolving trust”?
I think it should be to expand the number of voters and contributors. Elite cliques are not sustainable. Only 200 people voted in the recent elections. 300 or 500 real Fedorans voting with the best intentions will make a much more resilient democracy.

Third - what is the problem we are trying to solve now? Might we make the problem worse by over-thinking or over-engaging in this issue?

[jspaleta (Jef Spaleta)]

Thanks for doing the in person discussion at SCaLE>

@jflory7

• Finding the Baseline: If 15 Badges and 5 Groups is too high, what is a fair “minimum viable baseline” to filter out spam without gatekeeping genuine newcomers?

Hmm. I’m actually okay with the badges thing, even though badges were never something that incentived me personally. The reason why I’m okay with it is there appears to be a lot of automatically earnable badges because of measurable message bus activity that we expect newcomers to generate. Is 15 too high? Maybe. Can we find new people who have FAS accounts that are about 6 month or a 12 months old and see if their badge accumulation experience matches these baseline expectations? We can always add more badgable opportunities to close the gap between measurable baseline and expected contributor journey.

The group thing, hmm I don’t know about that. That feels like we are asking people to spread themselves thin. Is it healthy for a new person to be in 5 groups? Is it healthier for people to be focused on an interest area and be in just 2 or 3. What does sustainable contribution look like in the 6 months or 12 month mark for volunteers?

@jflory7

• The Vouching Sweet Spot: If 5 vouches is too many, how many human vouches feels right to you?

Can we define what vouching requires? If vouching means I physically met you in a situation where I could have done the in-person gpg web of trust ritual, that’s a much higher bar than I vouch that your active in meetings on matrix. Also a little snarkily, does vouching imply you are making a positive contribution or just a memorable contribution? I’m pretty sure those are not simple circle Venn diagrams for some of us, myself included.

@jflory7

• Measuring Presence: How can we accurately and fairly measure “activity” for our 12-month security check without relying entirely on the fedora-messaging bus?

Hmm I don’t think we can get to accurately or even fairly. What we can maybe get to is multiple ways to achieve sufficient measurement. What if we had a process that traded off two different ways to do this? We trade measurable data and human vouch? If you are present enough in the measurable data stream your human vouch requirement is reduced. If you are not present enough in the measurable data stream your human vouch requirement is higher?

[luap99 (Paul Holzinger)]

Hi, I find this is a certainly interesting topic. I don’t have particular strong opinion about the numbers but maybe I can share my numbers here. I have an account for 5 years now.

I never looked at badges before, I have exactly 15 now, the last I got there now for simply logging in on the badges site. According to that site that puts me into the top 7% of the users.

I am in 3 groups (fedora-contributor, fedorabugs, packager). I am not sure why I should need to get into more groups. I guess it means I would need to join some SIGs to get more groups?

Now my packager work is quite low as I mainly work as upstream Podman maintainer and only do the packaging work as backup if my coworker who does the main work is not around. And even that is automated via packit, so all I would do is merge some dist git PRs.

I do however have done work that is not represented by these numbers.
I authored and implemented a Fedora “Change“ proposal for netavark and I did a fair amount of work with the the Fedora QE team (well mainly Adam) to enable more podman tests as part of openQA runs to ensure podman works great and is not broken by other updates.

So overall as mentioned I feel like the baseline is way to high. But do you even need a high baseline if there are still vouches? I think vouches are a good idea, 5 people feels a bit much but I guess that depends how willing people are to vouch? i.e. do you vouch only people you have meet in person, worked with in some project/group or anyone who has done the baseline requirement and asks you? That certainly influences how many vouchers should be needed.

[ekidney (emma kidney)]

Thanks for posting this, it’s an interesting topic! I like that you used a group at SCaLE 23x to temp check this first too

• Finding the Baseline: If 15 Badges and 5 Groups is too high, what is a fair “minimum viable baseline” to filter out spam without gatekeeping genuine newcomers?

I think badges are a good metric because when you first sign up it can track all those small things you do to get set up in the community. I had a quick look at the badges to see what ones are easy to collect when you first sign up:

• logging in for the first time
• signing the FPCA
• setting your avatar
• setting your timezone
• adding GPG or SSH key to your FAS

Then there are other ones that are achievable when you first join but still need some effort like:

• participating in an irc
• getting a cookie
• taking the community survey
• joining a team
• creating your own user page on the wiki
• ask or answer 1 question on Ask Fedora

There are others, but in my opinion 10 would be a good minimum so it’s encouraging community involvement but very much do-able.

For the groups, one is enough in my opinion. Sometimes people only have one interest area. I also agree with early comments that if we use this as a metric, a standardised way of using the FAS groups needs to be established/enforced.

• The Vouching Sweet Spot: If 5 vouches is too many, how many human vouches feels right to you?

5 is possibly too many for a newcomer. Maybe 2 with a process to make it more approachable, like a form or request you can send someone.

There would need to be guidelines on when or why you should give someone a vouch. Is it for someone you have worked or are currently working with? Are you on the same team? Or do you only vaguely know this person.

If someone is part of the community or a team and actively contributing, they should be easily able to get vouches from people in that space.

• Measuring Presence: How can we accurately and fairly measure “activity” for our 12-month security check without relying entirely on the fedora-messaging bus?

Could just be an automated email asking if they’d like their account to not be deactivated? Then it could be a reminder to get involved again

[jflory7 (Justin Wheeler)]

@leigh123linux

I don’t think non-packagers should get a vote for FESCo elections.

@py0xc3

There are other groups who should be eligible, as packagers are not the sole experienced people with implications around a Linux OS.

But I agree that it can be questioned if everyone who makes any type of contribution can be eligible for a FESCo election once that contribution reaches a certain amount.

This kind of categorization game costs a lot of time and energy to enforce, and for little gain. If we did this for the FESCo election, then we also need to think about who is eligible to vote in Mindshare Committee elections and what impact this might have on event funding.

The fact of the matter is, anyone who spends a lot of time in our project community as a contributor knows something meaningful about Fedora, our project, and our community. A “lone wolf” approach won’t get someone very far in Fedora, not without burning out, at least. If you spend a lot of time in our community, know the people in our community, and contribute towards the greater cause of our efforts to release an operating system every six months, then I think you deserve a say in all aspects of our governance.

Besides, from my experience in conversations with people across the last decade, many people who are not packagers already feel intimidated to vote in FESCo elections. I even know of packagers who have said they like they are not involved enough to vote. Creating unnecessary barriers makes us less effective as a project, not better.

@py0xc3

I’m not sure if the xzutils incident has a relation to dormant user accounts (maybe I missed something off the cuff?). In xzutils it would have been more collaboration and/or exchange with Product Security that would have made an impact and could solve the issues we had in future

No, you are right. I made a false connection to the specifics of that incident here. I should know better too, since I even wrote the Fedora Magazine article announcing our actions about the exploit. So, that is my fault!

@py0xc3

We would more actively need to enforce that FAS groups are used for everything that is a team

Could you provide an example or two of a team where this is the case? Other than Fedora Discussion staff, because that one just came up recently.

@py0xc3

Maybe different ways to achieve the baseline might make sense?

@py0xc3

Again, I would not limit it to this specific criteria, but allow to complement different ones,

@py0xc3

As my points suggest, the criteria might be overlapping.

@luap99

So overall as mentioned I feel like the baseline is way to high. But do you even need a high baseline if there are still vouches?

Yes! This is a theme I have heard in conversation with multiple folks. I think there cannot be a single, binary way of being “verified” or not. We need to have multiple pathways to recognition that fit different kinds of contribution personas.

I am wondering if it would be useful as a pre-exercise to define “contributor personas” that describe the kinds of contributor profiles that we have in the community.

@py0xc3

This number of FAS groups (e.g., 3 or 4?)

@jspaleta

The group thing, hmm I don’t know about that. That feels like we are asking people to spread themselves thin. Is it healthy for a new person to be in 5 groups? Is it healthier for people to be focused on an interest area and be in just 2 or 3.

I was considering the fact that in a post-Forgejo world, every legitimate FAS group will actually have at least two, if not more, groups because you typically have a FAS group and then there is also a Forge group. So, membership in a single team might immediately make you FPCA+2 because of a git forge group membership, or even FPCA+3 because of the fedora-contributors meta group.

Or I don’t know if it will only work this way with “old” teams before we had the Fedora Forge. But then, this immediately skews the metric of how many groups is “enough.”

@py0xc3

This number of badges from this group of badges (I would be selective in badges as some are effectively without value) OR

I recall someone suggesting the idea of earning specific pathways of badges.

@py0xc3

This number of git commits in a repo of ours OR

I am hesitant to use a git commit as a useful metric for anything because I can make a tiny change in 43 git commits, or I can make a huge, architecture-shifting change in a single commit, and those can be significantly different in weight and value. A git commit is basically a sign of life to me. Beyond the sign of “hi someone is here!”, it is not useful for me in much of any other way.

@py0xc3

This number of packages actively maintained (e.g., I would complement this with a measurable action that has to be done regularly)

TBH, I feel like any package maintainer would/should immediately qualify for this.

@py0xc3

… or achieve ANY 2 or 3 of them → its just examples, there are many more ways.

I like to imagine something a bit like a rubric.

@py0xc3

I find it reasonable that someone who just signed up cannot get a human validation → I mean, that’s the sense of it, isn’t it?

Right. The idea is that a verified contributor is someone who has made some sort of impact in our community and is also recognized by their peers for having done so.

If you are brand-new, it is intentional. You shouldn’t be able to get “Fedora Verified” or whatever on Day 0. You need to spend some time in the project and in our community to get a sense of how we operate and what our community culture and values are.

@py0xc3

On the other hand, many different groups might have different ideas when to vouch for someone.

I think some variation is okay, but we could provide guidelines to help.

@py0xc3

Automated, might be …

• contribution in any git repo
• opening git issues
• posts in git issues
• posts in discourse
• bugzilla reports against product “Fedora”
• mailing list emails
• posts with their Fedora account in matrix, but I’m not sure if it can be measured if they post anything anywhere in the Fedora space

Meetbot meetings are another good one. Activity in the Fedora Penpot might also be a good metric. There are a lot of things not counted in this list, but that is where I think the “human vouching” mechanism could carry a heavier weight. So, if your contributions do not stack so highly in these things, you could “compensate” with a higher-than-average number of peer nominations. Or something to this effect.

@py0xc3

so can this concept achieve the same but also the opposite, and at the worst get rid of some groups/types of contributors at all,

We have to remain diligent during the roll-out of this program to make sure we are not cutting a legitimate project out. That’s why this process is starting here, right now, very slowly and gradually. The goal is for us to have a concrete proposal by Flock. I would hope @jspaleta could stand on the Flock stage and give us a pitch about the model. Or this is the ideal milestone for me!

@gtb

While I recognize it is acknowledged the numbers were too high, I decided to go check my status, and I am only a member of CLA+4 groups, so I would, in that scenario, not be able to vote in FESCo elections (even though one of the groups is packager).

I definitely have heard that CLA+5 was too ambitious. I think I need to come up with a matrix of permutations of how someone could be considered eligible for this.

@theprogram

Second - what is our motivation for “evolving trust”?

There are various reasons. I think this detail might deserve a breakout topic or need more forethought in how we present this. It is one of the top questions I see coming out of this. And to be honest, I think there are a number of reasons.

Despite having ample data, we do a poor job at describing our impact in the world, our value, and our contributions in data. There are several qualitative and interpersonal aspects to our work that make us successful as a project and community. Yet we have a hard time articulating that in a meaningful way. I think this impacts us negatively in many ways. In a corporate, commercial way, it means we have a hard time describing our impact and the results of investments into a project. If you spend a lot of money on something, you likely want to know if that thing is growing, shrinking, or changing in a meaningful way. In a nonprofit or non-commercial way, it makes it hard to discuss impact of donor and grant funds toward impact. Even for people with lofty goals and visions, you need to know whether your investment is meeting the mark or not. This is just how it works!

So, having a “verified” model for Fedora membership comes up with a way for us to establish a baseline for what meaningful contributions are, how to start establishing trust as a community member (and perhaps gaining access to more sensitive, trusted services and data), and voting in the leadership and governance in the project.

While I do tend to be an optimist and someone who looks for the good in the world, I also know that if you make it too easy or simple for outsiders to meddle with community governance, it becomes a governance security risk.

While I cannot cite an example of this happening to us, the open source “supply chain” is definitely under closer scrutiny than ever. Fedora is too large of a community for me, or anyone, to know every single person who contributes in a meaningful way. We need to evolve our governance model to better understand who our core community is. I believe this is a part of making us a more resilient community, ready to survive into this weird age of AI and beyond.

@jspaleta

Can we define what vouching requires?

Are you imagining something like an affirmation or oath? “I swear on my honor that I think Fedo Ra is an amazing and awesome contributor that helped us fix a bug in the Fedora Linux 42 Release Cycle to help us package thingamajit for the Yallah programming language SIG.”

@jspaleta

Hmm I don’t think we can get to accurately or even fairly.

The 12-month “security check” is about off-boarding someone as a verified member, when they have been inactive. Maybe you misread this one as eligibility criteria?

@luap99

I do however have done work that is not represented by these numbers.
I authored and implemented a Fedora “Change“ proposal for netavark

I feel like a FESCo-approved Change Request is something that should also be an immediate qualifier IMHO. Or should it be… a completed Fedora Change?

@luap99

I did a fair amount of work with the the Fedora QE team (well mainly Adam) to enable more podman tests as part of openQA runs to ensure podman works great and is not broken by other updates.

Is there nothing from openQA that emits onto fedora-messaging bus? Is this true @abompard & @adamwill?

@ekidney

There are others, but in my opinion 10 would be a good minimum so it’s encouraging community involvement but very much do-able.

Lately I have been feeling like ten badges is a fair enough baseline, if using Badges as a metric.

@ekidney

For the groups, one is enough in my opinion. Sometimes people only have one interest area. I also agree with early comments that if we use this as a metric, a standardised way of using the FAS groups needs to be established/enforced.

Maybe we could use FPCA+1 in conjunction with some other criteria, instead of arbitrarily inflating the number of groups. Plus, we do have a meta fedora-contributor FAS group that most FAS groups are inherited members. This means, adding anyone to one of these groups with that special dependency will automatically put you in this group. It also usually requires FPCA signed.

Maybe we could simply check whether the person is a member of the fedora-contributor group, on the basis of being in literally any other valid and not ancient FAS group.

@ekidney

There would need to be guidelines on when or why you should give someone a vouch. Is it for someone you have worked or are currently working with? Are you on the same team? Or do you only vaguely know this person.

I am thinking guidelines would be something absolutely necessary on how to give a vouch and when something is vouch-appropriate. I lean away from giving firm criteria, but instead giving flexible guidance to let an individual person assess whether a vouch is appropriate or not.

@ekidney

Could just be an automated email asking if they’d like their account to not be deactivated? Then it could be a reminder to get involved again

I like thais too… in the event that they do not choose to get involved again, it could have a 30-day expiration for the person to object to the expiration, or something like that.

[jflory7 (Justin Wheeler)]

@ryanlerch Hey, I got to thinking… if we launched a program like this, could making repositories in your own user namespace be a “benefit” for people who obtain this status? I am wondering if this is something even technically feasible or not.

Users circumventing new repo creation limitation

[py0xc3 (Chris)]

@jflory7

Could you provide an example or two of a team where this is the case? Other than Fedora Discussion staff, because that one just came up recently.

Actually, most I know. Jef mentioned himself in the earlier debate that he is still member of teams in which he has not been active for many years, and in all the time he was inactive he could have voted.

Beyond the Discussion case that includes ask-fedora (a FAS group dead for long that was not really linked to the Discourse Mod team for years, as the name suggests), I am considering to open a ticket to get rid of the security-team: it is still confusing people (as security sig != security team) although it is dead for I think over 10 years (?). Many people contained are no longer active in our security matters at all.

Beyond FAS groups that are dead at all, most I had to work with did only add users (if the FAS was in use at all), but do not purge (and most did adding based on very different criteria → some add just based on one contribution, others after a long proven record)

If I review the FAS groups I am member in, except the FAS groups created in the recent weeks, I think all were largely filled with dormant accounts or people who are no longer active in the group (mostly for years): Docs, Ambassadors, … . But again, I think that affects many if not most FAS groups: the FAS members are not representative for the actual members.

Concerning “who else”, the first I had in mind (due to recent interaction) and became curious about is anaconda: While I could find a FAS group that contains largely people I know to be current members (gitanaconda), the Product Owner is not contained at all Not sure if that group is actually intended to be used as normal FAS but maybe just something to get access to some git or so, leaving anaconda without an actual FAS group.

Skimming the FAS groups with atomic within the name, I could not find one that reflects the current contributors (in all groups, I miss people very active, but find some I do not know at all), and I am actually not sure if any FAS group I find is even intended to be the current team.

Concerning teams not using FAS at all: as mentioned, anaconda and *atomic* could fall into this category. But I’m sure when going through the teams we have, many more would be found, may it be with no FAS group at all, or one that is not representative if not orphaned Many teams don’t need it and thus have no incentive to create one: however, making it binding for voting, this issue might solve itself? Teams then have a stronger incentive to create an FAS group once they are “established” just to have a vote. But even if this would work out, it would not solve the “purge” issue.

@jflory7

I recall someone suggesting the idea of earning specific pathways of badges.

Not sure I understand But I primarily mean different pathways to eligibility, and badges being just one of them, and maybe additionally focus on badges with a value and/or that enforce a real contribution (e.g., avoid to make it attractive to send “blind” or “pseudo-tested” karma in bodhi to get voting rights)

@jflory7

I am hesitant to use a git commit as a useful metric for anything because I can make a tiny change in 43 git commits

I think that problem applies to many if not most contributions. As you said yourself above:

who spends a lot of time in our project community as a contributor knows something meaningful about Fedora, our project, and our community

I generally agree to your point, but I would then rather use a very high number of commits than not using git at all for two simple reasons:

1. I think someone who makes, e.g., 100 small successfull commits/year is likely to be involved and active somewhere (either someone gave them developer rights - FAS group membership issues not considered here - or someone keeps approving their PR/MR)
2. you risk here to exclude a noteworthy amount of our developers: many of them are likely to be contributing mostly by git commits, mailing list mails, and maybe some Matrix conversations, and some “non-git” packaging-related activities (though I would not presume all useful developers are packagers!!). It can have a hard impact if they loose voting right in FESCo, and we don’t know what that makes with their relation to FESCo. However, the group I just outlined would do a lot of git commits → thus, a high number might mitigate the concerns of mine and yours? Of course it’s again a compromise, not a perfect solution …

@jflory7

I feel like any package maintainer would/should immediately qualify for this.

After thinking about it, I think you are right, the potential issues with package management and “effectively-inactive” packagers should be tackled elsewhere and not considered in this.

[py0xc3 (Chris)]

An issue I just identified that might be considered: due to how we implement forge, it can occur that people become member in 3 FAS groups just to manage their team’s forge. That said, it might be a minor issue as that usually implies an impactful/deeply-established team and the person to be deeply involved (as being member of the owner group etc). So this might be considered, but it is not necessarily a problem but could be even interpreted as a desirable feature. However, “normal” members might still quickly end up in 2 FAS groups that represent one team.

[hricky (Hristo Marinov)]

@py0xc3

Skimming the FAS groups with atomic within the name, I could not find one that reflects the current contributors (in all groups, I miss people very active, but find some I do not know at all), and I am actually not sure if any FAS group I find is even intended to be the current team.

Concerning teams not using FAS at all: as mentioned, anaconda and atomic could fall into this category.

While some may be inactive, forge-atomic-desktops-members is active and used by the Fedora Atomic Desktops Forge org.

[smarnv (Stefan Marinov)]

@ekidney

I had a quick look at the badges to see what ones are easy to collect when you first sign up:

• logging in for the first time
• signing the FPCA
• setting your avatar
• setting your timezone
• adding GPG or SSH key to your FAS

I had already done all of them before but I didn’t have any of the badges (besides the middle one). Now I did an experiment and I was able to retrieve the last 2 by reapplying the same changes I already had on my FAS profile (undo, save, redo, save), but not the former 2. So relying on these as easy to obtain might not be a good idea.

In my opinion it would make more sense to explicitly exclude these and similar badges and count only badges related to some meaningful contributions, whatever the criteria for such contributions might be (if badges are used at all as a proxy to measure contributor activity).

[luap99 (Paul Holzinger)]

@jflory7

Is there nothing from openQA that emits onto fedora-messaging bus? Is this true @abompard & @adamwill?

The point I was trying to make is not openQA specific. My work there involved creating an issue and a few commits on the openQA repo which was on pagure.io and now on the new forge Making sure you're not a bot! I am not sure if such activity there is tracked by badges? The badges site shows there is supposed to be one for pagure activity yet I do not see such badge in my profile despite having a few commits merged there so I suppose something was not working there?

However my point was more about there will always be activity you cannot really monitor. For example the openQA tests do publish results on the bus and I do monitor the podman results there to notice if new podman test issues come in. That is “invisible“ work, at best I report a issue somewhere but often that will be upstream because well most things are upstream issues not Fedora specific (i.e. test flakes). I am an upstream maintainer so it is easier to handle these things upstream for me.

Regardless I guess this is not really important if the baseline numbers are low enough. As long as someone like Adam recognizes my work there I can ask for a vouch.

[ffmancera (Fernando F. Mancera)]

I guess I should chime in here as I did in the council hackfest thread.

While I cannot say much new, I must record my opinion. I think this will end up hurting ourselves as a community. Limiting participation without a relevant precedent does not make sense.

I thought the Fedora strategy 2028^[1] goal was “By the end of 2028, double the number of contributors active every week.”. This in my honest opinion goes in the opposite direction, it is not welcoming and it just gatekeeping people.

If you contributed a lot until Fedora 30 and for whatever reason stop, maybe an election gets you again in the loop. With the new approach - well, you cannot vote anymore so why do you even care about the elections? Why do you even care about what is going on in Fedora, anyway if you don’t like it you won’t be able to chime in!

In addition, all the arguments around this seems to be empty to me for mainly 2 reasons:

1. All are based on assumptions that the elections will be rigged by people out of the system.
2. This is mixing concepts. Above the xz utils situation was mentioned. Well, if the same approach to the xz utils would be taken on Fedora with the new system.. it would have succeeded! The attacked was a known name around the project not just a random person showing up. So how is that even related to this change?

Anyway, do we even have the tools to understand how will this impact the community engagement?

Finally I would like to share a personal experience not an argument^[2]. I joined Fedora for first time because I wanted to vote for someone. Then I discovered plenty of new things and ways to participate and people encouraged me to do it. If I would have found such gate keeping I would not have bothered to get started.

P.S: Sorry if something that I mentioned was already addressed on the discussion. I tried to read everything but could have overlook something.

---

1. Strategy 2028 Update – Fedora Community Blog

   ↩︎

2. An Anecdotal Fallacy occurs when someone relies on personal experiences or individual cases as evidence for a general claim, overlooking larger and more reliable data. ↩︎

[zbyszek (Zbigniew Jędrzejewski-Szmek)]

I read the full thread now, and there a lot of thoughtful comments.

I find @ffmancera’s comments particularly convincing.

How I see the current state:

• Inactive contributors coming back to vote in an election is not a problem at all. As far as we know, this doesn’t happen much, but even if it did happen, that’d be still be OK. In particular, that status is not relevant to security. (This is different then e.g. package maintenance where we have established account expiry.)
• People creating an account just to vote currently also doesn’t seem to be a problem currently, because of the FAS+1 group rule, which creates a non-trivial barrier. Mindshare elections have looser requirements, but even there outsiders coming in to vote doesn’t seem to be an issue.
• Packagers are well covered by the existing rules, but some other areas of contribution, like Docs, QA, User help, Design, etc, might not correspond to any groups and not be covered. We should provide a path for all those contributors to be recognized and fully participate in elections.

So:

• I don’t see people who stopped being active participating in elections as a problem. I think we should scrap the whole plan to expire the status.
• We have the problem that too few people vote, so any changes we make should make it easier to vote, not harder.
• I also believe that people who are active in one area of the project should get the privilege to vote for other teams too, as we are currently doing. So e.g. if somebody is recognized for being a QA contributor, they should vote for FESCo and Council and whatnot. In practice things are loosely defined and contributions overlap. And also, see previous point about needing more votes, not fewer.
• We should make it easier to recognize non-packaging contributors.

To recognize non-packaging contributions and contributors, I think we should decentralize and allow Working Groups and other “subdivisions” to create their own rules to recognize their contributors. A group would draft a set of rules and ask the Council to approve it. And then a person who wants to have voting rights would participate in the process through the area where they are the most active. Once they are approved once through this process, they’d remain part of the voting group forever.

So, for example, the group of people who are doing QA might agree that they expect — hypothetically — 300 karma votes and reporting in TestDay results 28 times in the last year. Ideally, this would be measured automatically through a periodic script. Otherwise, the group would need to establish a process how a contributor can ask to be officially recognized, either through a ticket system or maybe even by asking in some special channel.

Ideally, anyone who is recognized would automatically get a badge. This way people would get a notification that they can participate in elections.