nasa-pds / .github Goto Github PK

💪 Motivation

See this issue for context; apparently some reviewer of JOSS thinks our contributor guidelines are too strict when it comes to pull-requests that contain cosmetic changes only. This person believes that PEP8 changes should be allowed even though they are cosmetic.

⚖️ Acceptance Criteria

Given a pull-request that has cosmetic-only changes but are actually PEP8 changes
When I perform a merge
Then I expect the merge to be allowed and not rejected based on new contributor guidelines that contains such verbiage.

⚙️ Engineering Details

I personally think a reviewer at a journal doesn't have the authority to dictate what our contributor guidelines are, but Marc seemed pretty invested in the reviewer's comments, and so we can track, discuss, and ultimately decide what to do with this punctilious pronouncement and any changes to our guidelines here.

Enable blank issues in our ISSUE_TEMPLATE config file so we can create non-templated issues for internal / development tasks.

See title and refer to https://github.com/NASA-PDS/nasa-pds.github.io/wiki/Git-and-Github-Guide#creating-a-new-repo to ensure group perms are set properly.

After reviewing the visibility of the default community health files I'm not convinced that they're prominent enough without additional linking on our part. I reread the GitHub documentation and I can both see where they accurately described the functionality and why I expected something different. I'd have liked to see references to the files off the main landing page for a repository but I can't find that anywhere.

I'd suggest that we update our template repos to link to these defaults in appropriately named README sections or something similar. Thoughts?

--

These are the only places where I can find references to our default files:

References are also available to the files on the Community Insights page but that seems way too nested for anyone to care.

The new community health files look great! Got a pleasant surprise from them when making a fresh pull-request this morning.

However, once I followed the links, I hit a 404: on the CONTRIBUTiNG.md, there's a clickable link to the "security policy" that goes nowhere:

You do get a cute Octocat though! Since the SECURITY.md is specific for each repository (because it typically lists supported versions), we could

• Reword this to mention checking the SECURITY.md file in a relevant repository without linking to it.
• Rewrite this to mention emailing a [email protected] email list; a lot of other organizations prefer to have security problems sent by encrypted email rather than publicly tracked for the obvious implications (with the obvious need for a public key to also be available for [email protected]).
• Drop this bullet.

Not sure what the right approach is.

May the force be with you 🐙🐱