Closed sanjayankur31 closed 1 year ago
The Software Sustainability Institute has a bunch of guides: https://software.ac.uk/guides Not very specific to research software, but still interesting: a label that you can earn if you meet certain requirements: https://bestpractices.coreinfrastructure.org/
Ran into this:
@sanjayankur31 Perhaps in the post above ;)
Meanwhile I pulled Arbor through that wringer: https://bestpractices.coreinfrastructure.org/en/projects/4476 We fail at process around security, but I think that does not really apply to our kind of projects. We don't do any static analysis or fuzzing in our CI as a matter of course, I'd be curious if anyone else here does and how they handle the probably very long list of 'problems' coming out of that. We've found that different tools produce very different outputs, and very different quality of outputs.
Oh, I thought I'd run into it from a different project :laughing:
Yes, I don't think all the points for general infrastructure projects apply to research projects---we'll cherry-pick the relevant ones.
With software that we package in NeuroFedora, the Red Hat security team tends to do regular audits so we do get CVE reports from time to time (Example). But, I'll have to double-check if they audit the complete set of thousands of packages included in Fedora and EL, or if they pick ones that are important for their own work/customers.
Google Style Guides | styleguide:
This project holds the C++ Style Guide, C# Style Guide, Swift Style Guide, Objective-C Style Guide, Java Style Guide, Python Style Guide, R Style Guide, Shell Style Guide, HTML/CSS Style Guide, JavaScript Style Guide, TypeScript Style Guide, AngularJS Style Guide, Common Lisp Style Guide, and Vimscript Style Guide. This project also contains cpplint, a tool to assist with style guide compliance, and google-c-style.el, an Emacs settings file for Google style.
Some more:
List of licenses with identifiers: https://spdx.org/licenses/
https://codecheck.org.uk/guide/community-process