Add contributing link to new ontology form

[cthoyt]

This is one of the follow-up items to #1836, so review of this PR should wait until there's a decision on that one

Blocked by #1969

[matentzn]

@cthoyt you say:

Would be nice to finish https://github.com/OBOFoundry/OBOFoundry.github.io/pull/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]

After #1969, it will be more simple to say that all ontologies added after some YYYY-MM-DD have to conform to new rules and review of this PR will be easier.

[cthoyt]

This issue is now unblocked:

• https://github.com/INCATools/ontology-development-kit/pull/620 added base contribution guidelines to ODK that can be reused in new ontologies
• https://github.com/OBOFoundry/OBOFoundry.github.io/pull/2277 made it possible to add new metadata checks that only apply to new ontologies. It was a valid concern in https://github.com/OBOFoundry/OBOFoundry.github.io/issues/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 #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 https://github.com/OBOFoundry/OBOFoundry.github.io/issues/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 https://github.com/OBOFoundry/OBOFoundry.github.io/discussions/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.