let’s not be too hasty. Is there a way I can look at that 7 day log just so I can understand what it captures and see if that maps to a reasonable record of contribution (for my own needs to message something about contribution) and then we can maybe talk about whether that derived record of contribution makes sense as a proxy for voting eligibility. Let’s not assume at the outset that you need to change anything about log retention patterns, what we are talking about here might be a daily or hourly log processor script.
im not sure if thats any more useful than the fas group proxy as it exists right now.
This topic was the centerpiece of a significant debate during the January 14th meeting regarding the tension between inclusivity and the potential for gaming FESCo elections via temporary memberships. We discussed the difficulty of defining “active contributors” and noted that “legacy” voting rights for inactive members are just as problematic as new temporary ones. The Council determined this topic is too complex to resolve in a single meeting and requires detailed asynchronous discussion here on Fedora Discussion rather than waiting for the 2026 Strategy Summit.
I found it a bit pity, that from such a incident has been made such a big thing.
There have been other moments we talked about the app. I even did send a pull request to change the expression CLA to FPCA. Till today the request is open.
A reason that this is still not implemented could be, that we do have to many versions around of this app. I made the request on pagure.io
Next steps which could help to start to solve the issue is, bringing the app to the forge and actualize it as far as we can and make tests. I got stuck pulling the container image and make local tests.
need of some hints which is the actual git repository to use
help to actualize the instructions how to build the environment to debug the app.
Last time I tested i got some issues with the instructions installing Vagrant. Maybe we could share a virtual image or Container so we do have all the same infrastructure to test?
A user on Ask-Fedora did send me the screenshot while asking how to participate the elections. The request was in Portuguese and I could not help as I am aware of the “contribution” discussion ↩︎
Please do not forget, I am from the generation which installed a OS from a Floppy disk. Of course I brought my knowledge as far as possible up to date. However I do learning by doing and very happy when someone cares about a working development environment without bricking the working installation. ↩︎
I think you are mixing up two things, the voting environment on one hand, and different perceptions about how we have to act within this environment on the other hand. However, I think there is a good chance that both issues can be resolved with the same means as the Council seems motivated to put forward something before another such election comes up. However, I think the issues cannot be resolved only by PR, as they go beyond the app Before implementing anything, we should wait for clarification about what to implement.
It was said to not rush as there is plenty of time for the F44 elections. Well, the F44 elections are there, and while there is a potential long term development (not to be discussed here), there is no guidance about how to moderate and act in the elections that start soon:
is it, at least as interim decision for the upcoming election, allowed to allocate temporary SIG memberships based on personal determinations in order to enable users to vote or not?
I don’t exclude I missed something as there had been many discussions in many directions in many channels, and while most are still open, maybe one of them contains an interim decision? (my own contributions were quite focused recently ^^)
I think it would make sense to document something like “group memberships must not be granted if the sole purpose of membership would be to be able to participate in an election” … might need a bit more wordsmithing though (and I might not think of some cases right now).
Because the Council has chosen to not provide any provision or guidance in this matter but still leaves it to the community, the remaining authority to tailor to, or to derive from, is FESCo. The few FESCo members, who have added their opinion+preference about this matter (3), have all preferred that temporary memberships shall not be used for this purpose, 2 in general and 1 at least until there is a Council-approved formal policy that regulates it.
Since this is the closest we have to a guidance/provision, I will enforce the rules this way in the channels I am a moderator in for the time being.
(supplement: this is a solely passive measure to create a predictable experience that otherwise would end up unpredictable and to mitigate foreseeable conflicts! I THINK there is a consensus with Join SIG to not use any means that are in question in this issue → in that case, my post here leads to no action as well. So this is only to avoid one side ends up as the sole beneficiary, both in polls and in absence of guidance, and then having another conflict in which both sides couldn’t predict the other [just to avoid misunderstandings that seem to have come up in another channel about this])
Point of information. Is there any existing documentation that attempts to set forth the cultural norms and behavioral expectations on the role of FAS group sponsor?
To my knowledge, this is something informal for most groups. The only one I am aware of that has documentation for sponsorship prerequisites, sponsor responsibilities, and sponsorship revocation is the “packager” group: https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/
Indeed, the only rule I am aware of explicitly to FAS sponsors is that Join SIG is allowed to do temporary memberships, which was formalized to allow wiki edits (wiki edits = FAS group membership limitation due to earlier vandalism afaik). One could derive from this that others correspondingly ain’t allowed temp. memberships. Beyond, its the CoC, trust, good faith and in some cases maybe best practices/least privileges. The assumption to only add people that add to the value/purpose of the SIG is not formalized either.
One can derive a few things from the definition of the groups though: “The tracking groups are primarily meant to indicate that people are contributors in a certain part of the Fedora Project.” [1], but that’s not a Council document afaik, so again nothing binding in such respects.
No, neither case can be “derived”, or both can—that no one else is allowed, or that everyone is.
There are no current restrictions/rules on groups allowing temporary memberships. Sponsors can already do this if they wish.
Since the most common use case was access to infra (wiki/fedorapeople), infra started to do it to be a single point of contact. When the Join SIG’s process was put in place, we took it over from infra, since helping out community members with this sort of thing fell more under onboarding under infra tasks. When it was being done by other groups, it wasn’t even necessarily temporary—people sponsored other community members that they trusted to enable them to contribute (as we correctly should). Since the Join SIG works with newcomers, we came up with a system to make it temporary to help people onboard until they were sponsored to a team/group. Requests are rarely made and not always accepted.
To some extend, this is sort of my point One could say… but not really… effectively, there is nothing regulated for sure, except that explicitly Join SIG is allowed temp. memberships. Everything else… can derive… or not… interpretation possible…
… with this being already a derivation. If Join SIG is explicitly allowed, doesn’t that imply that others ain’t? What else would this rule be for? Interpretations possible: as you say, there is no rule that says explictily others are not allowed to
I do understand and respect your opinion. But don’t forget this is a matter of perception too, not a fact, and it has implications with everything being a type of compromise. This is part of the debate. Adding that your opinion is the correct one does not help to reach a consensus or compromise. That said, my own posts in this debate might also could have “honored” this in more effective ways.
No: if A is “yes”, it doesn’t not mean everything other than A is “no”. It really only means that A is “yes”. We can’t make any statements about things other than A.
I’m sorry Chris, I do not understand the point this paragraph is making. If we are debating, we must present our opinions. I cannot see where I’ve written that my opinion is the correct one in my reply. I have pointed out that the derivation you make is not correct, and further tried to clarify that at the starting of this reply.
This is also not really the case. every sponsor can do it. The Join SIG simply tried to simplify it for others. We said “we help newcomers, so how about we take this on—everyone that may need access but isn’t part of a group can come speak to us and we’ll see how we can help”. It does not mean we accept every request—we point people to other ways of gaining group membership, like pointing them to other teams. Only in exceptional cases do we give temporary membership. I remain unhappy with this being referred to as “abuse” and “bypassing of rules”. Nothing of the sort was done.
There’s no “allowing”—no sponsor needs permissions to do this. When they become sponsors, we trust them to use their powers correctly.
I think we end up in repeating the same debates and points that had been already made. I guess it makes sense to leave it to the Council to read what already is documented, and respond only to their questions to best of our knowledge.
I don’t think the implication stands.
From what I can tell fas groups are individually self-governing, with most fas groups not having any documented policy about membership. It seems to be very rare, out of the 1688 fas groups defined there are maybe a handful that have documented policy inside fedora docs or the wiki for expressing membership intent or policy about how members are added. Even fewer have documented policy for how members are removed.
As a mechanism, fas groups kinda have to be self-governing because fas groups are used for a variety of reasons. fas groups are an implementation detail that get mapped to things like access control in various bits of infrastructure.
Some fas groups are group access mechanisms for copr repositories. It’s difficult to see it being appropriate to restrict copr group sponsors from making self-governing membership choices because as a governance choice, we’ve tied abstract fas group membership to voting rights.
Some fas groups are organizational for projects in the ecosystem that are derived from Fedora. It’s difficult to see it being appropriate to restrict the sponsors of those groups from making self-governing membership choices because as a governance choice, we’ve tied abstract fas group membership to voting rights.
Right now there are several centos related groups in fas, at least one of them has like 200+ members. Fedora Council has no real authority to dictate to Centos governance how the membership of those groups must be managed. The projects share some infrastructure but not governance. And looking forward. I fully expect fas may have organizational groups around other downstreams, like Azure, depending on how Fedora grows in importance as an upstream project to them as well. There are many downstream efforts, they could all organize via fas groups.. and the membership policy of those groups will not be something Fedora governance gets to decide on.
If you want to talk about membership policy of fas groups associated with Fedora SIGs as a subset of fas groups. That’s germane. Currently SIG oversight is documented as being under the authority of FESCo. I’m going to take my FPL hat off and make a purely personal opinion statement now. I think SIG oversight needs to be put back into the hands of Council as a governance function. I think FESCo has more than enough work with technical advisory issues and the expectation that FESCo also has the capacity for SIG oversight that reads on things like minimum expectations on membership handling is asking too much from that group. But retooling what SIG oversight means is a much larger discussion, it may actually mean putting a modicum of structure on Fedora SIGs and asking sponsors to do certain things as part of SIG health statusing so we can better understand which SIGs are healthy “groups” But whatever we do with regard to SIG oversight, doesn’t translate to CentOS SIG oversight, because again.. shared infrastructure…but not shared governance.
I do understand this opinion. But I would add (opinion too) that FESCo should be heard about if they have enough work, or if that is something they would want to keep and prioritize compared to other things, given that this can massively impact them.
Right now SIG oversight seem to be pretty much a laissez faire endeavor at the moment.
I don’t even think we have an agreed on understanding of what SIGs are. Maybe what some of the load bearing work that is currently being done as part of a SIG, which seems to be intended to be informal groups, really isn’t actually work a SIG should be doing. Maybe we map too much into the organization bucket that is a SIG and really some of that work has become project ciritical and it should be a formal group.. a team. The packager SIG is clearly a formal group, not an informal one.
But beyond definitional boundaries of what a SIG is and is not… what I think is actually impactful is commit access in certain contexts.
There are some SIGs with certain commit access and yes those have project wide impact. But then there are other SIGs that don’t have commit authority in any way. 2 or 3 people just decide to make a SIG.
So what I see is that commit access in some specific contexts has impact. but commit access is orthogonal to whether you call the organizational structure a team or a sig or whatever you want to call it.
We actually need to figure out how to surface the commit access mappings that exist so we can categorize more coherently. What commit access are we doing inside of “SIGs” and what are we doing inside of “teams” and what are we doing outside of both?
Commit access in specific contexts is the thing that has project wide technical impact. FESCo should have oversight in some commit contexts imho. But commit access does not imply a SIG or vice versa.
Here’s how things evolve from informal group to something impactful…
A SIG forms up, gets space to self-organize itself…maybe it has commit access to a copr as part of its initial work. i don’t see how that impacts FESCo. If the SIG members are also packaging group members the commit access impact flows from the packaging group membership and the more formalized structure associated with the group. its only when certain commit access is conferred to the new SIG membership that the SIG becomes projectwide impactful. And at that point… shouln’t it really need to be more formal and be a “team” because its blast radius as a group is big enough to role into scope for FESCo?
Before implementing anything, we should wait for clarification about what to implement.