I think that's how it works when SSO is enabled : people are supposed to be already authenticated through SSO (and so gitlab account tied to their SSO identity)
Looking at this, on pagure one needed absolutely to have FAS account to just open a PR
I guess investigation is needed to ensure people willing to contribute can, but also would have to link to a FAS account too (for audit/tracking purposes)
Never looked at Gitlab doc for auth but if you have pointers about how to do that that would be good

I think the bigger issue was not being able to file issues.

@ngompa well, I hope that's something the Board took into consideration before publicly deciding to go to gitlab.com :)
Status quo about what we had before (a need for a FAS account to create issue) .. haven't looked at gitlab doc (yet)

So I went and did some poking around, and here's what I came up with:

Firstly, we can't remove the need for an SSO-backed account to interact with the repos without removing SSO entirely. It's also what Fedora will be doing with Forgejo, as I understand it, and consistency seems good, so I think you're stuck with that.

For the "new users can't log issues" part, that can be fixed - currently we default newly-created SSO users to the "Minimal" role (as per GitLab's blog) but a role of "Guest" is needed to interact with issues.

The catch is that is only changeable at the root CentOS level, not for individual groups. So we either (a) do that for the whole group, but I'm not sure of potential consequences, or (b) we find some way to create an auto "everyone-included" FAS group that we can use per-group on the GitLab side to allow all accounts to have Guest access

we find some way to create an auto "everyone-included" FAS group that we can use per-group on the GitLab side to allow all accounts to have Guest access

I think this would be a good idea since then we can hopefully minimize spam ticket creation. I know for wiki edits and such we do FPCA+1, and maybe that's the way we should go here too.

@eslobodo Do you have thoughts on this?

I have to admit that I might be misunderstanding something here, but what exactly is not working on gitlab.com/CentOS? The Kmods SIG moved all its resources from git.centos.org to gitlab.com/CentOS/kmods in July 2022. Issues like the ones described here have not occurred so far. There was no additional step required to allow users/contributors who are not members of the Kmods SIG to submit issues and create merge requests. However, I cannot determine whether these users authenticated through SSO, i.e., determine if one must have a FAS account.

Basically, I just wanted to say: If you're considering changing something for the entire gitlab.com/CentOS group, please discuss it with other users beforehand so as not to disrupt their workflows. Other SIGs, such as Automotive and Kmods, have been using gitlab.com/CentOS for quite some time.

@pjgeorg : I think that this ticket should become a thread on devel list, so that all SIGs can participate and it would give visibility to the thread.
If you can confirm that non FAS users (so just people with a gitlab.com account, nothing else) were able to open issues and/or create MRs, wondering what's going on for Hyperscale ..

@ngompa : can you start a public thread on devel list please ?

If you can confirm that non FAS users (so just people with a gitlab.com account, nothing else) were able to open issues and/or create MRs, wondering what's going on for Hyperscale ..

Created a new GitLab account using an e-mail address not known to FAS.

Issue created by a non FAS user: https://gitlab.com/CentOS/kmods/sig/-/issues/8
Merge Request created by a non FAS user: https://gitlab.com/CentOS/kmods/docs/-/merge_requests/4

Note: CI is not working for the Merge Request as GitLab requires new users to verify their identity before they are allowed to run CI jobs. I did not verify this test account.

@pjgeorg : great, thanks for confirming ..
Let's wait on @ngompa to explain then the underlying issue in details

This was definitely an issue for the Hyperscale SIG, both back when we first evaluated GitLab two years ago and recently where someone reported to @dcavalca that they couldn't interact with our projects at all until I added them directly.

@dcavalca : would you mind elaborating about the tech issue you had ? as @pjgeorg confirmed that for Kmods SIG it seems to be working and external gitlab accounts (not tied to FAS/ACO) were able to open tickets and MRs ..

no feedback received, closing but feel free to reopen with details if/when needed