review Rocky Open Source Contributor Agreement (ROSCA) and ensure it aligns with our vision #8

New Issue

neil · 2024-09-04T02:22:09Z

neil commented

2024-09-04 02:22:09 +00:00

060bb84b40/docs/contributing/git.md

Notably, this agreement currently precludes anyone from contributing from a company device, regardless of whether they are permitted to do the work or not.

I would recommend we consider replacing this agrement and the Rocky CLA with a Developer Certificate of Origin, like the Linux Kernel.

(i.e., replace both the Git agreement and https://wiki.rockylinux.org/contributing/rosca/ with a DCO)

https://github.com/neil-forks/wiki.rockylinux.org/blob/060bb84b403bfc00d3e701621c3a494118273f8e/docs/contributing/git.md Notably, this agreement currently precludes anyone from contributing from a company device, regardless of whether they are permitted to do the work or not. I would recommend we consider replacing this agrement and the Rocky CLA with a Developer Certificate of Origin, like the Linux Kernel. (i.e., replace both the Git agreement and https://wiki.rockylinux.org/contributing/rosca/ with a DCO)

👍 2

label commented

2024-09-04 04:27:52 +00:00

Summary: I am with Neil here that we should review/replace the current state of our agreements. Our project has grown and matured enough that it's time to be less restrictive on potential contributors.

Context on the "Git Agreement"

When we originally made the agreement, the point was to make it clear who and how one can use our git forges and to make signing it a path way to gain access to them. During its existence, it was modified to account for git.resf.org, which there is less restrictions on access and usage. With that said, I believe it has several flaws that warrants it being replaced while not negatively impacting our current services that rely on the signing of it.

So everyone understands/remembers the reason for its creation, it came down to this:

Expectations - Such as usage, moderation, and what's considered "bad" conduct
The differences between the two forges - git.rockylinux.org requires licenses and is further restricted as a result.[1] Signing this agreement in Rocky Account Services gives access to git.resf.org immediately, which is for the RESF as a whole.
Reiterate that it's not a bug tracker for Rocky Linux[3]

My Thoughts: Non-technical

In my opinion, the git agreement itself has flaws and is highly restrictive for absolutely no gain whatsoever. As the project has evolved and continues to mature as well as more tech companies/entities wanting to contribute and participate in this project, we need to make it very evident (and easy) that contributions are welcome. The way the git agreement stands now, it does not make it easy to do so and could very likely put off a lot of potential contributors to our project. It may be likely that it has already. Let's use Neil's example of contributing from a company device. The way it is now, it [the agreement] makes it near impossible for someone from a company tasked to work on open source or contribute have difficulty in doing that for our project.

ROSCA (or our CLA, otherwise known as Rocky Open Source Contributor Agreement), also contains language that may be off-putting to some contributors. Reading it again and putting myself on the outside, it reads "too legal" and feels as though there are artificial barriers created as a result. Myself personally, if I saw it for the first time, I'd have questions as to the necessity of signing it. If I instead read a DCO, my impression would be that the project is friendly, that it is easy to sign up, and it's possible to make short or long-term contributions to the project without feeling there are many hurdles to jump over.

A DCO would be better suited for both the git agreement and ROSCA. A DCO can be seen as a way to bring down artificial barriers for the project and potentially drive more interest toward the project and potentially our backing foundation. We are at a place as a project that both agreements should be removed from our wiki and Rocky Account Services replaced with the DCO.

My Thoughts: Technical

Removal of the agreements from Rocky Account Services can negatively impact our git forges, as it pertains to abuse. In my opinion, in the event we go with a DCO, it should be in Rocky Account Services and signing it gives access to this forge. If not, perhaps a thoroughly reduced version of the git agreement referencing the DCO and potentially pointing to a policy or statements that alludes to what is and is not good for our git forges (see general guidelines point 1, revocation of access points 1 and 3 [4][5]).

Making our git forges not rely on signing of an agreement can (and will) lead to abuse.[2] While manual intervention should not be required and most of us don't want to deal with that[1], auto-magic login abilities should also not be expected.

Bottom Line

Our project has matured enough that it's time to be more flexible and more open on how we allow users to join our project and be part of it.

I agree with Neil's recommendation of replacing the git agreement and ROSCA with a DCO instead, keeping in mind the technical notes outlined in my footnotes below.

footnotes

[1] We have a license from gitlab to ensure we can use specific features of gitlab. The free tier poses some difficulties, thus why we have a license. As a result of "seating" that GitLab employs, this requires us to manually add people to gitusers so we don't go over our limit.

[2] It should be noted that when we didn't have the agreement "guarding" access to this git forge, we got spammed relentlessly and it required a few hours of cleanup each time. The moment we locked down to signing the agreement and ensured OpenIDC was on the same page, the spam stopped. I want to make it clear that I do not want any of our resources used as a free spam vector again.

[3] In hindsight, I'm not sure why we kept this part. In the past, people wanted access to git to file bug reports... Our wiki, website, forums resources all make it clear where to go to report bugs, so this is completely unnecessary now.

[4] In the past we were concerned about "trophy" accounts and that trivial PR's will just be denied. We had this issue on our GitHub org in the past and users were trying to do the same thing in git.rockylinux.org during the project's infancy. Reading it back, this can be taken the wrong way. Since git.resf.org is more open and we're continuing to grow as a project in general, this is less of a concern and will be at the discretion of the maintainers of their given repositories on which PR's will be reviewed and accepted or declined.

[5] In the past, we were concerned about "personal repositories". I don't have any deep concerns with it, after being with this project for three years. I think it's implied that personal repositories are discouraged, but at the end of the day I don't think it makes a whole lot of sense to really mention it or be heavy handed about it. I personally think it will come down to the discretion of the maintainers of the git forges (i.e., myself and the rest of infrastructure). Allowing us to be a bit more "relaxed" in this regard (keeping in mind footnote 2) would benefit the RESF because it could lead way to new projects for the foundation. In my opinion, this is a win-win.

Edit 9/3/2024: notes about ROSCA

Summary: I am with Neil here that we should review/replace the current state of our agreements. Our project has grown and matured enough that it's time to be less restrictive on potential contributors. #### Context on the "Git Agreement" When we originally made the agreement, the point was to make it clear who and how one can use our git forges and to make signing it a path way to gain access to them. During its existence, it was modified to account for git.resf.org, which there is less restrictions on access and usage. With that said, I believe it has several flaws that warrants it being replaced while not negatively impacting our current services that rely on the signing of it. So everyone understands/remembers the reason for its creation, it came down to this: 1) Expectations - Such as usage, moderation, and what's considered "bad" conduct 2) The differences between the two forges - git.rockylinux.org requires licenses and is further restricted as a result.[1] Signing this agreement in Rocky Account Services gives access to git.resf.org immediately, which is for the RESF as a whole. 3) Reiterate that it's not a bug tracker for Rocky Linux[3] #### My Thoughts: Non-technical In my opinion, the git agreement itself has flaws and is highly restrictive for absolutely no gain whatsoever. As the project has evolved and continues to mature as well as more tech companies/entities wanting to contribute and participate in this project, we need to make it very evident (*and* easy) that contributions are welcome. The way the git agreement stands now, it does not make it easy to do so and could very likely put off a lot of potential contributors to our project. It may be likely that it has already. Let's use Neil's example of contributing from a company device. The way it is now, it [the agreement] makes it near impossible for someone from a company tasked to work on open source or contribute have difficulty in doing that for our project. ROSCA (or our CLA, otherwise known as Rocky Open Source Contributor Agreement), also contains language that may be off-putting to some contributors. Reading it again and putting myself on the outside, it reads "too legal" and feels as though there are artificial barriers created as a result. Myself personally, if I saw it for the first time, I'd have questions as to the necessity of signing it. If I instead read a DCO, my impression would be that the project is friendly, that it is easy to sign up, and it's possible to make short or long-term contributions to the project without feeling there are many hurdles to jump over. A DCO would be better suited for both the git agreement and ROSCA. A DCO can be seen as a way to bring down artificial barriers for the project and potentially drive more interest toward the project and potentially our backing foundation. We are at a place as a project that both agreements should be removed from our wiki and Rocky Account Services replaced with the DCO. #### My Thoughts: Technical Removal of the agreements from Rocky Account Services can negatively impact our git forges, as it pertains to abuse. In my opinion, in the event we go with a DCO, it should be in Rocky Account Services and signing it gives access to this forge. If not, perhaps a thoroughly reduced version of the git agreement referencing the DCO and potentially pointing to a policy or statements that alludes to what is and is not good for our git forges (see general guidelines point 1, revocation of access points 1 and 3 [4][5]). Making our git forges not rely on signing of an agreement can (and will) lead to abuse.[2] While manual intervention should not be required and most of us don't want to deal with that[1], auto-magic login abilities should also not be expected. #### Bottom Line Our project has matured enough that it's time to be more flexible and more open on how we allow users to join our project and be part of it. I agree with Neil's recommendation of replacing the git agreement and ROSCA with a DCO instead, keeping in mind the technical notes outlined in my footnotes below. #### footnotes **[1]** We have a license from gitlab to ensure we can use specific features of gitlab. The free tier poses some difficulties, thus why we have a license. As a result of "seating" that GitLab employs, this requires us to manually add people to gitusers so we don't go over our limit. **[2]** It should be noted that when we didn't have the agreement "guarding" access to this git forge, we got spammed relentlessly and it required a few hours of cleanup each time. The moment we locked down to signing the agreement *and* ensured OpenIDC was on the same page, the spam stopped. I want to make it clear that I *do not* want any of our resources used as a free spam vector again. **[3]** In hindsight, I'm not sure why we kept this part. In the past, people wanted access to git to file bug reports... Our wiki, website, forums resources all make it clear where to go to report bugs, so this is completely unnecessary now. **[4]** In the past we were concerned about "trophy" accounts and that trivial PR's will just be denied. We had this issue on our GitHub org in the past and users were trying to do the same thing in git.rockylinux.org during the project's infancy. Reading it back, this can be taken the wrong way. Since git.resf.org is more open and we're continuing to grow as a project in general, this is less of a concern and will be at the discretion of the maintainers of their given repositories on which PR's will be reviewed and accepted or declined. **[5]** In the past, we were concerned about "personal repositories". I don't have any deep concerns with it, after being with this project for three years. I think it's implied that personal repositories are discouraged, but at the end of the day I don't think it makes a whole lot of sense to really mention it or be heavy handed about it. I personally think it will come down to the discretion of the maintainers of the git forges (i.e., myself and the rest of infrastructure). Allowing us to be a bit more "relaxed" in this regard (keeping in mind footnote 2) would benefit the RESF because it could lead way to new projects for the foundation. In my opinion, this is a win-win. ----- Edit 9/3/2024: notes about ROSCA

Sign in to join this conversation.