NASA-AMMOS SLIM Repository Essentials Assistance -- Baseline Files

[jpl-jengelke]

Purpose

• Infusion of documentation and ticket/PR templating suggestions for SLIM integration

Proposed Changes

Automation templates for the following:

• Pull Requests
• Issue Tickets
• Feature Request Tickets

MGSS-approved and customized (application-specific) documentation templates:

• CHANGELOG.md
• CODE_OF_CONDUCT.md
• CONTRIBUTING.md
• LICENSE
• images in support of documentation in webdocs directory

Leveraging SLIM Best Practice Guides:
https://nasa-ammos.github.io/slim/docs/category/documentation
https://nasa-ammos.github.io/slim/docs/category/contributions

- ⚠ NOTE: This PR branch should be customized / adapted - please commit changes before merging!
- ⚠ NOTE: Modify by searching text ('INSERT' keyword) and/or replacing with appropriate values.
- ⚠ NOTE: Read the file thoroughly to ensure it's well adapted and please freely modify as necessary.

Issues

• SLIM Infusion

Testing

• Reviewed by developer and verified by Git Diff tool
• Documentation additions, no testing available

[cartermak]

Thank you for adding this! I'll review and edit as necessary.

Question out of curiosity: what's the case for maintaining a changelog in source control instead of using a tool like release messages in Github?

[jpl-jengelke]

Thank you for adding this! I'll review and edit as necessary.

Question out of curiosity: what's the case for maintaining a changelog in source control instead of using a tool like release messages in Github?

Hi Carter,

Thank you for reading through our PR. I'm on a team with @riverma who are working on Lab standards for software, and we also manage this GitHub project (project, not repo) in public GitHub. We are working on presenting unified documentation for all repos in the project, and that is what this PR is attempting to infuse. We hope that the suggested changes can be embraced with/without some modifications to make the standards relevant to this particular software repo.

The case for maintaining a source control changelog centers around how users get the package. Sometimes it is downloaded from release artifacts in the form of a compressed archive (one example) and so users don't always have network access. Moreover, it's a fallback standard that allows a more granular or detailed representation of changes, as necessary. More info is available at https://keepachangelog.com/en/1.1.0/ .

Thanks again,

John Engelke

[cartermak]

Hi John,

Thanks for the thoughtful reply! I definitely support the initiative for unified Lab standards and appreciate the rationale behind the changelog.

-Carter

[riverma]

@jpl-jengelke - please add back the LICENSE file.