Groups, FPCA and CLA+1

Project Discussion
1

Hey folks!

With IPA we can require users to have “signed” the FPCA before entering a group, but it’s a per-group thing that we need to specify when creating new groups.
Another thing that must be done “manually” is whether the new group counts for giving the “CLA+1” or “Contributor” status. This status is used elsewhere, for example only “contributors/CLA+1” users get an email alias.

This was not explained in the docs, which is probably my bad since it should have been done by my/our team when writing Noggin.

When migrating, groups were created as requiring the FPCA and as granting the Contributor status, but since then new groups have been created and they don’t all have those two properties.

I can write a script to correct all that, and I can also write a toddler to make sure it doesn’t happen again (or someone else can! hint hint hint), but first I’d need to know if there are groups that either:

  • don’t require their users to have signed the FPCA
  • or don’t grant the Contributor status

I’m thinking of groups like COPR-related groups, service groups, etc. Does anything come to mind?

2

Will current users who are in the groups but haven’t signed the FPCA be grandfathered in or will they be kicked out of the groups?

3

Let me know if I’m thinking about this wrong, but when somebody creates an FAS account, they sign the FPCA right after creating their password. There shouldn’t really be accounts in groups that don’t have the FPCA signed.

4

I don’t know how the system works, but I just checked the websites-apps-cms group and it has the following members who have not signed the FPCA.

0xsaksham
2tanu6
akhilsharma
alisiphone
codigomaye
dlopez
grenjikxd
juan8a23
nicole
osayami
qincai
xanmoy

It’s perhaps off-topic for this thread, but I do see a lot of people requesting to be added to that group who do not seem to follow up with contributions to the website’s content management system. If they are having difficulty figuring it out, they haven’t been asking in Matrix or elsewhere that I am aware of. It’s possible that people are abusing the system there and requesting access for some other reason than to contribute to the website. Should we clean up that group by removing anyone who has not made any commits to the CMS? Maybe I should be making it more difficult to be added to that group?

5

So, historically, we specifically did not require cla_done for
pagure.io, because mostly we wanted it to be like fedorahosted.org
(our trac based source forge from before pagure.io). fedorahosted
actually used fas groups to control acccess to everything, so every
project had it’s own group, etc. pagure.io had seperate groups, so this
largely didn’t matter.

Also, we didn’t want to have copr projects require it, since those were
seperate open source projects that are managed by those groups.

I don’t think we need to worry about the Making sure you're not a bot! fedorahosted
case moving forward. We could identify the groups from fedorahosted days
because they are named ‘$SCMwhatever’ so… like ‘gitabrt’ for the abrt
project, ‘svnhardlink’ for hardlink project, etc. So, for all those
git*, svn*, bzr*, cvs*, hg* we should just… leave them alone.

copr groups are more a problem, they could be most anything. ;(
I guess we could query copr for what ones are in use?
But perhaps the council thread about membership and contributors and
voting will decide that these should just be contributors too?
I think what we do here depends on what they want to do.

6

Well, it’s up to you. I am not sure what that group even grants. :slight_smile:
This all might be from a while back when there was a websites and apps
revamp project with a lot of people working on it?