Require new ontologies include a link to contribution guidelines

[cthoyt]

Closes #1836

Given the OBO Foundry Principle 10 (Commitment to Collaboration), ontologies should actively lower the bar and encourage participation from the community. For different ontologies, this ranges from participation in community discussion on slack (e.g., UBERON has their own slack workspace), attendance in project-specific meetings (e.g., RO does this), making issues (all ontologies are REQUIRED to have a public issue tracker), to reviewing PRs (IMO all ontologies should be required to consider external contributions, but some reject them without consideration).

Having a CONTRIBUTING.md in an ontology's repository that is further in a place that GitHub can recognize it is crucial for enabling community participation since it outlines the expectations for the contributors and the maintainers.

As of INCATools/ontology-development-kit#620, the ODK now has a basic contribution guidelines file built-in, so all of the original blockers towards the issue #1836 that proposed we require contribution guidelines for all new ontologies are now gone.

This PR specifically does the following:

1. Adds a field to the new ontology form to make explicit the URL to the contribution guidelines in the repository
2. Implements (as a follow-up to Add automated license correspondence check #2277) a check that is only applied to new ontologies that going forwards they will be required to have contribution guidelines before being accepted into OBO Foundry

[matentzn]

@cthoyt you say:

Would be nice to finish #1841 before admitting new ontologies

I think its good to get the contributing.md requirement in for new ontologies. I will make sure this happens. But before we do, we need a really good blueprint - I will work in the next weeks (ODK), but it will be slow. After the blueprint is done, we will share it as an example.

If we require this contributing.md on ontologies that are already admitted, this will be a never ending process. I think this should be firmly in the "SHOULD" space, and I am also happy to add a warning to the OBO Dashboard in the "collaboration" principle. But an ERROR it wont be, at least not if you ever want this merged.

[cthoyt]

As a way to get around the issue of applying new, higher standards to old ontologies (many of which are still called "active" but will not be able/willing to make improvements), I've proposed we start tracking date of admission of ontologies in #1967 such that all new SOPs can be tagged with the date when they go in effect, and only ontologies submitted after that MUST and before that SHOULD follow them.

[matentzn]

Ahhhh now I get it! Ok, all in then! I like that!

[cthoyt]

This issue is now unblocked:

• New contribution guide INCATools/ontology-development-kit#620 added base contribution guidelines to ODK that can be reused in new ontologies
• Add automated license correspondence check #2277 made it possible to add new metadata checks that only apply to new ontologies. It was a valid concern in Require new ontologies' repositories to include documentation on how to contribute #1836 that it would not be possible to retroactively get existing OBO Foundry ontologies to make contribution guidelines. This concern is now less applicable.
• Previous references to Add github_date_added field to ontology metadata #1969 have therefore been removed as they would only be a distraction

@matentzn @nlharris you know my style, I like to bring solutions to OBO Foundry community then ask people to discuss rather than having slow moving discussions that never go anywhere first. Can you help re-orient the solution in this PR and the original discussion in #1836? What kind of discussion do we need to have to start enforcing new ontologies (but again, not existing ones) in OBO Foundry conform to a higher standard?

[nlharris]

What kind of discussion do we need to have to start enforcing new ontologies (but again, not existing ones) in OBO Foundry conform to a higher standard?

See #2209 (Should we make passing the dashboard mandatory by January 2025?) (to which the agreement was "yes").
(BTW, I dislike Discussions because it's a separate place that we (including me) mostly forget to check. I think it's fine to use some Issues as discussions.)

[cthoyt]

(BTW, I dislike Discussions because it's a separate place that we (including me) mostly forget to check. I think it's fine to use some Issues as discussions.)

@nlharris It seems that going forward, ontologies should pass OBO Dashboard. However, we should be able to make other quality tests that are not implemented there. Unfortunately, it's the case that OBO Dashboard is not so accessible for contribution, so I'm not going to put any of my effort there.

More importantly, we should do this in a way that we can add new checks without imposing them on already-accepted ontologies. There's way too much grumbling when we start talking about community-wide improvements because people are lacking time/funding/motivation.

[nlharris]

Hey, I'm just the messenger.

And I'm not sure why you quoted my grumble about Discussions (by which I specifically meant GitHub Discussions, not lowercase-d discussions!).

[cthoyt]

@nlharris oop no somehow I quoted wrong! I wasn't talking about your grumbling!

just let me know if you have any ideas where to bring that up :)

[erik-whiting]

I have two questions about these requests to the GitHub API. GitHub rate-limits requests to the API to 60 an hour if you're not using a token, see this section of an API article: https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limits-for-requests-from-github-actions
My questions:

1. Are we nearing that threshold? If so, someone with admin access to the repo needs to put a GitHub token in the CI secrets so we can reference it in the test file. If we're nowhere near 60 then never mind me. But yeah, if we hit that threshold in the middle of an ontology validation, it's possible someone could get their contribution wrongly rejected. We would have to wait for the API counter to reset to try again.
2. If we are nearing that threshold, has someone already addressed this issue? I don't have access to the repo secrets so idk. Again, this might not even be an issue, in which case don't mind me.

[cthoyt]

@erik-whiting since this will only run API calls on branches that have a new ontology, it will at most make 1 API call. I'd consider this negligible, and no follow-up action is required.

[erik-whiting]

lgtm