From c550535441d713ac886e09bac4de3600c48eb7cc Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 8 May 2024 16:43:30 +0000 Subject: [PATCH] deploy: 111e50f40135ce86c88c7f44a61cc69e29307bbd --- 404.html | 4 ++-- assets/js/{c2d7cd96.9582cfde.js => c2d7cd96.242bd1f2.js} | 2 +- .../{runtime~main.7c84ec1f.js => runtime~main.0e083e3f.js} | 2 +- blog/archive/index.html | 4 ++-- blog/first-blog-post/index.html | 4 ++-- blog/index.html | 4 ++-- blog/long-blog-post/index.html | 4 ++-- blog/mdx-blog-post/index.html | 4 ++-- blog/tags/docusaurus/index.html | 4 ++-- blog/tags/facebook/index.html | 4 ++-- blog/tags/hello/index.html | 4 ++-- blog/tags/hola/index.html | 4 ++-- blog/tags/index.html | 4 ++-- blog/welcome/index.html | 4 ++-- docs/about/CODE_OF_CONDUCT/index.html | 4 ++-- docs/about/GOVERNANCE/index.html | 4 ++-- docs/about/index.html | 4 ++-- docs/category/-governance/index.html | 4 ++-- docs/category/-information-sharing/index.html | 4 ++-- docs/category/-software-lifecycle/index.html | 4 ++-- docs/category/application-starter-kits/index.html | 4 ++-- docs/category/contributions/index.html | 4 ++-- docs/category/security/index.html | 4 ++-- docs/contribute/contributing/development-process/index.html | 4 ++-- docs/contribute/contributing/index.html | 4 ++-- docs/contribute/contributing/introduction/index.html | 4 ++-- .../contributing/know-before-contribute/index.html | 4 ++-- docs/contribute/contributing/ways-to-contribute/index.html | 4 ++-- docs/contribute/submit-best-practice/index.html | 4 ++-- docs/guides/checklist/index.html | 4 ++-- docs/guides/documentation/change-log/index.html | 4 ++-- docs/guides/documentation/documentation-hosts/index.html | 4 ++-- .../trade-study-hostingdocs-user/index.html | 4 ++-- .../documentation/documentation-hosts/use-cases/index.html | 4 ++-- docs/guides/documentation/readme/README-TEMPLATE/index.html | 4 ++-- docs/guides/documentation/readme/index.html | 4 ++-- .../governance/contributions/code-of-conduct/index.html | 4 ++-- .../contributing-guide/CONTRIBUTING/index.html | 4 ++-- .../governance/contributions/contributing-guide/index.html | 4 ++-- .../issue-templates/bug-reports/bug_report.yml/index.html | 4 ++-- .../issue-templates/bug-reports/bug_report/index.html | 4 ++-- .../issue-templates/features/new_feature.yml/index.html | 4 ++-- .../issue-templates/features/new_feature/index.html | 4 ++-- .../governance/contributions/issue-templates/index.html | 4 ++-- .../pull-requests/PULL_REQUEST_TEMPLATE/index.html | 4 ++-- .../governance/contributions/pull-requests/index.html | 4 ++-- .../governance-model/GOVERNANCE-TEMPLATE/index.html | 4 ++-- .../governance-template-small-team/index.html | 4 ++-- docs/guides/governance/governance-model/index.html | 4 ++-- docs/guides/search/index.html | 6 +++--- .../application-starter-kits/python-starter-kit/index.html | 4 ++-- .../continuous-integration-frameworks/index.html | 4 ++-- .../software-lifecycle/continuous-integration/index.html | 4 ++-- .../reference-architecture/index.html | 4 ++-- .../guides/software-lifecycle/continuous-testing/index.html | 4 ++-- .../continuous-testing/testing-frameworks/index.html | 4 ++-- docs/guides/software-lifecycle/metrics/index.html | 4 ++-- .../software-lifecycle/security/github-security/index.html | 4 ++-- .../security/secrets-detection/index.html | 4 ++-- docs/join/index.html | 4 ++-- index.html | 4 ++-- markdown-page/index.html | 4 ++-- 62 files changed, 123 insertions(+), 123 deletions(-) rename assets/js/{c2d7cd96.9582cfde.js => c2d7cd96.242bd1f2.js} (74%) rename assets/js/{runtime~main.7c84ec1f.js => runtime~main.0e083e3f.js} (99%) diff --git a/404.html b/404.html index 8d1e5fe52..e429b5599 100644 --- a/404.html +++ b/404.html @@ -5,13 +5,13 @@ Page Not Found | SLIM - +
Skip to main content

Page Not Found

We could not find what you were looking for.

Please contact the owner of the site that linked you to the original URL and let them know their link is broken.

- + \ No newline at end of file diff --git a/assets/js/c2d7cd96.9582cfde.js b/assets/js/c2d7cd96.242bd1f2.js similarity index 74% rename from assets/js/c2d7cd96.9582cfde.js rename to assets/js/c2d7cd96.242bd1f2.js index 3ec2339c7..c6591d45c 100644 --- a/assets/js/c2d7cd96.9582cfde.js +++ b/assets/js/c2d7cd96.242bd1f2.js @@ -1 +1 @@ -"use strict";(self.webpackChunkdocusaurus=self.webpackChunkdocusaurus||[]).push([[7972],{8171:(e,t,o)=>{o.r(t),o.d(t,{assets:()=>T,contentTitle:()=>Z,default:()=>L,frontMatter:()=>E,metadata:()=>C,toc:()=>A});var i=o(7462),s=o(7294),n=o(3905),r=o(8182),a=o(6714),c=o(6518),l=o(7977),u=o(5005),d=o(682),g=o(924),m=o(9463),p=o(2914),y=o(5517),f=o(4051),h=o(1555);const v=e=>{let{title:t,uri:o,tags:i,description:n}=e;return s.createElement(r.Z,null,s.createElement(r.Z.Header,{as:"h5"},t),s.createElement(r.Z.Body,null,s.createElement(r.Z.Text,null,s.createElement("p",null,n)),s.createElement(a.Z,null,s.createElement(c.Z,null,"Tags:",i.map((e=>s.createElement(l.Z,{bg:"secondary",className:"ms-1"},k(e)))))),s.createElement("a",{href:o,target:"_blank",rel:"noopener noreferrer"},s.createElement(u.Z,{variant:"primary",className:"mt-3",size:"md"},"View"))))};function k(e){return e.split("-").map((e=>e.charAt(0).toUpperCase()+e.slice(1))).join(" ")}const b=e=>{let{panelsData:t}=e;const[o,i]=(0,s.useState)("All"),[n,r]=(0,s.useState)({}),[a,c]=(0,s.useState)([]),[l,u]=(0,s.useState)([]),[b,w]=(0,s.useState)([]),[x,E]=(0,s.useState)("");(0,s.useEffect)((()=>{c(t);const e=[...new Set(t.flatMap((e=>e.tags)))];u(e),w(e)}),[]);const Z=a.filter((e=>Object.entries(n).every((t=>{let[o,i]=t;return!i||e.tags.includes(o)}))&&(e.title.toLowerCase().includes(x.toLowerCase())||e.description.toLowerCase().includes(x.toLowerCase()))));return s.createElement(d.Z,null,s.createElement("div",{className:"d-flex justify-content-center"},s.createElement(g.Z,{bg:"light",expand:"lg",className:"mb-4 p-4"},s.createElement(g.Z.Toggle,{"aria-controls":"navbar-nav"}),s.createElement(g.Z.Collapse,{id:"navbar-nav"},s.createElement(m.Z,{className:"mr-auto ps-2"},s.createElement(p.Z.Control,{type:"text",placeholder:"Search",value:x,onChange:e=>{E(e.target.value)}}),s.createElement(y.Z,null,s.createElement(y.Z.Toggle,{variant:"primary",id:"tag-dropdown",className:"ms-2"},Object.values(n).some((e=>e))?`${Object.keys(n).filter((e=>n[e])).length} tags selected`:"Select Tags"),s.createElement(y.Z.Menu,{className:"p-3",style:{minWidth:"250px",maxHeight:"400px",overflowY:"auto"}},s.createElement(p.Z.Control,{type:"text",placeholder:"Search Tags",className:"mb-2",onChange:e=>{const t=e.target.value.toLowerCase(),o=l.filter((e=>e.toLowerCase().includes(t)));w(o)}}),b.sort(((e,t)=>e.localeCompare(t))).map(((e,t)=>s.createElement(p.Z.Check,{key:t,type:"checkbox",label:k(e),id:`tag-checkbox-${t}`,checked:n[e]||!1,onChange:()=>(e=>{r((t=>{const o={...t};return o[e]=!o[e],o}))})(e)}))))))))),s.createElement(f.Z,null,Z.map(((e,t)=>s.createElement(h.Z,{key:t,sm:12,className:"mb-4"},s.createElement(v,{title:e.title,uri:e.uri,tags:e.tags,description:e.description}))))))},w=JSON.parse('[{"title":"GOVERNANCE.md","uri":"/slim/docs/guides/governance/governance-model","category":"governance","description":"A governance model template seeking to generalize how most government-sponsored open source projects can expect to operate in the open source arena.","tags":["governance","templates","repository-setup","github"]},{"title":"Secrets Detection","uri":"/slim/docs/guides/software-lifecycle/security/secrets-detection","category":"software lifecycle","description":"Detect-secrets is a security tool that scans code repositories to identify and prevent the accidental inclusion of sensitive information, such as API keys or passwords, by utilizing various detection techniques.","tags":["software-lifecycle","security","testing","tools"]},{"title":"README.md","uri":"/slim/docs/guides/documentation/readme","category":"documentation","description":"A template that can be used to help developers and users understand your repository\'s project code concisely and clearly.","tags":["documentation","repository-setup","templates","github"]},{"title":"Issue Ticket Templates","uri":"/slim/docs/guides/governance/contributions/issue-templates/","category":"documentation","description":"Issue tickets templates helping development teams keep the language of bug, feature, and other types of issues readable and consistent.","tags":["documentation","templates","repository-setup","github"]},{"title":"Change Log","uri":"/slim/docs/guides/documentation/change-log/","category":"documentation","description":"A guide on creating and maintaining a human-readable change log for software development projects, emphasizing the importance of a `CHANGELOG.md` file.","tags":["documentation","versioning","templates","repository-setup","github"]},{"title":"Documentation Hosts","uri":"/slim/docs/guides/documentation/documentation-hosts/trade-study-hostingdocs-user","category":"documentation","description":"A guide on possible use cases and recommended tools for hosting various types of documentation with a call for contributions.","tags":["documentation","trade-studies","tools"]},{"title":"Pull Requests","uri":"/slim/docs/guides/governance/contributions/pull-requests","category":"governance","description":"A guide outlining how to implement a pre-filled pull request template to provide guidance to potential contributors on GitHub.","tags":["github","templates","governance","repository-setup"]},{"title":"Code of Conduct","uri":"/slim/docs/guides/governance/contributions/code-of-conduct","category":"governance","description":"A guide on how to create and implement a code of conduct for project teams, with a specific recommendation to use the Contributor Covenant.","tags":["governance","repository-setup","github","templates"]},{"title":"Contributing Guide","uri":"/slim/docs/guides/governance/contributions/contributing-guide","category":"governance","description":"A detailed guide about creating a contributing guide for your project, featuring a customizable template and instructions on how to use it.","tags":["templates","governance","repository-setup","github","templates"]},{"title":"Python Starter Kit","uri":"/slim/docs/guides/software-lifecycle/application-starter-kits/python-starter-kit","category":"software-lifecycle","description":"A guide to a complete, deployment-ready Python 3 application that\'s bundled into a reusable template repository for quick implementation, with integrated build, release, and publish on GitHub.","tags":["python","templates","repository-setup","continuous-integration","github"]},{"title":"Continuous Integration Frameworks","uri":"/slim/docs/guides/software-lifecycle/continuous-integration/continuous-integration-frameworks","category":"software lifecycle","description":"An overview of different continuous integration frameworks and their use cases.","tags":["tools","continuous-integration","trade-studies"]},{"title":"Reference Architectures","uri":"/slim/docs/guides/software-lifecycle/continuous-integration/reference-architecture","category":"software lifecycle","description":"A high-level reference guide for the implementation of continuous integration best practices, detailing structure, component interrelationships, and processes.","tags":["continuous-integration","testing","versioning","devops"]},{"title":"Continuous Testing","uri":"/slim/docs/guides/software-lifecycle/continuous-testing/","category":"software lifecycle","description":"An extensive list of resources and tools for continuous testing including module testing, service endpoint testing, performance testing, and mobile testing among others.","tags":["testing","tools"]},{"title":"GitHub Security Best Practices","uri":"/slim/docs/guides/software-lifecycle/security/github-security","category":"software lifecycle","description":"Recommendations for enabling GitHub security features for repositories, including using GitHub native tools like CodeQL, code scanning and more.","tags":["software-lifecycle","security","testing","tools"]},{"title":"Metrics Tracking","uri":"/slim/docs/guides/software-lifecycle/metrics","category":"metrics tracking","description":"Recommendations for metrics collection and an installation tool for Apache DevLake.","tags":["software-lifecycle","metrics","tools"]}]');var x=o(3727);const E={sidebar_position:1},Z="\ud83d\udd0d Explore Our Guides",C={unversionedId:"guides/search",id:"guides/search",title:"\ud83d\udd0d Explore Our Guides",description:"Explore our guides via the categories below or the left-hand navigation. You may also search our guides.",source:"@site/docs/guides/search.md",sourceDirName:"guides",slug:"/guides/search",permalink:"/slim/docs/guides/search",draft:!1,editUrl:"https://github.com/nasa-ammos/slim/tree/main/docs/guides/search.md",tags:[],version:"current",sidebarPosition:1,frontMatter:{sidebar_position:1},sidebar:"guidesSidebar",next:{title:"\u2705 Getting Started",permalink:"/slim/docs/guides/checklist"}},T={},A=[{value:"Search",id:"search",level:2}],S={toc:A},D="wrapper";function L(e){let{components:t,...o}=e;return(0,n.kt)(D,(0,i.Z)({},S,o,{components:t,mdxType:"MDXLayout"}),(0,n.kt)("h1",{id:"-explore-our-guides"},"\ud83d\udd0d Explore Our Guides"),(0,n.kt)("p",null,"Explore our guides via the categories below or the left-hand navigation. You may also search our guides."),(0,n.kt)("div",{style:{display:"flex",flexWrap:"wrap",gap:"20px",justifyContent:"center"}},(0,n.kt)(x.rU,{to:"/slim/docs/category/software-lifecycle",style:{width:"18rem",textDecoration:"none"},mdxType:"Link"},(0,n.kt)(r.Z,{style:{flex:"1 0 auto",cursor:"pointer"},mdxType:"Card"},(0,n.kt)(r.Z.Body,{style:{textAlign:"center"}},(0,n.kt)("img",{src:"/slim/img/lifecycle.svg",alt:"Software Lifecycle",style:{maxHeight:"200px"}}),(0,n.kt)(r.Z.Title,null,"Software Lifecycle"),(0,n.kt)(r.Z.Text,null,"Covers the entire process of software development, continuous pipelines, application kits, testing, and security.")))),(0,n.kt)(x.rU,{to:"/slim/docs/category/governance",style:{width:"18rem",textDecoration:"none"},mdxType:"Link"},(0,n.kt)(r.Z,{style:{flex:"1 0 auto",cursor:"pointer"},mdxType:"Card"},(0,n.kt)(r.Z.Body,{style:{textAlign:"center"}},(0,n.kt)("img",{src:"/slim/img/governance.svg",alt:"Governance",style:{maxHeight:"200px"}}),(0,n.kt)(r.Z.Title,null,"Governance"),(0,n.kt)(r.Z.Text,null,"Dedicated to establishing robust governance frameworks, with standards for contributions and governance models.")))),(0,n.kt)(x.rU,{to:"/slim/docs/category/documentation",style:{width:"18rem",textDecoration:"none"},mdxType:"Link"},(0,n.kt)(r.Z,{style:{flex:"1 0 auto",cursor:"pointer"},mdxType:"Card"},(0,n.kt)(r.Z.Body,{style:{textAlign:"center"}},(0,n.kt)("img",{src:"/slim/img/documentation.svg",alt:"Documentation",style:{maxHeight:"200px"}}),(0,n.kt)(r.Z.Title,null,"Information Sharing"),(0,n.kt)(r.Z.Text,null,"Focuses on creating effective project documentation, including Change Logs, Documentation Hosts, and README templates."))))),(0,n.kt)("div",{style:{display:"flex",flexWrap:"wrap",gap:"20px",marginTop:"20px",justifyContent:"center",width:"100%"}},(0,n.kt)(x.rU,{to:"/slim/docs/guides/checklist",style:{textDecoration:"none",width:"100%"},mdxType:"Link"},(0,n.kt)(r.Z,{style:{flex:"1 0 auto",cursor:"pointer",width:"100%"},mdxType:"Card"},(0,n.kt)(r.Z.Body,{style:{textAlign:"center"}},(0,n.kt)(r.Z.Title,null,"Getting Started"),(0,n.kt)(r.Z.Text,null,"Not sure where to begin? Start here with our checklist."))))),(0,n.kt)("hr",null),(0,n.kt)("br",null),(0,n.kt)("h2",{id:"search"},"Search"),(0,n.kt)(b,{panelsData:w,mdxType:"FacetedPanels"}))}L.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkdocusaurus=self.webpackChunkdocusaurus||[]).push([[7972],{8171:(e,t,o)=>{o.r(t),o.d(t,{assets:()=>T,contentTitle:()=>C,default:()=>G,frontMatter:()=>Z,metadata:()=>E,toc:()=>S});var i=o(7462),s=o(7294),n=o(3905),r=o(8182),a=o(6714),c=o(6518),l=o(7977),u=o(5005),d=o(682),g=o(924),m=o(9463),p=o(2914),y=o(5517),f=o(4051),h=o(1555);const v=e=>{let{title:t,uri:o,tags:i,description:n}=e;return s.createElement(r.Z,null,s.createElement(r.Z.Header,{as:"h5"},t),s.createElement(r.Z.Body,null,s.createElement(r.Z.Text,null,s.createElement("p",null,n)),s.createElement(a.Z,null,s.createElement(c.Z,null,"Tags:",i.map((e=>s.createElement(l.Z,{bg:"secondary",className:"ms-1"},k(e)))))),s.createElement("a",{href:o,target:"_blank",rel:"noopener noreferrer"},s.createElement(u.Z,{variant:"primary",className:"mt-3",size:"md"},"View"))))};function k(e){return e.split("-").map((e=>e.charAt(0).toUpperCase()+e.slice(1))).join(" ")}const b=e=>{let{panelsData:t}=e;const[o,i]=(0,s.useState)("All"),[n,r]=(0,s.useState)({}),[a,c]=(0,s.useState)([]),[l,u]=(0,s.useState)([]),[b,w]=(0,s.useState)([]),[x,Z]=(0,s.useState)("");(0,s.useEffect)((()=>{c(t);const e=[...new Set(t.flatMap((e=>e.tags)))];u(e),w(e)}),[]);const C=a.filter((e=>Object.entries(n).every((t=>{let[o,i]=t;return!i||e.tags.includes(o)}))&&(e.title.toLowerCase().includes(x.toLowerCase())||e.description.toLowerCase().includes(x.toLowerCase()))));return s.createElement(d.Z,null,s.createElement("div",{className:"d-flex justify-content-center"},s.createElement(g.Z,{bg:"light",expand:"lg",className:"mb-4 p-4"},s.createElement(g.Z.Toggle,{"aria-controls":"navbar-nav"}),s.createElement(g.Z.Collapse,{id:"navbar-nav"},s.createElement(m.Z,{className:"mr-auto ps-2"},s.createElement(p.Z.Control,{type:"text",placeholder:"Search",value:x,onChange:e=>{Z(e.target.value)}}),s.createElement(y.Z,null,s.createElement(y.Z.Toggle,{variant:"primary",id:"tag-dropdown",className:"ms-2"},Object.values(n).some((e=>e))?`${Object.keys(n).filter((e=>n[e])).length} tags selected`:"Select Tags"),s.createElement(y.Z.Menu,{className:"p-3",style:{minWidth:"250px",maxHeight:"400px",overflowY:"auto"}},s.createElement(p.Z.Control,{type:"text",placeholder:"Search Tags",className:"mb-2",onChange:e=>{const t=e.target.value.toLowerCase(),o=l.filter((e=>e.toLowerCase().includes(t)));w(o)}}),b.sort(((e,t)=>e.localeCompare(t))).map(((e,t)=>s.createElement(p.Z.Check,{key:t,type:"checkbox",label:k(e),id:`tag-checkbox-${t}`,checked:n[e]||!1,onChange:()=>(e=>{r((t=>{const o={...t};return o[e]=!o[e],o}))})(e)}))))))))),s.createElement(f.Z,null,C.map(((e,t)=>s.createElement(h.Z,{key:t,sm:12,className:"mb-4"},s.createElement(v,{title:e.title,uri:e.uri,tags:e.tags,description:e.description}))))))},w=JSON.parse('[{"title":"GOVERNANCE.md","uri":"/slim/docs/guides/governance/governance-model","category":"governance","description":"A governance model template seeking to generalize how most government-sponsored open source projects can expect to operate in the open source arena.","tags":["governance","templates","repository-setup","github"]},{"title":"Secrets Detection","uri":"/slim/docs/guides/software-lifecycle/security/secrets-detection","category":"software lifecycle","description":"Detect-secrets is a security tool that scans code repositories to identify and prevent the accidental inclusion of sensitive information, such as API keys or passwords, by utilizing various detection techniques.","tags":["software-lifecycle","security","testing","tools"]},{"title":"README.md","uri":"/slim/docs/guides/documentation/readme","category":"documentation","description":"A template that can be used to help developers and users understand your repository\'s project code concisely and clearly.","tags":["documentation","repository-setup","templates","github"]},{"title":"Issue Ticket Templates","uri":"/slim/docs/guides/governance/contributions/issue-templates/","category":"documentation","description":"Issue tickets templates helping development teams keep the language of bug, feature, and other types of issues readable and consistent.","tags":["documentation","templates","repository-setup","github"]},{"title":"Change Log","uri":"/slim/docs/guides/documentation/change-log/","category":"documentation","description":"A guide on creating and maintaining a human-readable change log for software development projects, emphasizing the importance of a `CHANGELOG.md` file.","tags":["documentation","versioning","templates","repository-setup","github"]},{"title":"Documentation Hosts","uri":"/slim/docs/guides/documentation/documentation-hosts/trade-study-hostingdocs-user","category":"documentation","description":"A guide on possible use cases and recommended tools for hosting various types of documentation with a call for contributions.","tags":["documentation","trade-studies","tools"]},{"title":"Pull Requests","uri":"/slim/docs/guides/governance/contributions/pull-requests","category":"governance","description":"A guide outlining how to implement a pre-filled pull request template to provide guidance to potential contributors on GitHub.","tags":["github","templates","governance","repository-setup"]},{"title":"Code of Conduct","uri":"/slim/docs/guides/governance/contributions/code-of-conduct","category":"governance","description":"A guide on how to create and implement a code of conduct for project teams, with a specific recommendation to use the Contributor Covenant.","tags":["governance","repository-setup","github","templates"]},{"title":"Contributing Guide","uri":"/slim/docs/guides/governance/contributions/contributing-guide","category":"governance","description":"A detailed guide about creating a contributing guide for your project, featuring a customizable template and instructions on how to use it.","tags":["templates","governance","repository-setup","github","templates"]},{"title":"Python Starter Kit","uri":"/slim/docs/guides/software-lifecycle/application-starter-kits/python-starter-kit","category":"software-lifecycle","description":"A guide to a complete, deployment-ready Python 3 application that\'s bundled into a reusable template repository for quick implementation, with integrated build, release, and publish on GitHub.","tags":["python","templates","repository-setup","continuous-integration","github"]},{"title":"Continuous Integration Frameworks","uri":"/slim/docs/guides/software-lifecycle/continuous-integration/continuous-integration-frameworks","category":"software lifecycle","description":"An overview of different continuous integration frameworks and their use cases.","tags":["tools","continuous-integration","trade-studies"]},{"title":"Reference Architectures","uri":"/slim/docs/guides/software-lifecycle/continuous-integration/reference-architecture","category":"software lifecycle","description":"A high-level reference guide for the implementation of continuous integration best practices, detailing structure, component interrelationships, and processes.","tags":["continuous-integration","testing","versioning","devops"]},{"title":"Continuous Testing","uri":"/slim/docs/guides/software-lifecycle/continuous-testing/","category":"software lifecycle","description":"An extensive list of resources and tools for continuous testing including module testing, service endpoint testing, performance testing, and mobile testing among others.","tags":["testing","tools"]},{"title":"GitHub Security Best Practices","uri":"/slim/docs/guides/software-lifecycle/security/github-security","category":"software lifecycle","description":"Recommendations for enabling GitHub security features for repositories, including using GitHub native tools like CodeQL, code scanning and more.","tags":["software-lifecycle","security","testing","tools"]},{"title":"Metrics Tracking","uri":"/slim/docs/guides/software-lifecycle/metrics","category":"metrics tracking","description":"Recommendations for metrics collection and an installation tool for Apache DevLake.","tags":["software-lifecycle","metrics","tools"]}]');var x=o(3727);const Z={sidebar_position:1},C="\ud83d\udd0d Explore Our Guides",E={unversionedId:"guides/search",id:"guides/search",title:"\ud83d\udd0d Explore Our Guides",description:"Explore our guides via the categories below or the left-hand navigation. You may also search our guides.",source:"@site/docs/guides/search.md",sourceDirName:"guides",slug:"/guides/search",permalink:"/slim/docs/guides/search",draft:!1,editUrl:"https://github.com/nasa-ammos/slim/tree/main/docs/guides/search.md",tags:[],version:"current",sidebarPosition:1,frontMatter:{sidebar_position:1},sidebar:"guidesSidebar",next:{title:"\u2705 Getting Started",permalink:"/slim/docs/guides/checklist"}},T={},S=[{value:"Search",id:"search",level:2}],A={toc:S},L="wrapper";function G(e){let{components:t,...o}=e;return(0,n.kt)(L,(0,i.Z)({},A,o,{components:t,mdxType:"MDXLayout"}),(0,n.kt)("h1",{id:"-explore-our-guides"},"\ud83d\udd0d Explore Our Guides"),(0,n.kt)("p",null,"Explore our guides via the categories below or the left-hand navigation. You may also search our guides."),(0,n.kt)("div",{style:{display:"flex",flexWrap:"wrap",gap:"20px",justifyContent:"center"}},(0,n.kt)(x.rU,{to:"/slim/docs/category/-software-lifecycle",style:{width:"18rem",textDecoration:"none"},mdxType:"Link"},(0,n.kt)(r.Z,{style:{flex:"1 0 auto",cursor:"pointer"},mdxType:"Card"},(0,n.kt)(r.Z.Body,{style:{textAlign:"center"}},(0,n.kt)("img",{src:"/slim/img/lifecycle.svg",alt:"Software Lifecycle",style:{maxHeight:"200px"}}),(0,n.kt)(r.Z.Title,null,"Software Lifecycle"),(0,n.kt)(r.Z.Text,null,"Covers the entire process of software development: from code development, testing, building, security to deployment and delivery.")))),(0,n.kt)(x.rU,{to:"/slim/docs/category/-governance",style:{width:"18rem",textDecoration:"none"},mdxType:"Link"},(0,n.kt)(r.Z,{style:{flex:"1 0 auto",cursor:"pointer"},mdxType:"Card"},(0,n.kt)(r.Z.Body,{style:{textAlign:"center"}},(0,n.kt)("img",{src:"/slim/img/governance.svg",alt:"Governance",style:{maxHeight:"200px"}}),(0,n.kt)(r.Z.Title,null,"Governance"),(0,n.kt)(r.Z.Text,null,"Covers governance topics like governance frameworks, standards for contributions, triaging and other ideas.")))),(0,n.kt)(x.rU,{to:"/slim/docs/category/-information-sharing",style:{width:"18rem",textDecoration:"none"},mdxType:"Link"},(0,n.kt)(r.Z,{style:{flex:"1 0 auto",cursor:"pointer"},mdxType:"Card"},(0,n.kt)(r.Z.Body,{style:{textAlign:"center"}},(0,n.kt)("img",{src:"/slim/img/documentation.svg",alt:"Information Sharing",style:{maxHeight:"200px"}}),(0,n.kt)(r.Z.Title,null,"Information Sharing"),(0,n.kt)(r.Z.Text,null,"Focuses on project information sharing best practices, including documentation, communication channels, and other topics."))))),(0,n.kt)("div",{style:{display:"flex",flexWrap:"wrap",gap:"20px",marginTop:"20px",justifyContent:"center",width:"100%"}},(0,n.kt)(x.rU,{to:"/slim/docs/guides/checklist",style:{textDecoration:"none",width:"100%"},mdxType:"Link"},(0,n.kt)(r.Z,{style:{flex:"1 0 auto",cursor:"pointer",width:"100%"},mdxType:"Card"},(0,n.kt)(r.Z.Body,{style:{textAlign:"center"}},(0,n.kt)(r.Z.Title,null,"Getting Started"),(0,n.kt)(r.Z.Text,null,"Not sure where to begin? Start here with our checklist."))))),(0,n.kt)("hr",null),(0,n.kt)("br",null),(0,n.kt)("h2",{id:"search"},"Search"),(0,n.kt)(b,{panelsData:w,mdxType:"FacetedPanels"}))}G.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/runtime~main.7c84ec1f.js b/assets/js/runtime~main.0e083e3f.js similarity index 99% rename from assets/js/runtime~main.7c84ec1f.js rename to assets/js/runtime~main.0e083e3f.js index 3a6673129..ada9c5049 100644 --- a/assets/js/runtime~main.7c84ec1f.js +++ b/assets/js/runtime~main.0e083e3f.js @@ -1 +1 @@ -(()=>{"use strict";var e,a,c,f,b,d={},t={};function r(e){var a=t[e];if(void 0!==a)return a.exports;var c=t[e]={id:e,loaded:!1,exports:{}};return d[e].call(c.exports,c,c.exports,r),c.loaded=!0,c.exports}r.m=d,r.c=t,e=[],r.O=(a,c,f,b)=>{if(!c){var d=1/0;for(i=0;i=b)&&Object.keys(r.O).every((e=>r.O[e](c[o])))?c.splice(o--,1):(t=!1,b0&&e[i-1][2]>b;i--)e[i]=e[i-1];e[i]=[c,f,b]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},c=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,f){if(1&f&&(e=this(e)),8&f)return e;if("object"==typeof e&&e){if(4&f&&e.__esModule)return e;if(16&f&&"function"==typeof e.then)return e}var b=Object.create(null);r.r(b);var d={};a=a||[null,c({}),c([]),c(c)];for(var t=2&f&&e;"object"==typeof t&&!~a.indexOf(t);t=c(t))Object.getOwnPropertyNames(t).forEach((a=>d[a]=()=>e[a]));return d.default=()=>e,r.d(b,d),b},r.d=(e,a)=>{for(var c in a)r.o(a,c)&&!r.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:a[c]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,c)=>(r.f[c](e,a),a)),[])),r.u=e=>"assets/js/"+({46:"ca705c4a",53:"935f2afb",150:"32de2db0",292:"1937bb63",380:"22251b09",493:"ed7f1a16",913:"3e49c4e2",948:"8717b14a",1028:"51785cc5",1178:"80ba3087",1757:"cd95f078",1914:"d9f32620",2031:"8c4308b7",2049:"2bc4934e",2052:"69878e35",2081:"73e4d764",2119:"c612d4a7",2213:"39680a00",2249:"f26fc996",2267:"59362658",2362:"e273c56f",2475:"1375824b",2535:"814f3328",2608:"d52baca9",2774:"6d6ba527",3021:"c36b7e6b",3085:"1f391b9e",3089:"a6aa9e1f",3514:"73664a40",3608:"9e4087bc",3662:"b76a362f",3689:"c441f7d5",3842:"4317fbf7",4013:"01a85c17",4024:"6fb1fe71",4081:"719b1851",4103:"684aec4d",4173:"3b327884",4195:"c4f5d8e4",4227:"d5decc06",4555:"e0d5b996",4642:"b741a796",5178:"d07f8614",5242:"de1ef56c",5288:"4c9dd493",5307:"f1e6a692",5620:"e9025b0e",5680:"c2f4afbb",6004:"a729c412",6047:"5a59ea68",6103:"ccc49370",6104:"d698a8c5",6189:"91db1580",6677:"2f60f69a",7075:"be00f8f0",7170:"cb227d72",7275:"b4deb335",7414:"393be207",7649:"da286ece",7890:"51f4fcc3",7918:"17896441",7972:"c2d7cd96",8059:"7a337337",8361:"3cc55dcd",8400:"21821687",8558:"1fb8531c",8610:"6875c492",8636:"f4f34a3a",8671:"325c7275",8780:"8facacb8",8793:"403f595d",9003:"925b3f96",9278:"cdace248",9315:"abf58fe5",9402:"64fc4b83",9510:"0ee94099",9514:"1be78505",9642:"7661071f",9721:"3b13db8a",9817:"14eb3368",9959:"f25b6166"}[e]||e)+"."+{46:"42cbb196",53:"cac37dc1",150:"1f95ed27",292:"c01fcc43",380:"d8a93ec4",493:"6470d80e",913:"d8ecb7ca",948:"914d35ec",1028:"23da16a3",1098:"06d2c692",1178:"77bdf4ed",1757:"88e6a440",1914:"8aa602a6",2031:"98e99271",2049:"72893041",2052:"f01ce896",2081:"add750cf",2119:"d79501aa",2213:"7d42604e",2249:"ded78440",2267:"4445c936",2362:"0e41ec1f",2475:"0eff4db0",2529:"36c3bab3",2535:"743a3596",2608:"93fe4de6",2774:"5eaf706e",3021:"eb9b69eb",3085:"b260a6c5",3089:"a59b6240",3514:"a2ef6c76",3608:"fd66296e",3662:"fbd93ba2",3689:"fb308300",3842:"72d345f9",4013:"298b1a20",4024:"1edfdccc",4081:"5489bd4c",4103:"620595e0",4173:"4c384568",4195:"814258f0",4227:"fb746336",4555:"66988315",4642:"e68df027",4972:"71e74212",5178:"7b874a4b",5242:"3c4d2b0b",5288:"791558f2",5307:"1a0ccef4",5620:"a495e7a8",5680:"0277c7b0",6004:"8bb585dc",6047:"4c43887d",6103:"a04a9b88",6104:"4db76e32",6189:"d5c6552e",6316:"e253b8dd",6677:"ab253a10",7075:"3f5f6938",7170:"4bffee7f",7275:"0f7ffc27",7414:"2b6bec03",7649:"af8db11e",7724:"1ce4c8a5",7890:"2e8be81b",7918:"c879fc52",7972:"9582cfde",8059:"fdddc084",8361:"d7ac881b",8400:"d46fda60",8558:"6ee91e0a",8610:"7dbfa267",8636:"ec4f7a24",8671:"ca7f10df",8780:"af109432",8793:"fbcc0f20",9003:"39c96a76",9278:"98c4f9dd",9315:"edda825d",9402:"8763c510",9487:"1902e0d9",9510:"d97cafc7",9514:"8f5a31ba",9620:"b536c143",9642:"4eb2b4ef",9721:"9606fcc4",9817:"7e910f19",9959:"c6d206b1"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),f={},b="docusaurus:",r.l=(e,a,c,d)=>{if(f[e])f[e].push(a);else{var t,o;if(void 0!==c)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var b=f[e];if(delete f[e],t.parentNode&&t.parentNode.removeChild(t),b&&b.forEach((e=>e(c))),a)return a(c)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/slim/",r.gca=function(e){return e={17896441:"7918",21821687:"8400",59362658:"2267",ca705c4a:"46","935f2afb":"53","32de2db0":"150","1937bb63":"292","22251b09":"380",ed7f1a16:"493","3e49c4e2":"913","8717b14a":"948","51785cc5":"1028","80ba3087":"1178",cd95f078:"1757",d9f32620:"1914","8c4308b7":"2031","2bc4934e":"2049","69878e35":"2052","73e4d764":"2081",c612d4a7:"2119","39680a00":"2213",f26fc996:"2249",e273c56f:"2362","1375824b":"2475","814f3328":"2535",d52baca9:"2608","6d6ba527":"2774",c36b7e6b:"3021","1f391b9e":"3085",a6aa9e1f:"3089","73664a40":"3514","9e4087bc":"3608",b76a362f:"3662",c441f7d5:"3689","4317fbf7":"3842","01a85c17":"4013","6fb1fe71":"4024","719b1851":"4081","684aec4d":"4103","3b327884":"4173",c4f5d8e4:"4195",d5decc06:"4227",e0d5b996:"4555",b741a796:"4642",d07f8614:"5178",de1ef56c:"5242","4c9dd493":"5288",f1e6a692:"5307",e9025b0e:"5620",c2f4afbb:"5680",a729c412:"6004","5a59ea68":"6047",ccc49370:"6103",d698a8c5:"6104","91db1580":"6189","2f60f69a":"6677",be00f8f0:"7075",cb227d72:"7170",b4deb335:"7275","393be207":"7414",da286ece:"7649","51f4fcc3":"7890",c2d7cd96:"7972","7a337337":"8059","3cc55dcd":"8361","1fb8531c":"8558","6875c492":"8610",f4f34a3a:"8636","325c7275":"8671","8facacb8":"8780","403f595d":"8793","925b3f96":"9003",cdace248:"9278",abf58fe5:"9315","64fc4b83":"9402","0ee94099":"9510","1be78505":"9514","7661071f":"9642","3b13db8a":"9721","14eb3368":"9817",f25b6166:"9959"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,c)=>{var f=r.o(e,a)?e[a]:void 0;if(0!==f)if(f)c.push(f[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var b=new Promise(((c,b)=>f=e[a]=[c,b]));c.push(f[2]=b);var d=r.p+r.u(a),t=new Error;r.l(d,(c=>{if(r.o(e,a)&&(0!==(f=e[a])&&(e[a]=void 0),f)){var b=c&&("load"===c.type?"missing":c.type),d=c&&c.target&&c.target.src;t.message="Loading chunk "+a+" failed.\n("+b+": "+d+")",t.name="ChunkLoadError",t.type=b,t.request=d,f[1](t)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,c)=>{var f,b,d=c[0],t=c[1],o=c[2],n=0;if(d.some((a=>0!==e[a]))){for(f in t)r.o(t,f)&&(r.m[f]=t[f]);if(o)var i=o(r)}for(a&&a(c);n{"use strict";var e,a,c,f,b,d={},t={};function r(e){var a=t[e];if(void 0!==a)return a.exports;var c=t[e]={id:e,loaded:!1,exports:{}};return d[e].call(c.exports,c,c.exports,r),c.loaded=!0,c.exports}r.m=d,r.c=t,e=[],r.O=(a,c,f,b)=>{if(!c){var d=1/0;for(i=0;i=b)&&Object.keys(r.O).every((e=>r.O[e](c[o])))?c.splice(o--,1):(t=!1,b0&&e[i-1][2]>b;i--)e[i]=e[i-1];e[i]=[c,f,b]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},c=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,f){if(1&f&&(e=this(e)),8&f)return e;if("object"==typeof e&&e){if(4&f&&e.__esModule)return e;if(16&f&&"function"==typeof e.then)return e}var b=Object.create(null);r.r(b);var d={};a=a||[null,c({}),c([]),c(c)];for(var t=2&f&&e;"object"==typeof t&&!~a.indexOf(t);t=c(t))Object.getOwnPropertyNames(t).forEach((a=>d[a]=()=>e[a]));return d.default=()=>e,r.d(b,d),b},r.d=(e,a)=>{for(var c in a)r.o(a,c)&&!r.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:a[c]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,c)=>(r.f[c](e,a),a)),[])),r.u=e=>"assets/js/"+({46:"ca705c4a",53:"935f2afb",150:"32de2db0",292:"1937bb63",380:"22251b09",493:"ed7f1a16",913:"3e49c4e2",948:"8717b14a",1028:"51785cc5",1178:"80ba3087",1757:"cd95f078",1914:"d9f32620",2031:"8c4308b7",2049:"2bc4934e",2052:"69878e35",2081:"73e4d764",2119:"c612d4a7",2213:"39680a00",2249:"f26fc996",2267:"59362658",2362:"e273c56f",2475:"1375824b",2535:"814f3328",2608:"d52baca9",2774:"6d6ba527",3021:"c36b7e6b",3085:"1f391b9e",3089:"a6aa9e1f",3514:"73664a40",3608:"9e4087bc",3662:"b76a362f",3689:"c441f7d5",3842:"4317fbf7",4013:"01a85c17",4024:"6fb1fe71",4081:"719b1851",4103:"684aec4d",4173:"3b327884",4195:"c4f5d8e4",4227:"d5decc06",4555:"e0d5b996",4642:"b741a796",5178:"d07f8614",5242:"de1ef56c",5288:"4c9dd493",5307:"f1e6a692",5620:"e9025b0e",5680:"c2f4afbb",6004:"a729c412",6047:"5a59ea68",6103:"ccc49370",6104:"d698a8c5",6189:"91db1580",6677:"2f60f69a",7075:"be00f8f0",7170:"cb227d72",7275:"b4deb335",7414:"393be207",7649:"da286ece",7890:"51f4fcc3",7918:"17896441",7972:"c2d7cd96",8059:"7a337337",8361:"3cc55dcd",8400:"21821687",8558:"1fb8531c",8610:"6875c492",8636:"f4f34a3a",8671:"325c7275",8780:"8facacb8",8793:"403f595d",9003:"925b3f96",9278:"cdace248",9315:"abf58fe5",9402:"64fc4b83",9510:"0ee94099",9514:"1be78505",9642:"7661071f",9721:"3b13db8a",9817:"14eb3368",9959:"f25b6166"}[e]||e)+"."+{46:"42cbb196",53:"cac37dc1",150:"1f95ed27",292:"c01fcc43",380:"d8a93ec4",493:"6470d80e",913:"d8ecb7ca",948:"914d35ec",1028:"23da16a3",1098:"06d2c692",1178:"77bdf4ed",1757:"88e6a440",1914:"8aa602a6",2031:"98e99271",2049:"72893041",2052:"f01ce896",2081:"add750cf",2119:"d79501aa",2213:"7d42604e",2249:"ded78440",2267:"4445c936",2362:"0e41ec1f",2475:"0eff4db0",2529:"36c3bab3",2535:"743a3596",2608:"93fe4de6",2774:"5eaf706e",3021:"eb9b69eb",3085:"b260a6c5",3089:"a59b6240",3514:"a2ef6c76",3608:"fd66296e",3662:"fbd93ba2",3689:"fb308300",3842:"72d345f9",4013:"298b1a20",4024:"1edfdccc",4081:"5489bd4c",4103:"620595e0",4173:"4c384568",4195:"814258f0",4227:"fb746336",4555:"66988315",4642:"e68df027",4972:"71e74212",5178:"7b874a4b",5242:"3c4d2b0b",5288:"791558f2",5307:"1a0ccef4",5620:"a495e7a8",5680:"0277c7b0",6004:"8bb585dc",6047:"4c43887d",6103:"a04a9b88",6104:"4db76e32",6189:"d5c6552e",6316:"e253b8dd",6677:"ab253a10",7075:"3f5f6938",7170:"4bffee7f",7275:"0f7ffc27",7414:"2b6bec03",7649:"af8db11e",7724:"1ce4c8a5",7890:"2e8be81b",7918:"c879fc52",7972:"242bd1f2",8059:"fdddc084",8361:"d7ac881b",8400:"d46fda60",8558:"6ee91e0a",8610:"7dbfa267",8636:"ec4f7a24",8671:"ca7f10df",8780:"af109432",8793:"fbcc0f20",9003:"39c96a76",9278:"98c4f9dd",9315:"edda825d",9402:"8763c510",9487:"1902e0d9",9510:"d97cafc7",9514:"8f5a31ba",9620:"b536c143",9642:"4eb2b4ef",9721:"9606fcc4",9817:"7e910f19",9959:"c6d206b1"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),f={},b="docusaurus:",r.l=(e,a,c,d)=>{if(f[e])f[e].push(a);else{var t,o;if(void 0!==c)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var b=f[e];if(delete f[e],t.parentNode&&t.parentNode.removeChild(t),b&&b.forEach((e=>e(c))),a)return a(c)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/slim/",r.gca=function(e){return e={17896441:"7918",21821687:"8400",59362658:"2267",ca705c4a:"46","935f2afb":"53","32de2db0":"150","1937bb63":"292","22251b09":"380",ed7f1a16:"493","3e49c4e2":"913","8717b14a":"948","51785cc5":"1028","80ba3087":"1178",cd95f078:"1757",d9f32620:"1914","8c4308b7":"2031","2bc4934e":"2049","69878e35":"2052","73e4d764":"2081",c612d4a7:"2119","39680a00":"2213",f26fc996:"2249",e273c56f:"2362","1375824b":"2475","814f3328":"2535",d52baca9:"2608","6d6ba527":"2774",c36b7e6b:"3021","1f391b9e":"3085",a6aa9e1f:"3089","73664a40":"3514","9e4087bc":"3608",b76a362f:"3662",c441f7d5:"3689","4317fbf7":"3842","01a85c17":"4013","6fb1fe71":"4024","719b1851":"4081","684aec4d":"4103","3b327884":"4173",c4f5d8e4:"4195",d5decc06:"4227",e0d5b996:"4555",b741a796:"4642",d07f8614:"5178",de1ef56c:"5242","4c9dd493":"5288",f1e6a692:"5307",e9025b0e:"5620",c2f4afbb:"5680",a729c412:"6004","5a59ea68":"6047",ccc49370:"6103",d698a8c5:"6104","91db1580":"6189","2f60f69a":"6677",be00f8f0:"7075",cb227d72:"7170",b4deb335:"7275","393be207":"7414",da286ece:"7649","51f4fcc3":"7890",c2d7cd96:"7972","7a337337":"8059","3cc55dcd":"8361","1fb8531c":"8558","6875c492":"8610",f4f34a3a:"8636","325c7275":"8671","8facacb8":"8780","403f595d":"8793","925b3f96":"9003",cdace248:"9278",abf58fe5:"9315","64fc4b83":"9402","0ee94099":"9510","1be78505":"9514","7661071f":"9642","3b13db8a":"9721","14eb3368":"9817",f25b6166:"9959"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,c)=>{var f=r.o(e,a)?e[a]:void 0;if(0!==f)if(f)c.push(f[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var b=new Promise(((c,b)=>f=e[a]=[c,b]));c.push(f[2]=b);var d=r.p+r.u(a),t=new Error;r.l(d,(c=>{if(r.o(e,a)&&(0!==(f=e[a])&&(e[a]=void 0),f)){var b=c&&("load"===c.type?"missing":c.type),d=c&&c.target&&c.target.src;t.message="Loading chunk "+a+" failed.\n("+b+": "+d+")",t.name="ChunkLoadError",t.type=b,t.request=d,f[1](t)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,c)=>{var f,b,d=c[0],t=c[1],o=c[2],n=0;if(d.some((a=>0!==e[a]))){for(f in t)r.o(t,f)&&(r.m[f]=t[f]);if(o)var i=o(r)}for(a&&a(c);n Archive | SLIM - +

Archive

Archive

2019

2021

- + \ No newline at end of file diff --git a/blog/first-blog-post/index.html b/blog/first-blog-post/index.html index 8313018f6..b998da020 100644 --- a/blog/first-blog-post/index.html +++ b/blog/first-blog-post/index.html @@ -5,13 +5,13 @@ First Blog Post | SLIM - +

First Blog Post

· One min read
Gao Wei

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

- + \ No newline at end of file diff --git a/blog/index.html b/blog/index.html index eec2654ad..e8c9cf400 100644 --- a/blog/index.html +++ b/blog/index.html @@ -5,13 +5,13 @@ Blog | SLIM - +

· One min read
Sébastien Lorber
Yangshun Tay

Docusaurus blogging features are powered by the blog plugin.

Simply add Markdown files (or folders) to the blog directory.

Regular blog authors can be added to authors.yml.

The blog post date can be extracted from filenames, such as:

  • 2019-05-30-welcome.md
  • 2019-05-30-welcome/index.md

A blog post folder can be convenient to co-locate blog post images:

Docusaurus Plushie

The blog supports tags as well!

And if you don't want a blog: just delete this directory, and use blog: false in your Docusaurus config.

· One min read
Gao Wei

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

- + \ No newline at end of file diff --git a/blog/long-blog-post/index.html b/blog/long-blog-post/index.html index db2cc1adc..c0c3107f0 100644 --- a/blog/long-blog-post/index.html +++ b/blog/long-blog-post/index.html @@ -5,13 +5,13 @@ Long Blog Post | SLIM - +

Long Blog Post

· 3 min read
Endilie Yacop Sucipto

This is the summary of a very long blog post,

Use a <!-- truncate --> comment to limit blog post size in the list view.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

- + \ No newline at end of file diff --git a/blog/mdx-blog-post/index.html b/blog/mdx-blog-post/index.html index 622683d94..83a878564 100644 --- a/blog/mdx-blog-post/index.html +++ b/blog/mdx-blog-post/index.html @@ -5,13 +5,13 @@ MDX Blog Post | SLIM - +
- + \ No newline at end of file diff --git a/blog/tags/docusaurus/index.html b/blog/tags/docusaurus/index.html index e19a86c67..37708119d 100644 --- a/blog/tags/docusaurus/index.html +++ b/blog/tags/docusaurus/index.html @@ -5,13 +5,13 @@ 4 posts tagged with "docusaurus" | SLIM - +

4 posts tagged with "docusaurus"

View All Tags

· One min read
Sébastien Lorber
Yangshun Tay

Docusaurus blogging features are powered by the blog plugin.

Simply add Markdown files (or folders) to the blog directory.

Regular blog authors can be added to authors.yml.

The blog post date can be extracted from filenames, such as:

  • 2019-05-30-welcome.md
  • 2019-05-30-welcome/index.md

A blog post folder can be convenient to co-locate blog post images:

Docusaurus Plushie

The blog supports tags as well!

And if you don't want a blog: just delete this directory, and use blog: false in your Docusaurus config.

· One min read
Gao Wei

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

- + \ No newline at end of file diff --git a/blog/tags/facebook/index.html b/blog/tags/facebook/index.html index abc53bbd2..eb7ac4a7a 100644 --- a/blog/tags/facebook/index.html +++ b/blog/tags/facebook/index.html @@ -5,13 +5,13 @@ One post tagged with "facebook" | SLIM - +

One post tagged with "facebook"

View All Tags

· One min read
Sébastien Lorber
Yangshun Tay

Docusaurus blogging features are powered by the blog plugin.

Simply add Markdown files (or folders) to the blog directory.

Regular blog authors can be added to authors.yml.

The blog post date can be extracted from filenames, such as:

  • 2019-05-30-welcome.md
  • 2019-05-30-welcome/index.md

A blog post folder can be convenient to co-locate blog post images:

Docusaurus Plushie

The blog supports tags as well!

And if you don't want a blog: just delete this directory, and use blog: false in your Docusaurus config.

- + \ No newline at end of file diff --git a/blog/tags/hello/index.html b/blog/tags/hello/index.html index 80ea1744c..aa0a2b41c 100644 --- a/blog/tags/hello/index.html +++ b/blog/tags/hello/index.html @@ -5,13 +5,13 @@ 2 posts tagged with "hello" | SLIM - +

2 posts tagged with "hello"

View All Tags

· One min read
Sébastien Lorber
Yangshun Tay

Docusaurus blogging features are powered by the blog plugin.

Simply add Markdown files (or folders) to the blog directory.

Regular blog authors can be added to authors.yml.

The blog post date can be extracted from filenames, such as:

  • 2019-05-30-welcome.md
  • 2019-05-30-welcome/index.md

A blog post folder can be convenient to co-locate blog post images:

Docusaurus Plushie

The blog supports tags as well!

And if you don't want a blog: just delete this directory, and use blog: false in your Docusaurus config.

- + \ No newline at end of file diff --git a/blog/tags/hola/index.html b/blog/tags/hola/index.html index 77310e71e..5371ca2d4 100644 --- a/blog/tags/hola/index.html +++ b/blog/tags/hola/index.html @@ -5,13 +5,13 @@ One post tagged with "hola" | SLIM - +

One post tagged with "hola"

View All Tags

· One min read
Gao Wei

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

- + \ No newline at end of file diff --git a/blog/tags/index.html b/blog/tags/index.html index e64cac0a7..7b110a416 100644 --- a/blog/tags/index.html +++ b/blog/tags/index.html @@ -5,13 +5,13 @@ Tags | SLIM - +

Tags

- + \ No newline at end of file diff --git a/blog/welcome/index.html b/blog/welcome/index.html index 6a684d7b7..c33a1c59d 100644 --- a/blog/welcome/index.html +++ b/blog/welcome/index.html @@ -5,13 +5,13 @@ Welcome | SLIM - +

Welcome

· One min read
Sébastien Lorber
Yangshun Tay

Docusaurus blogging features are powered by the blog plugin.

Simply add Markdown files (or folders) to the blog directory.

Regular blog authors can be added to authors.yml.

The blog post date can be extracted from filenames, such as:

  • 2019-05-30-welcome.md
  • 2019-05-30-welcome/index.md

A blog post folder can be convenient to co-locate blog post images:

Docusaurus Plushie

The blog supports tags as well!

And if you don't want a blog: just delete this directory, and use blog: false in your Docusaurus config.

- + \ No newline at end of file diff --git a/docs/about/CODE_OF_CONDUCT/index.html b/docs/about/CODE_OF_CONDUCT/index.html index 80e69c272..deecab1a2 100644 --- a/docs/about/CODE_OF_CONDUCT/index.html +++ b/docs/about/CODE_OF_CONDUCT/index.html @@ -5,7 +5,7 @@ Code of Conduct | SLIM - + @@ -59,7 +59,7 @@ Mozilla's code of conduct enforcement ladder.

For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

- + \ No newline at end of file diff --git a/docs/about/GOVERNANCE/index.html b/docs/about/GOVERNANCE/index.html index b9b19d092..dc78ad9f8 100644 --- a/docs/about/GOVERNANCE/index.html +++ b/docs/about/GOVERNANCE/index.html @@ -5,13 +5,13 @@ SLIM Project Governance | SLIM - +

SLIM Project Governance

This governance model aims to create an open source community that encourages transparency, contributions, and collaboration, but maintains sound technical and quality standards. Our goal is to build a community comprised of members across the SLIM community and beyond, including from private organizations, universities, government organizations, and international organizations.

The project follows a fairly liberal contribution model where people and/or organizations who do the most work will have the most influence on project direction. Roles determine decision making influence, and governing committees (e.g. technical steering, project steering) are set up to ensure the project's direction is in-line with requirements / goals while supporting flexibility for future growth and membership. Technical decision making will primarily be made through a "consensus-seeking" approach within the respective governing committees.

Roles​

RoleRestricted ToDescriptionRead/ClonePropose Pull RequestComment in Tickets / DiscussionsTriageReviewCommitTechnical DecisionsProject Decisions
UserNoneAnyone downloading, deploying, or operating the software to meet a specific objective.✅✅✅❌❌❌❌❌
ContributorNoneAnyone providing input to the project, including: code, issues, documentation, graphics, etc.✅✅✅❌❌❌❌❌
TriagerContributorSubset of contributors demonstrating a strong familiarity with the project.✅✅✅✅❌❌❌❌
CollaboratorContributorSubset of contributors granted write access to one or more of the project repositories upon selection by TSC✅✅✅✅✅✅❌❌
Technical Steering Committee MemberCollaboratorA subset of collaborators having technical decision making authority and admin privileges✅✅✅✅✅✅✅❌
Project Steering Committee MemberStakeholdersSponsor organization representatives (i.e. those providing funding to the project) and key stakeholders with authority to guide project based on requirements, budget, schedule, etc.✅✅✅✅✅✅✅✅
Product ManagerStakeholdersOverall manager of project with final authority over all key decisions when consensus cannot be reached✅✅✅✅✅✅✅✅

User​

Anyone who has downloaded, deployed, or operated SLIM to meet a specific objective. This project was primarily designed for developing, iterating, and disseminating software process improvements, but let us know if you've found other uses for it.

Contributor​

Contributors include anyone that provides input to the project. This includes code, issues, documentation, graphics, designs, or anything else that tangibly improves the project. We encourage you to start contributing right away by joining our Discussions or submitting an Issue.

Triager​

Subset of contributors who have demonstrated a strong familiarity with the project and are regularly contributing to the project via issue creation, commenting, discussions, etc. Triagers are given specific permissions do the following:

- Label issues and pull requests
- Comment, close, and reopen issues and pull requests

List of current Triagers

Collaborator​

Subset of contributors who have been given write access to one or more project repositories. Both contributors and collaborators can propose changes to the project via pull requests, but only collaborators can formally review and approve (merge) these requests. Any contributor who has made a non-trivial contribution should be on-boarded as a collaborator in a timely manner.

If you are planning on making a substantial contribution to the project or feel as though you should be given write access to a repository, please send a request to https://github.com/riverma/

List of current collaborators

Technical Steering Committee Member​

A subset of the collaborators forms the Technical Steering Committee (TSC). The TSC has authority over the following aspects of this project:

  • Technical direction and guidance
  • Committee governance and process
  • Contribution policy
  • Conduct guidelines
  • Maintaining the list of collaborators

TSC Committee Members​

Emeriti

TSC Emeriti​

#### Scope

The TSC is primarily responsible for the following project repositories:

However, the TSC also has the responsibility to interface with and monitor third-party dependencies of the project for key changes impacting SLIM. These third-party dependencies include:

  • N/A

Decision Making Process​

Any community member can create an issue or comment asking the TSC to review something. Prior to implementing a substantial contribution, the design of that contribution should be reviewed by at least one member of the TSC. If consensus-seeking fails during the review of a pull request or in design discussions, the issue will be addressed by the TSC to make a determination on direction. TSC members will meet regularly and will keep track of decisions made when consensus was not met.

The TSC can nominate new members at any time. Candidates for membership tend to be collaborators who have shown great dedication to the project and/or experts in a particular domain or project component. TSC members are expected to be active contributors or members who have made significant contributions within the past 12 months.

Project Management Committee (PMC) Member​

The Project Management Committee (PMC) is made up of sponsor organization representatives (i.e. those providing funding to the project) and key stakeholders who rely or plan to rely on the project to meet a critical need. The PMC has the following responsibilities:

  • Maintaining the overall project roadmap
  • Determining project requirements and commitments to sponsors and stakeholders
  • Assessing available resources and allocating them across the project
  • Monitoring and reporting on progress against the roadmap
  • On-boarding new sponsors and stakeholders
  • Overall project governance (including this policy)
  • Addressing any legal considerations

PMC Committee Members​

Emeriti

PMC Emeriti​

Scope​

The PMC has management authority over the same project repositories over which the TSC has technical authority over.

Decision Making Process​

The PMC will consist of a product manager and additional representative from sponsors and key stakeholders. The PMC or sponsoring organizations can nominate new members at any time. Care should be taken not to include too many members from a single stakeholder project or organization.

Regular stakeholder meetings are held to discuss current project status and propose changes to the project roadmap. If stakeholder representatives and sponsors concur with these proposals during the meeting, they will be immediately adopted. A member of the PMC will ensure the changes have been captured and recorded. Regular stakeholder meetings will be open to the entire community, but only members of the PMC have decision making authority.

Additional meetings may be held if consensus is not met or to discuss significant changes to the roadmap due to changes in stakeholder priorities or available resources. Any decision made outside of stakeholder meetings must still be approved by all sponsors and stakeholders. If full consensus cannot be made, the product manager has the final authority to determine project direction. Any non-concurrences from stakeholders or sponsors will be noted.

Product Manager​

Overall manager of the project with final authority over all key decisions when consensus cannot be reached within the TSC or PSC. The product manager is often chosen at the onset of project initiation and can be reassigned by the PMC (with institutional approval, if applicable).

Acknowledgements

Much of this governance model was adapted from the other notable open source projects including node.js, OpenSSL, PostgresQL, and OpenMCT. We would like to thank those projects for setting the foundation upon which this model was built.

- + \ No newline at end of file diff --git a/docs/about/index.html b/docs/about/index.html index c702e2310..18854f64c 100644 --- a/docs/about/index.html +++ b/docs/about/index.html @@ -5,13 +5,13 @@ About | SLIM - +

About

A shared resource for discussing, iterating and referencing best practices in software lifecycle process improvements for multi-mission space and ground software

📖 View our Infographic (PDF)

Software Lifecycle Improvement & Modernization (SLIM) is a project focused on collecting, developing, and disseminating best practices and process improvement strategies in NASA multi-mission software development lifecycle ecosystems. SLIM represents both a community of contributors as well as a continually evolving repository for best practices documentation.

SLIM best practice guides and recommendations are all open source, which means you have the freedom to use our work (in accordance with our permissive LICENSE) as well as contribute and help shape our future work. We're excited to welcome new contributors and users.

Our Focus​

There are three key areas within the software development lifecycle improvement space that SLIM focuses on providing best practice guidance for:

SLIM-scope

Our Process​

1. Ask Our Community​

We reach out to community member projects, and solicit input on outstanding process improvement needs, including the respective needs' relative ranking in importance / criticality. A few needs are chosen to focus active contributor time upon - seeking to develop best practice guides, including items such as use case lists, trade-studies, reference architectures and starter kits. That being said, any external contributors are free to propose best practice guides to our project at any time in the form of a contribution. See our /slim/docs/contribute/submit-best-practice for more details.

You can see our current prioritized list of community-ranked best practice development ideas in our planning board.

2. Develop Standards & Best Practices​

We use a technique we like to call "standards-as-code", which basically means that we develop best practices that are patchable to existing or new community member project codebases or are deployable to their infrastructure. Therefore, we target providing best practices in a way that is most easily can be infused into existing SLIM community member projects. This way, we are actually able to scale out our best practice dissemination widely to many projects at once. For best practices that are not patchable to repositories, we ask our contributors to develop automation that can be run as a script or set of commands - and deploy these to SLIM community members through issue-tickets.

SLIM-dev-process

More information on our development process for best practice guides can be found in our Contributing Guide.

3. Publish Best Practices​

As mentioned above, we operate under a "standards-as-code" philosophy, which means that newly developed standards and best practices are directly infused into member projects through pull requests or issue tickets. This hands-on approach ensures that improvements are easily infusable into the SLIM community member repositories.

To see the current adoption status and how these practices are being integrated into various SLIM community member projects, check out our leaderboard pages:

Our Community Members​

What does it mean to be a community member of SLIM? The following ideas apply to community member projects:

  • Has a representative (a point-of-contact) who interfaces with the SLIM effort
  • Receives pull-requests / issues containing SLIM best practice recommendations
  • Openness and willingness to infuse SLIM best practices
  • Prioritizes contributing back to the SLIM project

The following list of public projects are currently SLIM community members:

NamePoint of Contact (POC)
Advanced Multi-Mission Operations System (AMMOS) Multimission Ground System and Services (MGSS) Instrument Data System (IDS)@PaulMRamirez
Hybrid Science Data System (HySDS)@hookhua
F' (FPrime)@LeStarch
Observational Products for End-Users from Remote Sensing Analysis (OPERA)@riverma
Unity Science Data System (SDS)@mike-gangl
- + \ No newline at end of file diff --git a/docs/category/-governance/index.html b/docs/category/-governance/index.html index 80480f143..ce5bcb11e 100644 --- a/docs/category/-governance/index.html +++ b/docs/category/-governance/index.html @@ -5,13 +5,13 @@ 🏛 Governance | SLIM - +

🏛 Governance

Check out our below list of guides and sub-sections related to governance best practices.

- + \ No newline at end of file diff --git a/docs/category/-information-sharing/index.html b/docs/category/-information-sharing/index.html index 5dc679fd9..a669cf051 100644 --- a/docs/category/-information-sharing/index.html +++ b/docs/category/-information-sharing/index.html @@ -5,13 +5,13 @@ 💬 Information Sharing | SLIM - +

💬 Information Sharing

Check out our below list of guides and sub-sections related to information sharing best practices.

- + \ No newline at end of file diff --git a/docs/category/-software-lifecycle/index.html b/docs/category/-software-lifecycle/index.html index 188f421c8..e6f602c63 100644 --- a/docs/category/-software-lifecycle/index.html +++ b/docs/category/-software-lifecycle/index.html @@ -5,13 +5,13 @@ 🔄 Software Lifecycle | SLIM - +

🔄 Software Lifecycle

Check out our below list of guides and sub-sections related to software lifecycle best practices.

- + \ No newline at end of file diff --git a/docs/category/application-starter-kits/index.html b/docs/category/application-starter-kits/index.html index 9e42ddbbd..2df9bd4be 100644 --- a/docs/category/application-starter-kits/index.html +++ b/docs/category/application-starter-kits/index.html @@ -5,13 +5,13 @@ Application Starter Kits | SLIM - +

Application Starter Kits

Check out our below list of guides on language-specific application starter kits / repository templates.

- + \ No newline at end of file diff --git a/docs/category/contributions/index.html b/docs/category/contributions/index.html index 21a466da1..3786b5e77 100644 --- a/docs/category/contributions/index.html +++ b/docs/category/contributions/index.html @@ -5,13 +5,13 @@ Contributions | SLIM - +

Contributions

Contributing Best Practices.

- + \ No newline at end of file diff --git a/docs/category/security/index.html b/docs/category/security/index.html index 186c1182c..69e5459e9 100644 --- a/docs/category/security/index.html +++ b/docs/category/security/index.html @@ -5,13 +5,13 @@ Security | SLIM - +

Security

Security Best Practices.

- + \ No newline at end of file diff --git a/docs/contribute/contributing/development-process/index.html b/docs/contribute/contributing/development-process/index.html index 422e22eb8..af974ddfa 100644 --- a/docs/contribute/contributing/development-process/index.html +++ b/docs/contribute/contributing/development-process/index.html @@ -5,13 +5,13 @@ Our Development Process | SLIM - +

Our Development Process

Our project integrates contributions from many people, and so we'd like to outline a process you can use to visualize how your contributions may be integrated if you provide something.

Fork our Repository​

Forking our repository, as opposed to directly committing to a branch is the preferred way to propose changes.

See this GitHub guide on forking for information specific to GitHub.com

Find or File an Issue​

Make sure people are aware you're working on a patch! Check out our issue tracking system and find an open issue you'd like to work against, or alternatively file a new issue and mention you're working on a patch.

Choose the Right Branch to Fork​

Our project typically has the following branches available, make sure to fork either the default branch or a branch someone else already tagged with a particular issue ticket you're working with.

  • main - default branch, and contains mature SLIM deliverables and should be the typical branch you fork
  • gh-pages - live rendering of SLIM website, auto-generated by changes committed to main branch via a GitHub Action

Make your Modifications​

Within your local development environment, this is the stage at which you'll propose your changes, and commit those changes back to version control. See the README.md or development guide for more specifics on what you'll need as prerequisites to setup your local development environment.

Commit Messages​

Commit messages to version control should reference a ticket in their title / summary line:

Issue #248 - Show an example commit message title

This makes sure that tickets are updated on GitHub with references to commits that are related to them.

Commit should always be atomic. Keep solutions isolated whenever possible. Filler commits such as "clean up white space" or "fix typo" should be merged together before making a pull request, and significant sub-feature branches should be rebased to preserve commit history. Please ensure your commit history is clean and meaningful!

Additionally, remember to "Sign-Off" on your commits to align with our Developer Certificate of Origin (DCO) policy.

Submit a Pull Request​

Pull requests are the core way our project will receive your patch contributions. Navigate to your branch on your own fork within the version control system, and submit a pull request or submit the patch text to our project.

Please make sure to provide a meaningful text description to your pull requests, whenever submitted. Our pull-request template will be auto-generated for you when you create your pull-request. See the template here.

Working on your first Pull Request? See guide: How to Contribute to an Open Source Project on GitHub

Reviewing your Pull Request​

Reviewing pull-requests, or any kinds of proposed patch changes, is an art. That being said, we follow the following best practices:

  • Intent - is the purpose of your pull-request clearly stated?
  • Solution - is your pull-request doing what you want it to?
  • Correctness - is your pull-request doing what you want it to correctly?
  • Small Patches - is your patch of a level of complexity and brevity that it can actually be reviewed by a human being? Or is does it involve too much content for one pull request?
  • Coding best practices - are you following best practices in the coding / contribution language being used?
  • Readability - is your patch readable, and ultimately maintainable, by others?
  • Reproducibility - is your patch reproducible by others?
  • Tests - do you have or have conducted meaningful tests?
- + \ No newline at end of file diff --git a/docs/contribute/contributing/index.html b/docs/contribute/contributing/index.html index b88a41674..2e6e32054 100644 --- a/docs/contribute/contributing/index.html +++ b/docs/contribute/contributing/index.html @@ -5,13 +5,13 @@ Contributing 101 | SLIM - +

Contributing 101

Thanks for taking the time to consider contributing! We very much appreciate your time and effort. This document outlines the many ways you can contribute to our project, and provides detailed guidance on best practices. We look forward to your help!

- + \ No newline at end of file diff --git a/docs/contribute/contributing/introduction/index.html b/docs/contribute/contributing/introduction/index.html index e28789f5f..307143268 100644 --- a/docs/contribute/contributing/introduction/index.html +++ b/docs/contribute/contributing/introduction/index.html @@ -5,13 +5,13 @@ Introduction | SLIM - +

Introduction

SLIM is a joint, community-based effort at collective software process improvements. Therefore, we need your help! Here's the basics on contributing:

  • Anyone can contribute!
  • You can contribute at any time
  • You can contribute in any way (code, documentation, discussion topics, issue ticket discussions, etc.)

We plan out our work into fiscal quarters (i.e. Oct - Dec as Q1, Jan - Mar as Q2, etc.). This helps our stakeholders (the folks using our process improvements) plan to incorporate process improvements better into their schedules. See our Planning Board for our most up-to-date plan. Generally speaking, we try to get together with our stakeholders and our community contributors at the start of every fiscal quarter to plan out what we should work on. That being said, since we're an open source project, we also accept and encourage ad-hoc contributions at any time - just note it may take some time to review / decide whether to incorporate.

- + \ No newline at end of file diff --git a/docs/contribute/contributing/know-before-contribute/index.html b/docs/contribute/contributing/know-before-contribute/index.html index d801506c9..74a3b4a81 100644 --- a/docs/contribute/contributing/know-before-contribute/index.html +++ b/docs/contribute/contributing/know-before-contribute/index.html @@ -5,13 +5,13 @@ Know Before you Contribute | SLIM - +

Know Before you Contribute

Before you begin contributing to our project, it'll be a good idea to ensure you've satisfied the below pre-requisites.

License​

Our project has our licensing terms, including rules governing redistribution, documented in our LICENSE file. Please take a look at that file and ensure you understand the terms. This will impact how we, or others, use your contributions.

Code of Conduct​

Our Code of Conduct helps facilitate a positive interaction environment for everyone involved with the team, and provides guidance on what to do if you experience problematic behavior. Read more in our CODE_OF_CONDUCT.md, and make sure you agree to its terms.

Developer Environment​

For patch contributions, see our Developer Documentation (TBD) for more details on how to set up your local environment, to best contribute to our project.

At a minimum however to submit patches (if using Git), you'll want to ensure you have:

  1. An account on the Version Control System our project uses (i.e. GitHub).
  2. The Version Control System client (i.e. Git) installed on your local machine.
  3. The ability to edit, build, and test our project on your local machine. Again, see our README.md or detailed developer guide for more details

Communication Channels​

Before contributing changes to our project, it's a great idea to be familiar with our communication channels and to socialize your potential contributions to get feedback early. This will help give you context for your contributions, no matter their form.

Our communication channels are:

  • Issue tracking system - a regularly monitored area to report issues with our software or propose changes
  • Discussion board - an permanently archived place to hold conversations related to our project, and to propose as well as show+tell topics to the contributor team. This resource can be searched for old discussions.
- + \ No newline at end of file diff --git a/docs/contribute/contributing/ways-to-contribute/index.html b/docs/contribute/contributing/ways-to-contribute/index.html index 71842f414..29e7cb315 100644 --- a/docs/contribute/contributing/ways-to-contribute/index.html +++ b/docs/contribute/contributing/ways-to-contribute/index.html @@ -5,13 +5,13 @@ Ways to Contribute | SLIM - +

Ways to Contribute

📖 Best Practice Guides​

Please see our Submit a Best Practice Guide for more details.

⚠️ Issue Tickets​

Do you like to talk about new features, changes, requests?

Issue tickets are a very simple way to get involved in our project. It also helps new contributors get an understanding of the project more comprehensively. This is a great place to get started with the project if you're not sure where to start.

See our list of issues at: https://github.com/NASA-AMMOS/slim/issues

Cleaning up Duplicate Issues​

Often we receive duplicate issues that can confuse project members on which issue ticket to hold conversations upon.

Here's how you can help:

  1. Scan the list of open issue tickets for duplicate titles, or internal wording
  2. If you find duplicates, copy / paste the below message on the conversation thread of the issue ticket that has less participants involved
This is a duplicate issue. Please migrate conversations over to [issue-XYZ](hyperlink to issue)

Good First Issues​

Issue tickets can vary in complexity, and issues labeled with good first issue labels are often a great way to get started with the project as a newcomer.

Take a look at our issue tracking system, and filter by good first issue for issues that are low-complexity, and that will help you get familiar with our issue tracking and patch submission process.

Suggesting New Issue Labels​

Labels within our issue tracking system are a great way to quickly sort through tickets. The project may not yet have labels to cover the full variety of issue tickets. Take a look through our list of issues, and if you notice a set of issue tickets that seem similar but are not categorized with an existing label, go ahead submit a request within one of the issues you've looked at with the following text:

I've noticed several other issues that are of the same category as this issue. Shall we make a new label for these types of issues?

Submitting Bug Issues​

Resolving bugs is a priority for our project. We welcome bug reports. However, please make sure to do the following prior to submitting a bug report:

  • Check for duplicates - there may be a bug report already describing your issue, so check the issue tracking system first.

Here's some guidance on submitting a bug issue:

  1. Navigate to our issue tracking system and file a new issue
  2. Select a bug template (if available) for your issue
    1. Fill out the template fields to the best of your ability, including output snippets or screenshots where applicable
  3. Follow the general guidelines below for extra information about your bug
    1. Include a code snippet if you have it showcasing the bug
    2. Provide reproducible steps of how to recreate the bug
    3. If the bug triggers an exception or error message, include the full message or stacktrace
    4. Provide information about your operating system and the version of our project you're using

📀 Media​

Media, such as such as images, videos, sound files, etc., are an excellent way to explain documentation to a wider audience more easily. Include media in your contributions as often as possible.

When including media into our version-control system, it is recommended to use formats such as:

  • Diagrams: Mermaid format
  • Images: JPEG format
  • Videos: H264 MPEG format
  • Sounds: MP3 format

❓ Questions​

Answering questions is an excellent way to learn more about our project, as well as get better known in our project community.

Here are just a few ways you can help answer questions for our project:

When answering questions, keep the following in mind:

  • Be polite and friendly. See our Code of Conduct recommendations as you interact with others in the team.
  • Repeat the specific question you are answering, followed by your suggestion.
  • If suggesting code, repeat the line of code that needs to be altered, followed by your alteration
  • Include any post-steps or checks to verify your answer can be reproduced

🎨 Design​

Design files can help to guide new features and new areas of expansion for our project. We welcome these kinds of contributions.

Here are just a few ways you can help provide design recommendations for our project:

  • Create visual mockups or diagrams to increase usability of our project applications. This can apply to user interfaces, documentation structuring, or even code architecture diagrams.
  • Conduct user research to understand user needs better. Save your findings within spreadsheets that the project team / contributors can review.
  • Create art, such as logos or icons, to support the user experience for the project

Each of the above can be contributed directly to repository code, and you should use our development process to contribute your additions.

🎟️ Meetups​

A great way to contribute towards our project goals is to socialize and encourage people to meet and learn more about each other. Consider ideas like:

  • Propose workshops or meetups regarding some topic within our project
  • Help point project contributors and community members to conferences and publications where they may socialize their unique innovations
  • Schedule in-person or virtual happy-hours to help create a more social atmosphere within the project community

For the above ideas, use our communication channels to propose get-togethers.

- + \ No newline at end of file diff --git a/docs/contribute/submit-best-practice/index.html b/docs/contribute/submit-best-practice/index.html index 912df05ad..3a5c47335 100644 --- a/docs/contribute/submit-best-practice/index.html +++ b/docs/contribute/submit-best-practice/index.html @@ -5,13 +5,13 @@ Submit a Best Practice Guide | SLIM - +

Submit a Best Practice Guide

Are you interested in submitting a best practice guide to the SLIM project? You've come to the right place!

Below, we outline the important steps involved - including things like making a ticket, making your contribution, and reviewing / disseminating it.

See Our Process for a high-level overview of how SLIM best practice guides are developed. We use the open source contribution model to ideate, develop, review, and disseminate best practice guides and standards.

1⃣️ Find or Make a Ticket​

The first step in making a contribution to SLIM is to make or select a ticket. This is important so that you don't inadvertently duplicate work that's already done / being done and help communicate your idea with the community. Also, not every best practice solution is appropriate for SLIM; therefore, its always a good idea to talk to the community first before you make a pull request.

To create an issue for the NASA-AMMOS/slim repository:

  1. Go to NASA-AMMOS/slim on GitHub
  2. Click on the "Issues" tab
  3. Select "New issue" > appropriate template (e.g., "New Best Practice Guide", "Improve an Existing Best Practice Guide", or "New Process Improvement Need")
    • NOTE: the "New Process Improvement Need" ticket type is intended for documenting needs only, rather than solution ideas.
  4. Enter a concise title and fill out the template
  5. Add labels and screenshots as relevant
  6. Review and click on "Submit new issue"
  7. Engage in discussions on the ticket if needed

Follow GitHub best practices: be clear and concise.

2⃣️ Initialize a Draft Pull Request​

To submit your solution to the NASA-AMMOS/slim repository follow the below steps. Note: we highly recommend iterating a draft pull request rather than issuing a pull request after you've already written up a guide - the SLIM community can provide much better feedback as you iterate! We also recommend making a fork for the SLIM repository to ensure you can demo your guide easily from your own GitHub account when the guide is ready.

  1. Fork NASA-AMMOS/slim
  2. Clone your fork (git clone https://github.com/YourUsername/slim.git) on your local machine
  3. Use the main branch on your fork - this allows you to host a copy of, and demo the SLIM website at https://<your-username>.github.io/slim
  4. Develop, iterate and commit your solution as it grows (see Step 3 below Develop Your Contribution)
  5. Within your fork, click the "Contribute" button, choose to submit a pull request and fill in details and reference any related issues. Consider keeping your a pull request a draft pull request while you iterate so the community knowns you're still working on the contribution.
  6. Address review feedback promptly and iterate as needed. Once your pull request is finalized, ensure it is no longer in "draft" mode. A SLIM collaborator and reviewer will help you finalize and get your contribution merged if possible.
  7. Keep your fork synchronized with the original repo using git fetch upstream and git merge upstream/main

3⃣️ Develop Your Contribution​

When developing your contribution to the NASA-AMMOS/slim repository, consider the following sub-sections:

Think about Automation​

To make it easier for users to adopt your best practice solution, consider presenting it as templates, software automation, or starter kits. This approach allows users to quickly implement your best practice in production. By providing automated tools or templates, you can streamline the adoption process and increase the likelihood of successful implementation.

Read more about our automation philosophy in Develop Standards & Best Practices.

Adhere to Folder Structure​

To maintain organization and consistency within the repository, create a new folder for your best practice guide. Place this folder within the appropriate sub-folder in the docs/guides directory of the NASA-AMMOS/slim repository. Ensure that the folder structure aligns with the type of best practice you are developing, allowing users to easily locate and reference your guide.

For example, if you were to add a new best practice guide related to software-lifecycle security, you'd create a new folder called "my-security-guide" in the below directory:

docs/
├── about
├── contribute
└── guides
    ├── documentation
    ├── search.md
    └── software-lifecycle
        ├── application-starter-kits
        ├── continuous-integration
        ├── continuous-testing
        └── security
            ├── README.md
            ├── dependabot
            ├── secrets-detection
            └── my-security-guide
                └── README.md
                └── other-file.txt
                └── other-file.json
                └── other-file.jpg

Use our Standard Guide Template​

To maintain uniformity and ease of understanding, contributors are urged to utilize the below template when submitting their best practice guides. This structured format ensures clarity, beginning with a concise title and a one-liner description to capture the essence of the proposal. The Introduction sets the context, Prerequisites identify essential tools or knowledge, and the Step-by-Step Guide offers a methodical walkthrough, enhanced optionally with illustrative images. An FAQ section addresses potential queries, and appropriate credits acknowledge contributors and inspirations. This standard layout not only ensures that each guide retains consistency and comprehensibility, but it also facilitates smoother automation and integration within the SLIM ecosystem.

Directions:

  • Create a new Markdown file for your guide (sample below) and call it README.md. Its advised to create a new folder for your best practice, where you can include multiple files, templates, and miscellaneous files if needed. See the above "Adere to Folder Structure" section.
  • Copy/paste the below template into the file
  • Fill in the guide with your contents
# _Title Goes Here_

<pre align="center">One sentence description of your best practice solution.</pre>

## Introduction

**Background**: _A longer description of the problem you aim to solve and your solution. Talk about the background of why this is needed, what kind of benefits the user might enjoy, and any other background information that may be useful for the reader. Additionally, talk about the expected outcome the user can expect in implementing your solution._

**Use Cases**:
- _A list of the types of use cases where your process improvement solution will shine_
- _e.g. Making code repository README's consistent for internal and external contributors_
  
---

## Prerequisites
_List any software, hardware, or skills required to utilize the solution._

* Prerequisite 1
* Prerequisite 2
* ...

---

## Quick Start
**[Link to Process Improvement Solution (template/code sample/tool/etc.)](#)**

_A brief description of what the link provides, e.g., "Click the link above to access the full template for the README.md file."_

---

## Step-by-Step Guide

1. **Step 1**: _Brief description of the step._
![Optional Image for Step 1](imageURL_for_step1)

2. **Step 2**: _Brief description of the step._
![Optional Image for Step 2](imageURL_for_step2)

3. ...
   
---

## Frequently Asked Questions (FAQ)

- Q: Example question relevant to this guide
- A: Example answer to the question

---

## Credits 

**Authorship**:
- _List of contributing authors of this write-up who actually wrote words. Link to GitHub profiles if available, e.g. [Bugs Bunny](https://www.github.com/bbuny573429)_

**Acknowledgements**:
* Source/Organization 1 that inspired the solution or was adapted from 
* Source/Organization 2 that inspired the solution or was adapted from 
* ...
  
---

## Feedback and Contributions

We welcome feedback and contributions to help improve and grow this page. Please see our [contribution guidelines](https://nasa-ammos.github.io/slim/docs/contribute/contributing/).

Add Entry to the Registry​

To document metadata about your best practice and have your best practice show up in our search page, add a JSON entry to the file data/slim-registry.json within the NASA-AMMOS/slim repository. Fill out the following fields in the example below:

{
  "title": "README.md",
  "uri": "/docs/guides/documentation/readme",
  "category": "documentation",
  "description": "A template that can be used to help developers and users understand your repository's project code concisely and clearly.",
  "tags": [
    "documentation",
    "repository-setup",
    "project-template"
  ],
  "last-updated": "2023-04-27"
}

Customize the fields according to your best practice guide. This entry will serve as a reference for users and allow them to discover your contribution through the registry. Make sure to include relevant and accurate information to help users understand the purpose and benefits of your best practice guide.

4⃣️ Get Feedback For Your Contribution​

Once you've created a contribution you're happy about, it's important to gather feedback from the SLIM community. This will help ensure that your contribution aligns with the project's standards and meets the community's needs.

First ensure your pull-request is ready for review:

  1. Ensure your contribution is viewable via https://<your-username>.github.io/slim. You may need to visit your Settings page for the repository and the "Pages" sub-section to configure GitHub Pages hosting. This should be automatically set up for you, but if you need help troubleshooting please visit Docusaurus' Deploying to GitHub Pages.
  2. Within your fork (created in step 2 above) on GitHub.com, click the "Contribute" button. Choose to submit a pull request and fill in details and reference any related issues. Provide a link to the live, demo website guide page on your fork!

It's now important to request feedback from the community. To request feedback, you can do the following:

  • SLIM Reviewers: Tag @slim-community or @slim-committers in your pull request for feedback for faster responses.

  • Slack/E-mail/Discussions: Post a message in the Slack channels, over e-mail, or other mediums. Use the provided template below as a guide for your message. Don't forget to include a link to your pull request or issue for easy reference.

    As part of the Software Lifecycle Improvement & Modernization (SLIM) project, we’ve recently created a pull request (PR) introducing best practices for [INSERT GUIDE NAME HERE]. The goal is to [INSERT BRIEF GOAL HERE].

    **Purpose of this Message:**
    I'm reaching out to you all to get your thoughts on [INSERT GUIDE NAME HERE] for the SLIM project.
    The goal for the guide is to [INSERT BRIEF GOAL STATEMENT HERE].

    **Proposal Details:**
    Pull Request: [INSERT PULL REQUEST URL HERE]
    Live Demo Here: [INSERT URL TO YOUR LIVE DEMO OF THE PROPOSED GUIDE (USUALLY ON YOUR GITHUB FORK)]

    **Your Input Matters:**
    Your comments and insights would be extremely valuable. Please consider adding a comment to the PR about your thoughts!
    Thank you in advance for your support and feedback!

Feedback from the community is crucial for the refinement of your contribution and ensures its successful integration into the SLIM project.

5⃣️ Merge Your Contribution​

The final step in the contribution process involves the review and potential merging of your pull request by SLIM committers and reviewers. This process includes:

  1. Review by SLIM Committers and Reviewers: Your pull request will be thoroughly reviewed by the project's committers and reviewers. They will provide feedback, suggest improvements, or approve the changes.

  2. Iterate as Required: Based on the feedback, you may need to make further adjustments to your contribution. Promptly addressing these suggestions is crucial for the progression of your pull request.

  3. Final Decision: Once your pull request meets all the criteria and standards of the SLIM project, the committers will decide to merge your contribution into the main branch. Alternatively, they might request additional changes if needed.

This process ensures that every contribution is in line with the project's goals, standards, and quality expectations, contributing to the overall excellence and reliability of the SLIM project.

- + \ No newline at end of file diff --git a/docs/guides/checklist/index.html b/docs/guides/checklist/index.html index fe9603061..a8dfe4b03 100644 --- a/docs/guides/checklist/index.html +++ b/docs/guides/checklist/index.html @@ -5,7 +5,7 @@ ✅ Getting Started | SLIM - + @@ -13,7 +13,7 @@

✅ Getting Started

We have numerous guides and recommendations on this website. You are free to explore and take what you find most helpful. However, if you're looking for more guidance on how to bring together SLIM's recommendations for your project in an aggregated form, you've come to the right place.

Checklist​

Here we present a checklist you can run through for your project, as well as links to automation / guides to make your project ready with the best of SLIM.

Review your project's repositories, and ensure all have the following (in prioritized order):

Checklist ItemWhy?
✅ LICENSESpell out legal terms for software usage & modification
✅ READMEProvide project overview, setup, & usage instructions
✅ Contributing GuideOutline how to contribute & the process for submissions
✅ Code of ConductEstablish community behavior standards
✅ Issue TemplatesStreamline issue reporting for consistency & clarity
✅ Pull Request TemplatesEnsure PRs are comprehensive & adhere to project standards
✅ DocumentationOffer detailed info on features, APIs, & customizations not covered in README
✅ Change LogKeep track of all notable changes in each version in a human-readable format
✅ Security & Dependency ScanningIdentify vulnerabilities & outdated dependencies for security
✅ Sensitive Information ScanningDetect accidental commits of sensitive info
✅ Governance ModelDefine decision-making structure & project leadership for transparency & organization
✅ Software MetricsCollect metrics on performance of your software's governance and lifecycle

Repository Starter Kit​

If you're starting a new project / repository, you can automatically get many of the above set up quickly using our:

🌐 Repository Starter Kit

There's two ways to use the Repository Starter Kit:

Using our Template Repository​

  1. Navigate to the Starter Kit: Go to the SLIM Repository Starter Kit on GitHub.
  2. Create Your Repository: Click the "Use this template" button at the top right of the GitHub repository page. GitHub Use Template Button Example screenshot of button to click.
  3. Set Up Your New Repository: Fill in the Repository name and description for your new project. Decide whether your repository will be public or private. Click "Create repository from template".
  4. Customize Your Repository: After creation, go through your new repository and look for files containing the [INSERT ...] text. These are placeholders for you to replace with information specific to your project. This includes project name, description, contributing guidelines, etc.
  5. Push Changes: Once you've made your customizations, commit and push the changes to your repository to ensure all your project information is up to date.

Manually Cloning and Using the Template​

If you prefer to set up your project manually or need more control over the initial setup, follow these steps:

  1. Clone the Starter Kit:

    • Open your terminal or command prompt.
    • Navigate to the directory where you want your project to be.
    • Clone the repository using:
      git clone https://github.com/nasa-ammos/slim-starterkit.git YOUR_PROJECT_NAME
    • Replace YOUR_PROJECT_NAME with the desired name of your project folder.

  2. Navigate to Your Project Directory:

    cd YOUR_PROJECT_NAME

  3. Remove the Git History and start fresh:

    rm -rf .git
    git init

  4. Customize Your Project: Go through the cloned files and modify any [INSERT ...] placeholders with information relevant to your project. This step is crucial for tailoring the starter kit to your specific project needs.

  5. Initial Commit:

    • Add all the files to your new git repository:
      git add .
    • Commit the changes:
      git commit -m "Initial commit with SLIM Repository Starter Kit"

  6. Create a New Repository on GitHub (or your preferred Git hosting service) without initializing it with a README, .gitignore, or license since your project already contains these files.

  7. Link Your Local Repository to GitHub:

    • Follow the instructions provided by GitHub to push an existing repository from the command line, which will include:
      git remote add origin <repository-URL>
      git branch -M main
      git push -u origin main

  8. Push Your Changes: Ensure all your customizations and initial setup are pushed to your remote repository.

By following these steps, you'll have a new project set up with best practices in repository setup, including a LICENSE, README, contributing guide, and more. Remember to keep your project information up to date and regularly review the repository for any updates to the starter kit that might be beneficial to your project.

- + \ No newline at end of file diff --git a/docs/guides/documentation/change-log/index.html b/docs/guides/documentation/change-log/index.html index 0fbe89690..22fd25ece 100644 --- a/docs/guides/documentation/change-log/index.html +++ b/docs/guides/documentation/change-log/index.html @@ -5,13 +5,13 @@ Change Log | SLIM - +

Change Log

A guide for setting up a log to document software changes in a human-centric format.

changelog-screenshot-example

Example CHANGELOG.md template rendering

Introduction​

Background: A change log is a vital tool for documenting significant changes in software over time in a format accessible to humans. It plays a critical role in conveying the evolution of software, including additions, deprecations, and removals. This guide outlines the best practices for maintaining a CHANGELOG.md file, complementing release pages and enhancing software distribution transparency.

Use Cases:

  • Documenting software changes for easy understanding and tracking.
  • Enhancing transparency in software development and release cycles.
  • Storing the history of significant changes independent of code hosts like GitHub.com

Prerequisites​

  • Familiarity with semantic versioning and release cycles.
  • Basic knowledge of Markdown formatting.

Quick Start​

⬇️ Keep a Changelog (see example)

Download a template for creating a human-readable change log for your software project.

Step-by-Step Guide​

  1. Team Agreement: Discuss the importance of a change log with your team, emphasizing its value for transparency and communication.
  2. Creating the Change Log:
    • Start a CHANGELOG.md in your repository.
    • See demo use of the templates like Demo 1 or Demo 2 as a base.
    • Customize the file with your project's release information.
  3. Integrating with Project Documentation:
    • Link to the CHANGELOG.md from your project’s README.md to enhance visibility.

Frequently Asked Questions (FAQ)​

  • Q: Why is a CHANGELOG.md crucial even if there's a GitHub auto-generated release changes page?
  • A: It ensures future-proof accessibility of change information, especially for users who may not have access to the project's release page or if the software has changed hands. Moreover, its meant to be feature-centric and designed for people to understand, rather than GitHub's commit-oriented change reports.

Credits​

Authorship:

Acknowledgements:

  • This guide draws from the "Keep a Changelog" standard and examples from various open source projects.

Feedback and Contributions​

Feedback and contributions are encouraged to refine this guide. See our contribution guidelines.

- + \ No newline at end of file diff --git a/docs/guides/documentation/documentation-hosts/index.html b/docs/guides/documentation/documentation-hosts/index.html index 5148bf625..8d2ae020c 100644 --- a/docs/guides/documentation/documentation-hosts/index.html +++ b/docs/guides/documentation/documentation-hosts/index.html @@ -5,13 +5,13 @@ Documentation Hosting | SLIM - +

Documentation Hosting

Guidance on selecting and implementing documentation hosting tools.

docs-screenshot-example

Example documentation hosts (no endorsement implied)

Introduction​

Background: Choosing the right platform for hosting various types of documentation is crucial for project success. This guide explores use cases for different documentation types and recommends tools for hosting user, developer, admin, API docs, and more, aiding in informed decision-making for documentation management.

Use Cases:

  • Hosting user, admin, developer, and API documentation.
  • Selecting appropriate platforms for different documentation needs.
  • Ensuring accessible and maintainable documentation for a variety of audiences.

Prerequisites​

  • Understanding of different types of documentation and their requirements.
  • Familiarity with various documentation hosting platforms and frameworks.

Quick Start​

📔 Documentation Use Cases and Hosting Tools

See various use cases and then select corresponding tools for hosting different types of documentation.

📔 Trade Study on Hosting Frameworks

View a trade-study of documentation hosting tools that we recommend.

Step-by-Step Guide​

  1. Identify Documentation Needs: Assess your project's documentation requirements based on use cases. For use case mapping, consult our Documentation Use Cases and Hosting Tools document.
  2. Choose Appropriate Tools: Refer to the Trade Study on Hosting Frameworks to select the right tools for your documentation type based on features.
  3. Implement and Maintain: Set up your chosen documentation platforms and ensure they are regularly updated and maintained.

Frequently Asked Questions (FAQ)​

  • Q: How do I choose the right platform for hosting my project's documentation?
  • A: Consider the type of documentation (user, admin, developer, API), the audience, and the specific features offered by the hosting platforms.

Credits​

Authorship:

Feedback and Contributions​

Feedback and contributions are welcome to enhance this guide. Visit our contribution guidelines.

- + \ No newline at end of file diff --git a/docs/guides/documentation/documentation-hosts/trade-study-hostingdocs-user/index.html b/docs/guides/documentation/documentation-hosts/trade-study-hostingdocs-user/index.html index 4ed382987..a384fbe71 100644 --- a/docs/guides/documentation/documentation-hosts/trade-study-hostingdocs-user/index.html +++ b/docs/guides/documentation/documentation-hosts/trade-study-hostingdocs-user/index.html @@ -5,13 +5,13 @@ Docs Hosting Trade Study | SLIM - +

Docs Hosting Trade Study

Tool NameLicensingRender TimeVCS Stored ContentSelf-HostingManaged HostingAPI ActionsGenerate API DocsWYSIWYG EditingMarkdown SupportEmbedded ContentHierarchial StructureTemplating SupportRolesComment SupportSearchImport From Other FormatsExport Other FormatsAnchor LinksDraft ContentVersion ControlInternationalizationFile UploadsDiagram EditingUsage AnalyticsExtension Support
GitBookFree for OSS / $$$FastYesNoYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesNoYesNo
ConfluenceFree for OSS / $$SlowNoNoYesYesNo (only non-free plugins)YesPartial (for embedded content)YesYesYesYesYesYesYesYesYesYesYesNoYesNo (only non-free plugins)No (non-free plans only)Yes
ReadTheDocsFree (with ads)SlowYesNoYesYesNoNoYesYesYesYesYesNoYesLimitedYesYesNoYes including doc packagesYesNo (embed/links only)Yes (with plugins)YesYes
mdBookFree (Mozilla Public License 2.0)FastYesYesNo (static hosts only)NoNoNoYesNoYesYesNoNoYesNoNoYesNoYesNoNo (embed/links only)Yes (as a preprocessor)No (third-party only)Yes
DocusaurusFree MIT LicenseFastYesYesYes (with static site hosts like Vercel, Netlify)NoYes (with plugins)NoYesYesYesYesNoNoYesNoNo (but can be done with external tools)YesNoNoYesNo (embed/links only)Yes (with plugins)No (third-party only)Yes
DocsifyFree MIT LicenseFastYesYesYes (with static site hosts like GitHub Pages, Netlify)NoNoNo (Markdown-based)YesYesYesNoNoNoYes (with plugins)NoNoYesNoNoNoNo (embed/links only)Partial (with plugins)No (third-party only)Yes
- + \ No newline at end of file diff --git a/docs/guides/documentation/documentation-hosts/use-cases/index.html b/docs/guides/documentation/documentation-hosts/use-cases/index.html index cc29082a1..b4b1d33e3 100644 --- a/docs/guides/documentation/documentation-hosts/use-cases/index.html +++ b/docs/guides/documentation/documentation-hosts/use-cases/index.html @@ -5,13 +5,13 @@ Docs Use Cases | SLIM - +

Docs Use Cases

- + \ No newline at end of file diff --git a/docs/guides/documentation/readme/README-TEMPLATE/index.html b/docs/guides/documentation/readme/README-TEMPLATE/index.html index d99b5f2c2..9e4174c59 100644 --- a/docs/guides/documentation/readme/README-TEMPLATE/index.html +++ b/docs/guides/documentation/readme/README-TEMPLATE/index.html @@ -5,13 +5,13 @@ README Template | SLIM - +

README Template

<!-- Header block for project -->
<hr>

<div align="center">

[INSERT YOUR LOGO IMAGE HERE (IF APPLICABLE)]
<!-- ☝️ Replace with your logo (if applicable) via ![](https://uri-to-your-logo-image) ☝️ -->
<!-- ☝️ If you see logo rendering errors, make sure you're not using indentation, or try an HTML IMG tag -->

<h1 align="center">[INSERT YOUR REPO / PROJ NAME HERE]</h1>
<!-- ☝️ Replace with your repo name ☝️ -->

</div>

<pre align="center">[INSERT A SINGLE SENTENCE DESCRIBING THE PURPOSE OF YOUR REPO / PROJ]</pre>
<!-- ☝️ Replace with a single sentence describing the purpose of your repo / proj ☝️ -->

<!-- Header block for project -->

[INSERT YOUR BADGES HERE (SEE: https://shields.io)] [![SLIM](https://img.shields.io/badge/Best%20Practices%20from-SLIM-blue)](https://nasa-ammos.github.io/slim/)
<!-- ☝️ Add badges via: https://shields.io e.g. ![](https://img.shields.io/github/your_chosen_action/your_org/your_repo) ☝️ -->

[INSERT SCREENSHOT OF YOUR SOFTWARE, IF APPLICABLE]
<!-- ☝️ Screenshot of your software (if applicable) via ![](https://uri-to-your-screenshot) ☝️ -->

[INSERT MORE DETAILED DESCRIPTION OF YOUR REPOSITORY HERE]
<!-- ☝️ Replace with a more detailed description of your repository, including why it was made and whom its intended for.  ☝️ -->

[INSERT LIST OF IMPORTANT PROJECT / REPO LINKS HERE]
<!-- example links>
[Website](INSERT WEBSITE LINK HERE) | [Docs/Wiki](INSERT DOCS/WIKI SITE LINK HERE) | [Discussion Board](INSERT DISCUSSION BOARD LINK HERE) | [Issue Tracker](INSERT ISSUE TRACKER LINK HERE)
-->

## Features

* [INSERT LIST OF FEATURES IMPORTANT TO YOUR USERS HERE]
  
<!-- ☝️ Replace with a bullet-point list of your features ☝️ -->

## Contents

* [Quick Start](#quick-start)
* [Changelog](#changelog)
* [FAQ](#frequently-asked-questions-faq)
* [Contributing Guide](#contributing)
* [License](#license)
* [Support](#support)

## Quick Start

This guide provides a quick way to get started with our project. Please see our [docs]([INSERT LINK TO DOCS SITE / WIKI HERE]) for a more comprehensive overview.

### Requirements

* [INSERT LIST OF REQUIREMENTS HERE]
  
<!-- ☝️ Replace with a numbered list of your requirements, including hardware if applicable ☝️ -->

### Setup Instructions

1. [INSERT STEP-BY-STEP SETUP INSTRUCTIONS HERE, WITH OPTIONAL SCREENSHOTS]
   
<!-- ☝️ Replace with a numbered list of how to set up your software prior to running ☝️ -->

### Run Instructions

1. [INSERT STEP-BY-STEP RUN INSTRUCTIONS HERE, WITH OPTIONAL SCREENSHOTS]

<!-- ☝️ Replace with a numbered list of your run instructions, including expected results ☝️ -->

### Usage Examples

* [INSERT LIST OF COMMON USAGE EXAMPLES HERE, WITH OPTIONAL SCREENSHOTS]

<!-- ☝️ Replace with a list of your usage examples, including screenshots if possible, and link to external documentation for details ☝️ -->

### Build Instructions (if applicable)

1. [INSERT STEP-BY-STEP BUILD INSTRUCTIONS HERE, WITH OPTIONAL SCREENSHOTS]

<!-- ☝️ Replace with a numbered list of your build instructions, including expected results / outputs with optional screenshots ☝️ -->

### Test Instructions (if applicable)

1. [INSERT STEP-BY-STEP TEST INSTRUCTIONS HERE, WITH OPTIONAL SCREENSHOTS]

<!-- ☝️ Replace with a numbered list of your test instructions, including expected results / outputs with optional screenshots ☝️ -->

## Changelog

See our [CHANGELOG.md](CHANGELOG.md) for a history of our changes.

See our [releases page]([INSERT LINK TO YOUR RELEASES PAGE]) for our key versioned releases.

<!-- ☝️ Replace with links to your changelog and releases page ☝️ -->

## Frequently Asked Questions (FAQ)

[INSERT LINK TO FAQ PAGE OR PROVIDE FAQ INLINE HERE]
<!-- example link to FAQ PAGE>
Questions about our project? Please see our: [FAQ]([INSERT LINK TO FAQ / DISCUSSION BOARD])
-->

<!-- example FAQ inline format>
1. Question 1
   - Answer to question 1
2. Question 2
   - Answer to question 2
-->

<!-- example FAQ inline with no questions yet>
No questions yet. Propose a question to be added here by reaching out to our contributors! See support section below.
-->

<!-- ☝️ Replace with a list of frequently asked questions from your project, or post a link to your FAQ on a discussion board ☝️ -->

## Contributing

[INSERT LINK TO CONTRIBUTING GUIDE OR FILL INLINE HERE]
<!-- example link to CONTRIBUTING.md>
Interested in contributing to our project? Please see our: [CONTRIBUTING.md](CONTRIBUTING.md)
-->

<!-- example inline contributing guide>
1. Create an GitHub issue ticket describing what changes you need (e.g. issue-1)
2. [Fork](INSERT LINK TO YOUR REPO FORK PAGE HERE, e.g. https://github.com/my_org/my_repo/fork) this repo
3. Make your modifications in your own fork
4. Make a pull-request in this repo with the code in your fork and tag the repo owner / largest contributor as a reviewer

**Working on your first pull request?** See guide: [How to Contribute to an Open Source Project on GitHub](https://kcd.im/pull-request)
-->

[INSERT LINK TO YOUR CODE_OF_CONDUCT.md OR SHARE TEXT HERE]
<!-- example link to CODE_OF_CONDUCT.md>
For guidance on how to interact with our team, please see our code of conduct located at: [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)
-->

<!-- ☝️ Replace with a text describing how people may contribute to your project, or link to your contribution guide directly ☝️ -->

[INSERT LINK TO YOUR GOVERNANCE.md OR SHARE TEXT HERE]
<!-- example link to GOVERNANCE.md>
For guidance on our governance approach, including decision-making process and our various roles, please see our governance model at: [GOVERNANCE.md](GOVERNANCE.md)
-->

## License

See our: [LICENSE](LICENSE)
<!-- ☝️ Replace with the text of your copyright and license, or directly link to your license file ☝️ -->

## Support

[INSERT CONTACT INFORMATION OR PROFILE LINKS TO MAINTAINERS AMONG COMMITTER LIST]

<!-- example list of contacts>
Key points of contact are: [@github-user-1](link to github profile) [@github-user-2](link to github profile)
-->

<!-- ☝️ Replace with the key individuals who should be contacted for questions ☝️ -->
- + \ No newline at end of file diff --git a/docs/guides/documentation/readme/index.html b/docs/guides/documentation/readme/index.html index 2a4d6ff18..142065078 100644 --- a/docs/guides/documentation/readme/index.html +++ b/docs/guides/documentation/readme/index.html @@ -5,13 +5,13 @@ READMEs | SLIM - +

READMEs

A guide to constructing an effective and impressive README for your project.

readme-screenshot-example

Example README.md template rendering

Introduction​

Background: A well-crafted README.md is essential for introducing your software repository. It serves as the first point of contact for developers and users, providing a concise and clear overview. This guide offers a template suitable for various software projects, aiding in the creation of effective README files.

Use Cases:

  • Creating an informative and welcoming introduction to your software project.
  • Standardizing README content across various types of software repositories.
  • Enhancing project understanding for contributors and users.
  • Answering questions in a FAQ setting
  • Guiding readers on licensing and who to contact for support

Prerequisites​

  • Basic knowledge of Markdown formatting.
  • Understanding of your project's key features and usage.

Quick Start​

⬇️ README Template (see example)

Download and fill-out our recommended README template to get started on crafting your project's introduction.

Step-by-Step Guide​

  1. Discuss with Your Team: Ensure consensus on adopting the README Template.
  2. Customize the Template:
    • Copy the README Template into a README.md file in your repository.
    • Replace [INSERT ...] placeholders with your project's specifics.
  3. Integrate into Your Project:
    • Link to the CONTRIBUTING.md within your README.md for easy access.

Frequently Asked Questions (FAQ)​

  • Q: What makes a README file effective?
  • A: Clarity, completeness, and relevance of information regarding the project's purpose, usage, and contribution process.

Credits​

Authorship:

Acknowledgements:

  • Inspired by README best practices from NASA-AMMOS, ReactJS, VueJS, and Apache Kafka.

Feedback and Contributions​

We welcome feedback and improvements to this template. See our contribution guidelines.

- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/code-of-conduct/index.html b/docs/guides/governance/contributions/code-of-conduct/index.html index 368155391..44be97891 100644 --- a/docs/guides/governance/contributions/code-of-conduct/index.html +++ b/docs/guides/governance/contributions/code-of-conduct/index.html @@ -5,13 +5,13 @@ Code of Conduct | SLIM - +

Code of Conduct

A walkthrough on setting up a code-of-conduct policy for your project.

code-of-conduct-screenshot-example

Example CODE_OF_CONDUCT.md template rendering

Introduction​

Background: A Code of Conduct is important in setting the standards for interaction within a project team. It promotes a positive community environment, addressing unacceptable behaviors and providing mechanisms for conflict resolution. In this guide, we'll help you bootstrap your project with a recommended a Code of Conduct, notably the Contributor Covenant, which is widely recognized and adopted in open-source communities.

Use Cases:

  • Establishing a respectful and inclusive team culture.
  • Providing clear guidelines on acceptable behaviors and handling grievances.

Prerequisites​

  • Understanding of community management and team dynamics.
  • Familiarity with Markdown for editing documentation.

Quick Start​

⬇️ Contributor Covenant Template (see example)

Access the standard Contributor Covenant template for a robust Code of Conduct policy to use in your project.

Step-by-Step Guide​

  1. Team Consultation: Discuss the adoption of the Contributor Covenant with your team, ensuring consensus.
  2. Setting Up the Document:
    • Create a CODE_OF_CONDUCT.md file in your repository.
    • Copy the Contributor Covenant template into this file.
    • Replace [INSERT CONTACT METHOD] with appropriate contact details for reporting issues.
  3. Integrate into Your Project:
    • Add the Contributor Covenant badge () to your README.md for visibility and easy access.
      [![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](CODE_OF_CONDUCT.md)

Frequently Asked Questions (FAQ)​

  • Q: Why is a Code of Conduct important for projects?
  • A: It establishes a standard for behavior, promoting a safe and inclusive environment for collaboration.
  • Q: Can I customize the Contributor Convenant Code of Conduct template?
  • A: Yes! Especially if your project is managed in a unique way.
  • Q: What should be done if a team member violates the Code of Conduct?
  • A: Violations should be reported to the designated contact person or team. The matter should be handled confidentially and in accordance with the guidelines set forth in the Code of Conduct.
  • Q: How often should the Code of Conduct be reviewed or updated?
  • A: Regularly reviewing and updating the Code of Conduct ensures it stays relevant and effective. It's advisable to reassess it annually or when significant changes occur within the project or community.

Credits​

Authorship:

Acknowledgements:

Feedback and Contributions​

Your feedback and contributions are welcome to enhance this guide. See our contribution guidelines.

- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/contributing-guide/CONTRIBUTING/index.html b/docs/guides/governance/contributions/contributing-guide/CONTRIBUTING/index.html index 13a194b83..362626255 100644 --- a/docs/guides/governance/contributions/contributing-guide/CONTRIBUTING/index.html +++ b/docs/guides/governance/contributions/contributing-guide/CONTRIBUTING/index.html @@ -5,13 +5,13 @@ CONTRIBUTING | SLIM - +

CONTRIBUTING

# Contributing Guide

Thanks for taking the time to consider contributing! We very much appreciate your time and effort. This document outlines the many ways you can contribute to our project, and provides detailed guidance on best practices. We look forward to your help!

## Prerequisites

Before you begin contributing to our project, it'll be a good idea to ensure you've satisfied the below pre-requisites. 

### License

Our project has our licensing terms, including rules governing redistribution, documented in our [LICENSE](LICENSE) file. Please take a look at that file and ensure you understand the terms. This will impact how we, or others, use your contributions.

### Code of Conduct

Our Code of Conduct helps facilitate a positive interaction environment for everyone involved with the team, and provides guidance on what to do if you experience problematic behavior. Read more in our [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md), and make sure you agree to its terms. 

### Developer Environment

For patch contributions, see our [Developer Documentation]([INSERT YOUR DEVELOPMENT GUIDE LINK HERE]) for more details on how to set up your local environment, to best contribute to our project. 

At a minimum however to submit patches (if using Git), you'll want to ensure you have:
1. An account on the Version Control System our project uses (i.e. GitHub).
2. The Version Control System client (i.e. Git) installed on your local machine.
3. The ability to edit, build, and test our project on your local machine. Again, see our [README.md](README.md) or detailed developer guide for more details 

### Communication Channels

Before contributing changes to our project, it's a great idea to be familiar with our communication channels and to socialize your potential contributions to get feedback early. This will help give you context for your contributions, no matter their form.

Our communication channels are:
- [Issue tracking system]([INSERT LINK TO ISSUE TRACKING SYSTEM]) - a regularly monitored area to report issues with our software or propose changes
- [Discussion board]([INSERT LINK TO DISCUSSION BOARD OR MAILING LIST]) - an permanently archived place to hold conversations related to our project, and to propose as well as show+tell topics to the contributor team. This resource can be searched for old discussions.
- [INSERT ADDITIONAL COMMUNICATION CHANNELS FOR YOUR PROJECT, EX: SLACK, TWITTER, YOUTUBE, ETC.]

### Communication Channels

Before contributing changes to our project, it's a great idea to be familiar with our communication channels and to socialize your potential contributions to get feedback early. This will help give you context for your contributions, no matter their form.

Our communication channels are:
- [Issue tracking system]([INSERT LINK TO ISSUE TRACKING SYSTEM]) - a regularly monitored area to report issues with our software or propose changes
- [Discussion board](INSERT LINK TO DISCUSSION BOARD OR MAILING LIST) - an permanently archived place to hold conversations related to our project, and to propose as well as show+tell topics to the contributor team. This resource can be searched for old discussions.
- [INSERT ADDITIONAL COMMUNICATION CHANNELS FOR YOUR PROJECT, EX: SLACK, TWITTER, YOUTUBE, ETC.]

## Our Development Process

Our project integrates contributions from many people, and so we'd like to outline a process you can use to visualize how your contributions may be integrated if you provide something. 

```mermaid
flowchart TD
    repo_proj[(Our Repository)]-->|Fork|repo_fork[(Your Forked Repository)]
    repo_fork-->|Make|patch(Your Changes)
    patch-->|Submit|pr(Pull Request)
    pr==>|Approved|repo_proj
    pr-->|Changes Requested|repo_fork
```

### Fork our Repository

Forking our repository, as opposed to directly committing to a branch is the preferred way to propose changes. 

See [this GitHub guide](https://docs.github.com/en/get-started/quickstart/fork-a-repo) on forking for information specific to GitHub.com

#### Find or File an Issue

Make sure people are aware you're working on a patch! Check out our [issue tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]) and find an open issue you'd like to work against, or alternatively file a new issue and mention you're working on a patch.

#### Choose the Right Branch to Fork

Our project typically has the following branches available, make sure to fork either the default branch or a branch someone else already tagged with a particular issue ticket you're working with.
- `main`[INSERT DEFAULT VCS BRANCH NAME HERE] - default branch
- [INSERT ADDITIONAL TYPICAL VCS BRANCH NAMES HERE] - 

### Make your Modifications

Within your local development environment, this is the stage at which you'll propose your changes, and commit those changes back to version control. See the [README.md](README.md) or development guide for more specifics on what you'll need as prerequisites to setup your local development environment.

#### Commit Messages

Commit messages to version control should reference a ticket in their title / summary line:

```
Issue #248 - Show an example commit message title
```

This makes sure that tickets are updated on GitHub with references to commits that are related to them.

Commit should always be atomic. Keep solutions isolated whenever possible. Filler commits such as "clean up white space" or "fix typo" should be merged together before making a pull request, and significant sub-feature branches should be [rebased](https://www.youtube.com/results?search_query=git+rebase) to preserve commit history. Please ensure your commit history is clean and meaningful!

### Submit a Pull Request

Pull requests are the core way our project will receive your patch contributions. Navigate to your branch on your own fork within the version control system, and submit a pull request or submit the patch text to our project. 

Please make sure to provide a meaningful text description to your pull requests, whenever submitted. Our pull-request template will be auto-generated for you when you create your pull-request. See the template [here]([INSERT LINK TO YOUR PULL REQUEST TEMPLATE, ex: .github/PULL_REQUEST_TEMPLATE.md]). 

**Working on your first Pull Request?** See guide: [How to Contribute to an Open Source Project on GitHub](https://kcd.im/pull-request)

### Reviewing your Pull Request

Reviewing pull-requests, or any kinds of proposed patch changes, is an art. That being said, we follow the following best practices:
- **Intent** - is the purpose of your pull-request clearly stated?
- **Solution** - is your pull-request doing what you want it to?
- **Correctness** - is your pull-request doing what you want it to *correctly*?
- **Small Patches** - is your patch of a level of complexity and brevity that it can actually be reviewed by a human being? Or is does it involve too much content for one pull request?
- **Coding best practices** - are you following best practices in the coding / contribution language being used?
- **Readability** - is your patch readable, and ultimately maintainable, by others?
- **Reproducibility** - is your patch reproducible by others?
- **Tests** - do you have or have conducted meaningful tests?

## Ways to Contribute

### ⚠️ Issue Tickets

> *Do you like to talk about new features, changes, requests?*

Issue tickets are a very simple way to get involved in our project. It also helps new contributors get an understanding of the project more comprehensively. This is a great place to get started with the project if you're not sure where to start. 

See our list of issues at: [INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]

#### Cleaning up Duplicate Issues

Often we receive duplicate issues that can confuse project members on *which* issue ticket to hold conversations upon.

Here's how you can help:
1. Scan the list of *open* issue tickets for duplicate titles, or internal wording 
2. If you find duplicates, copy / paste the below message on the conversation thread of the issue ticket *that has less participants* involved

```
This is a duplicate issue. Please migrate conversations over to [issue-XYZ](hyperlink to issue)
```

#### Good First Issues

Issue tickets can vary in complexity, and issues labeled with `good first issue` labels are often a great way to get started with the project as a newcomer. 

Take a look at our [issue tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]), and filter by `good first issue` for issues that are low-complexity, and that will help you get familiar with our issue tracking and patch submission process.

#### Suggesting New Issue Labels

Labels within our [issue tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]) are a great way to quickly sort through tickets. The project may not yet have labels to cover the full variety of issue tickets. Take a look through our list of issues, and if you notice a set of issue tickets that seem similar but are not categorized with an existing label, go ahead submit a request within one of the issues you've looked at with the following text:

```
I've noticed several other issues that are of the same category as this issue. Shall we make a new label for these types of issues?
```

#### Submitting Bug Issues

Resolving bugs is a priority for our project. We welcome bug reports. However, please make sure to do the following prior to submitting a bug report:
- **Check for duplicates** - there may be a bug report already describing your issue, so check the [issue tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]) first.

Here's some guidance on submitting a bug issue:
1. Navigate to our [issue tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]) and file a new issue
2. Select a bug template (if available) for your issue
   1. Fill out the template fields to the best of your ability, including output snippets or screenshots where applicable
3. Follow the general guidelines below for extra information about your bug
   1. Include a code snippet if you have it showcasing the bug
   2. Provide reproducible steps of how to recreate the bug
   3. If the bug triggers an exception or error message, include the *full message* or *stacktrace*
   4. Provide information about your operating system and the version of our project you're using

#### Submitting New Feature Issues

We welcome new feature requests to help grow our project. However, please make sure to do the following prior to submitting a new feature request:
- **Check for duplicates** - there may be a new feature issue already describing your issue, so check the [issue tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]) first
- **Consider alternatives** - is your feature really needed? Or is there a feature within our project or with a third-party that may help you achieve what you want?

Here's some guidance on submitting a new feature issue:
1. Navigate to our [issue tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]) and file a new issue
2. Select a new feature template (if available) for your issue
   1. Fill out the template fields to the best of your ability

#### Submitting Security Vulnerability Issues

Security vulnerabilities should **not** be filed to the regular issue tracking system.

Report your security vulnerabilities to (see contact links): [INSERT SECURITY CONTACT LINK HERE]

Please be sure to:
* Indicate the severity of the vulnerability
* Provide any workarounds, if you know them
* Provide return-contact information to follow-up with you if needed

#### Reviewing Pull Requests

Reviewing others' contributions is a great way to learn about best practices in both contributions as well as software. 

Take a look at our [pull requests tracking system]([INSERT LINK FOR PULL REQUESTS TRACKING SYSTEM]), and try the following options for providing a review:
1. Read the code / patch associated with the pull-request, and take note of any coding, bug, or documentation issues if found
2. Try to recreate the pull-request patch on your local machine, and report if it has issues with your system in particular
3. Scan over suggested feedback from other contributors, and provide feedback if necessary

### 💻  Code

⚠️ It's **highly** advised that you take a look at our [issue tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]) before considering any code contributions. Here's some guidelines:
1. Check if any duplicate issues exist that cover your code contribution idea / task, and add comments to those tickets with your thoughts.
2. If no duplicates exist, create a new issue ticket and get a conversation started before making code changes using our [communication channels](#communication-channels).

Once you have a solid issue ticket in hand and are ready to work on code, you'll want to:
1. Ensure you have development [prerequisites](#prerequisites) cleared.
2. Have your [development environment](#developer-environment) set up properly.
3. Go through our [development process](#our-development-process), including proposing changes to our project.

Some guidelines for code-specific contributions:
- **Do your homework** - read-up on necessary documentation, like `README.md`s, developer documentation, and pre-existing code to see the intention and context necessary to make your contribution a success. It's important to _communicate_ what you're working on through our project [communication channels](#communication-channels) and get buy-in from frequent contributors - this will help the project be more receptive to your contributions! 
- **Ask questions** - its important to ask questions while you work on your contributions, to check-in with frequent contributors on the style and the set of expectations to make your code contribution work well with pre-existing project code. Use our [communication channels](#communication-channels)
- **Keep positive** - code contributions, by their nature, have direct impacts on the output and functionality of the project. Keep a positive spirit as your code is reviewed, and take it in stride if core contributors take time to review, give you suggestions for your code or respectfully decline your contribution. This is all part of the process for quality open source development. 
- **Comments** - include *useful* comments throughout your code that explain the intention of a code block, not a step-by-step analysis. See our [inline code documentation](#inline-code-documentation) section for specifics. 

[INSERT ADDITIONAL SECTIONS HERE FOR MORE SPECIFIC CLASSES OF CODE CONTRIBUTIONS DEPENDING ON YOUR MODULES, LANGUAGES, PLATFORMS IN USE BY YOUR PROJECT. THE MORE DETAILS YOU OFFER, THE MORE LIKELY SOMEONE IS TO UNDERSTAND HOW TO CONTRIBUTE]
<!-- EXAMPLE: APIs, PyTest, etc. -->

### 📖 Documentation 

Documentation is the core way our users and contributors learn about the project. We place a high value on the quality, thoroughness, and readability of our documentation. Writing or editing documentation is an excellent way to contribute to our project without performing active coding. 

⚠️ It's **highly** advised that you take a look at our [issue-tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM]) before considering any documentation contributions. Here's some guidelines:
1. Check if any duplicate issues exist that cover your documentation contribution idea / task, and add comments to those tickets with your thoughts.
2. If no duplicates exist, create a new issue ticket and get a conversation started before making documentation changes.

Some guidelines for documentation best practices (summarized from Google's [excellent documentation guide](https://google.github.io/styleguide/docguide/best_practices.html)):
- **Minimum viable docs** - don't do less documentation than your users / developers need, but also don't do more
- **Changed code = changed docs** - if your code has changed, remember to update your documentation
- **Delete old docs** - continually clean your documentation tree, and remove outdated docs regularly

#### Documentation Organization

The overall structure of our project documentation is as follows:
- Source-controlled documentation
  - [README.md](README.md) - top-level information about how to run, build, and contribute to the project
  - [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) - best practices and guidance on how to work well with other people in the project, and suggestions on dealing with interpersonal issues
  - [CONTRIBUTING.md](CONTRIBUTING.md) - guidance on contributing to the project
  - `*.[INSERT YOUR CODING LANGUAGE FILE EXTENSIONS HERE]` - inline documentation available inside code files
- [INSERT ADDITIONAL DOCUMENTATION CLASSES AND ORGANIZATION STRUCTURE HERE, SEE EXAMPLE IN COMMENTS BELOW]

<!-- EXAMPLE:
- Source-controlled documentation
  - [README.md](README.md) - top-level information about how to run, build, and contribute to the project
  - [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) - best practices and guidance on how to work well with other people in the project, and suggestions on dealing with interpersonal issues
  - [CONTRIBUTING.md](CONTRIBUTING.md) - guidance on contributing to the project
  - `*.py` - inline documentation available inside code files' function headers and code blocks
  - [docs/](docs/)` - top-level directory containing source-controlled documentation built into statically hosted files on our documentation website
- Hosted documentation
  - [Wiki Main-page]()
    - [Wiki Sub-page 1]()
    - [Wiki Sub-page 2]() 
- Discussion Boards
  - [Discussion Board Topic 1]()
  - [Discussion Board Topic 2]()
- YouTube.com video tutorials
  - [Channel page 1]()
  - [Channel page 2]()
- Application Programming Interface (API) documentation
  - [Sub-module 1]()
  - [Sub-module 2]()
- etc.
-->

For directions on contributing to our source-controlled documentation:
1. Ensure you have development [prerequisites](#prerequisites) cleared.
2. Have your [development environment](#developer-environment) set up properly.
3. Go through our [development process](#our-development-process), including proposing changes to our project.

<!-- OPTIONAL FOR HOSTED DOCUMENTATION >
For directions on contributing to our hosted documentation:
1. 
2. 
3. 

[INSERT HOSTED DOCUMENTATION PLATFORM SPECIFIC INSTRUCTIONS HERE FOR HOW TO CONTRIBUTE]
-->

#### Writing Style

To ensure documentation is readable and consistent by newcomers and experts alike, here are some suggestions on writing style for English:
- Use gender neutral pronouns (they/their/them) instead of he/she/his/her 
- Avoid qualifiers that minimize the difficulty of a task at hand, e.g. avoid words like “easily”, “simply”, “just”, “merely”, “straightforward”, etc. Readers' expertise may not match your own, and qualifying complexity may deter some readers if the task does not match their level of experience. That being said, if a particular task is difficult or complex, do mention that. 

#### Common Wording 

Below are some commonly used words you'll want to leverage in your documentation contributions:
- **GitHub** - one word, and capitalization of the 'G' and the 'H'
- [INSERT YOUR PROJECT SPECIFIC COMMON TERMS AND HOW TO USE THEM]

#### Inline Code Documentation

For language-specific guidance on code documentation, including style guides, see [Google's list of language style guides](https://google.github.io/styleguide/) for a variety of languages. 

Additionally, take a look at Google's recommendations on [inline code documentation](https://google.github.io/styleguide/docguide/best_practices.html#documentation-is-the-story-of-your-code) for best practices. 

#### Media

Media, such as such as images, videos, sound files, etc., are an excellent way to explain documentation to a wider audience more easily. Include media in your contributions as often as possible.

When including media into our version-control system, it is recommended to use formats such as:
- Diagrams: [Mermaid](https://mermaid-js.github.io/mermaid/#/) format
- Images: JPEG format
- Videos: H264 MPEG format
- Sounds: MP3 format
<!-- ADD TO OR MODIFY ABOVE DEFAULT SUGGESTIONS -->

### ❓ Questions

Answering questions is an excellent way to learn more about our project, as well as get better known in our project community. 

Here are just a few ways you can help answer questions for our project:
- Answer open questions in our [discussion forum]([INSERT LINK TO DISCUSSION FORUM])
- Answer open questions mentioned in our [issue tracking system]([INSERT LINK TO YOUR ISSUE TRACKING SYSTEM])
<!-- ADD TO OR MODIFY DEPENDING ON YOUR COMMUNICATION CHANNELS LISTED AT THE BEGINNING OF THIS DOCUMENT-->

When answering questions, keep the following in mind:
- Be polite and friendly. See our [Code of Conduct](CODE_OF_CONDUCT.md) recommendations as you interact with others in the team.
- Repeat the specific question you are answering, followed by your suggestion.
- If suggesting code, repeat the line of code that needs to be altered, followed by your alteration
- Include any post-steps or checks to verify your answer can be reproduced 

### 🎨 Design

Design files can help to guide new features and new areas of expansion for our project. We welcome these kinds of contributions.

Here are just a few ways you can help provide design recommendations for our project:
- Create visual mockups or diagrams to increase usability of our project applications. This can apply to user interfaces, documentation structuring, or even code architecture diagrams.
- Conduct user research to understand user needs better. Save your findings within spreadsheets that the project team / contributors can review.
- Create art, such as logos or icons, to support the user experience for the project

Each of the above can be contributed directly to repository code, and you should use our [development process](#our-development-process) to contribute your additions.

### 🎟️ Meetups

A great way to contribute towards our project goals is to socialize and encourage people to meet and learn more about each other. Consider ideas like:
- Propose workshops or meetups regarding some topic within our project
- Help point project contributors and community members to conferences and publications where they may socialize their unique innovations
- Schedule in-person or virtual happy-hours to help create a more social atmosphere within the project community

For the above ideas, use our [communication channels](#communication-channels) to propose get-togethers.
- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/contributing-guide/index.html b/docs/guides/governance/contributions/contributing-guide/index.html index 31f7a78ae..322870fd5 100644 --- a/docs/guides/governance/contributions/contributing-guide/index.html +++ b/docs/guides/governance/contributions/contributing-guide/index.html @@ -5,14 +5,14 @@ Contributing Guide | SLIM - +

Contributing Guide

Fast track developing a contribution guide for your new contributors.

contributing-screenshot-example

Example CONTRIBUTING.md template rendering

Introduction​

Background: A well-defined contribution guide is crucial for open-source projects. It helps new contributors understand the expectations and processes for contributing effectively. We walk you through developing a contribution guide for your project via our template, which sets clear standards for contributions and details a recommended process to follow.

Use Cases:

  • Guiding new contributors on making meaningful contributions.
  • Ensuring contributions align with project norms and requirements.
  • Facilitating a transparent and efficient contribution process.

Prerequisites​

  • Understanding of basic project management and version control systems.
  • Familiarity with GitHub and Markdown formatting.

Quick Start​

⬇️ Contributing Guide Template (see example)

Download our customizable template to create a contributing guide for your project.

Step-by-Step Guide​

  1. Team Discussion: Collaborate with your team to decide on adopting a contribution guide template. This step is essential to establish project norms and contribution expectations. Our template touches the following topics that you'll want to consider:
    • License overview
    • Code of Conduct
    • Governance Model
    • Developer environment setup
    • Communication channels
    • How-to in interacting with the codebase
    • Pull requests
    • Ways to contribute (e.g. code, docs, media, etc.)
    • etc.
  1. Customize the Template: Modify the Contributing Guide Template to fit your project's specifics.
    • Copy the template and create a CONTRIBUTING.md file at the root level of your repository.
    • Replace [INSERT ...] placeholders with your project's details. These markers are used throughout to designate customization options.
  2. Integrate with Project:
    • Add a link to CONTRIBUTING.md in your project's README.md file under the Contributing section.
  3. Communicate:
    • Share the guide with existing contributors and all new contributors as their starting point.

Frequently Asked Questions (FAQ)​

  • Q: Why should I even bother with a contributing guide?
  • A: Do you want to constantly re-explain your project's philosophy and contribution norms? If not - a contribution guide helps set clear expectations and processes, ensuring contributions are consistent and aligned with your project's goals.

Credits​

Authorship:

Acknowledgements: This template is influenced by guidelines from the following:

Feedback and Contributions​

Feedback and contributions are encouraged to refine this guide. Visit our contribution guidelines for more information.

- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/issue-templates/bug-reports/bug_report.yml/index.html b/docs/guides/governance/contributions/issue-templates/bug-reports/bug_report.yml/index.html index 9788fc126..675c32de0 100644 --- a/docs/guides/governance/contributions/issue-templates/bug-reports/bug_report.yml/index.html +++ b/docs/guides/governance/contributions/issue-templates/bug-reports/bug_report.yml/index.html @@ -5,13 +5,13 @@ bug_report.yml | SLIM - +

bug_report.yml

name: Bug Report Form
description: Report a bug to help us improve
title: "[Bug]: "
labels: "bug"
body:
  - type: markdown
    attributes:
      value: |
        > _Thanks for filing a bug ticket. We appreciate your time and effort. Please answer a few questions._
  - type: dropdown
    id: checked-for-duplicates
    attributes:
      label: Checked for duplicates
      description: Have you checked for duplicate issue tickets?
      multiple: false
      options:
        - "Yes - I've already checked"
        - "No - I haven't checked"
    validations:
      required: yes
  - type: textarea
    id: description
    attributes:
      label: Describe the bug
      description: A clear and concise description of what the bug is. Plain-text snippets preferred but screenshots welcome.
      placeholder: Tell us what you saw
      value: "When I did [...] action, I noticed [...]"
    validations:
      required: true
  - type: textarea
    id: expected-behavior
    attributes:
      label: What did you expect?
      description: A clear and concise description of what you expect to happen
      placeholder: Tell us what you expected
      value: "I expected [...]"
    validations:
      required: true
  - type: textarea
    id: reproduction
    attributes:
      label: Reproducible steps
      description: "How would we reproduce this bug? Please walk us through it step by step. Plain-text snippets preferred but screenshots welcome."
      value: |
        1.
        2.
        3.
        ...
      render: bash
  - type: textarea
    id: environment
    attributes:
      label: Environment
      description: "What is your environment? Include any computer hardware, operating system, framework, browser, time-of-day or other contextual information related to your issue"
      value: |
        - Version of this software [e.g. vX.Y.Z]
        - Operating System: [e.g. MacOSX with Docker Desktop vX.Y]
        ...
      render: bash
- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/issue-templates/bug-reports/bug_report/index.html b/docs/guides/governance/contributions/issue-templates/bug-reports/bug_report/index.html index 60db6f090..4d7be676c 100644 --- a/docs/guides/governance/contributions/issue-templates/bug-reports/bug_report/index.html +++ b/docs/guides/governance/contributions/issue-templates/bug-reports/bug_report/index.html @@ -5,13 +5,13 @@ bug_report | SLIM - +

bug_report

---
name: Bug Report
about: Report a bug to help us improve
title: '[Bug]: '
labels: 'bug'
assignees: ''

---

**Checked for duplicates**

> Have you checked for duplicate issue tickets?

- Ex. Yes - I've already checked
- Ex. No - I haven't checked

**Describe the bug**

> A clear and concise description of what the bug is. Plain-text snippets preferred but screenshots welcome.

Ex. When I did [...] action, I noticed [...]

**What did you expect?**

> A clear and concise description of what you expect to happen

Ex. I expected [...]

**Reproducible steps**

> How would we reproduce this bug? Please walk us through it step by step. Plain-text snippets preferred but screenshots welcome.

1.
2.
3.

**What is your environment?**

> Include any computer hardware, operating system, framework, browser, time-of-day or other contextual information related to your issue

- Ex. Version of this software [e.g. vX.Y.Z]
- Ex. Operating System: [e.g. MacOSX with Docker Desktop vX.Y]
- ...
- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/issue-templates/features/new_feature.yml/index.html b/docs/guides/governance/contributions/issue-templates/features/new_feature.yml/index.html index d1da36005..cf5038e4f 100644 --- a/docs/guides/governance/contributions/issue-templates/features/new_feature.yml/index.html +++ b/docs/guides/governance/contributions/issue-templates/features/new_feature.yml/index.html @@ -5,13 +5,13 @@ new_feature.yml | SLIM - +

new_feature.yml

name: New Feature Form
description: Suggest a new feature for us to implement
title: "[New Feature]: "
labels: "enhancement"
body:
  - type: markdown
    attributes:
      value: |
        > _Thanks for filing a new feature request. We appreciate your time and effort. Please answer a few questions._
  - type: dropdown
    id: checked-for-duplicates
    attributes:
      label: Checked for duplicates
      description: Have you checked for duplicate issue tickets?
      multiple: false
      options:
        - "Yes - I've already checked"
        - "No - I haven't checked"
    validations:
      required: yes
  - type: dropdown
    id: checked-alternatives
    attributes:
      label: Alternatives considered
      description: Have you considered alternative solutions to your feature request?
      options:
        - "Yes - and alternatives don't suffice"
        - "No - I haven't considered"
    validations:
      required: yes
  - type: textarea
    id: related-problems
    attributes:
      label: Related problems
      description: Is your feature request related to any problems? Please help us understand if so, including linking to any other issue tickets.
      placeholder: Tell us the problems
      value: "I'm frustrated when [...] happens as documented in issue-XYZ"
    validations:
      required: false
  - type: textarea
    id: description
    attributes:
      label: Describe the feature request
      description: A clear and concise description of your request. 
      placeholder: Tell us what you want
      value: "I need or want [...]"
    validations:
      required: true
- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/issue-templates/features/new_feature/index.html b/docs/guides/governance/contributions/issue-templates/features/new_feature/index.html index 396259882..f6e1d0cef 100644 --- a/docs/guides/governance/contributions/issue-templates/features/new_feature/index.html +++ b/docs/guides/governance/contributions/issue-templates/features/new_feature/index.html @@ -5,13 +5,13 @@ new_feature | SLIM - +

new_feature

---
name: New Feature
about: Suggest a new feature for us to implement
title: '[New Feature]: '
labels: 'enhancement'
assignees: ''

---

**Checked for duplicates**

> Have you checked for duplicate issue tickets?

- Ex. Yes - I've already checked
- Ex. No - I haven't checked

**Alternatives considered**

> Have you considered alternative solutions to your feature request?

- Ex. Yes - and alternatives don't suffice
- Ex. No - I haven't considered

**Related problems**

> Is your feature request related to any problems? Please help us understand if so, including linking to any other issue tickets.

Ex. I'm frustrated when [...] happens as documented in issue-XYZ

**Describe the feature request**

> A clear and concise description of your request. 

Ex. I need or want [...]
- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/issue-templates/index.html b/docs/guides/governance/contributions/issue-templates/index.html index 70a2774cf..26b551b63 100644 --- a/docs/guides/governance/contributions/issue-templates/index.html +++ b/docs/guides/governance/contributions/issue-templates/index.html @@ -5,13 +5,13 @@ Issue Templates | SLIM - +

Issue Templates

Make issue tracking clear and consistent with structured issue templates for your contributors.

issue-bug-screenshot-example

Example bug issue ticket template rendering

Introduction​

Background: Implementing issue templates in GitHub projects standardizes and clarifies the submission of bug reports, feature requests, and other types of issues. It guides contributors in providing essential details, helping developers understand and address issues more efficiently.

Use Cases:

  • Enhancing clarity and consistency in issue or feature reporting.
  • Streamlining the process for contributors to report bugs or request features so that a wide audience can switch between issues easily.
  • Improving developers' understanding of issues for quicker resolution.

Prerequisites​

  • Access to a GitHub repository with administrative permissions.
  • Basic knowledge of Markdown for editing GitHub templates.

Quick Start​

Bug Reports:

New Features:

Resources:

📔 GitHub Issue Template Documentation

Step-by-Step Guide​

  1. Team Discussion: Consult with your team about using GitHub issue templates. Reach a consensus on adopting this practice. Our suggested templates request the below information - see justification below.

    • Bug Reports:
      1. Checked for duplicates: This section asks the contributor to verify if the issue has already been reported. It helps prevent duplication and streamlines the issue management process.
      2. Describe the bug: The contributor provides a clear, concise description of the bug. This section is critical for developers to understand the issue's nature and impact.
      3. What did you expect?: Understanding the contributor's expectations clarifies the disparity between expected and actual behavior, helping to pinpoint the issue more accurately.
      4. Reproducible steps: Step-by-step reproduction instructions are crucial for developers to replicate the issue, diagnose the problem, and test solutions effectively.
      5. What is your environment?: Providing details about the hardware, operating system, or other contextual factors helps in identifying if the bug is environment-specific and aids in troubleshooting.
    • New Features:
      1. Checked for duplicates: This section ensures the contributor has checked for existing feature requests, avoiding redundancy and streamlining the development process.
      2. Alternatives considered: Encourages the contributor to consider and document alternative solutions. This insight can guide the evaluation of the feature's necessity.
      3. Related problems: This helps identify if the feature request is a solution to an existing problem, adding context and justification for the request.
      4. Describe the feature request: A clear description from the contributor about the proposed feature. This clarity is essential for understanding the feature's purpose and scope.

  2. Setting Up Issue Templates:

  3. Commit and Use Templates:

    • Commit these files to the main branch.
    • New issues in your repository will now offer these templates for contributors to fill.

Frequently Asked Questions (FAQ)​

  • Q: Why are issue templates important in GitHub projects?
  • A: They ensure that all necessary information is provided, leading to more effective issue tracking and resolution.

Credits​

Authorship:

Acknowledgements:

  • GitHub for providing documentation for issue templates.

Feedback and Contributions​

Feedback and contributions are welcome to enhance these guidelines. See our contribution guidelines.

- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/pull-requests/PULL_REQUEST_TEMPLATE/index.html b/docs/guides/governance/contributions/pull-requests/PULL_REQUEST_TEMPLATE/index.html index a718dd42c..cc75b0985 100644 --- a/docs/guides/governance/contributions/pull-requests/PULL_REQUEST_TEMPLATE/index.html +++ b/docs/guides/governance/contributions/pull-requests/PULL_REQUEST_TEMPLATE/index.html @@ -5,13 +5,13 @@ PULL_REQUEST_TEMPLATE | SLIM - +

PULL_REQUEST_TEMPLATE

## Purpose
- Clear, easy-to-understand sentences outlining the purpose of the PR
## Proposed Changes
- [ADD] ...
- [CHANGE] ...
- [REMOVE] ...
- [FIX] ...
## Issues
- Links to relevant issues
- Example: issue-XYZ
## Testing
- Provide some proof you've tested your changes 
- Example: test results available at ...
- Example: tested on operating system ...
- + \ No newline at end of file diff --git a/docs/guides/governance/contributions/pull-requests/index.html b/docs/guides/governance/contributions/pull-requests/index.html index 298938a1e..9aede21cd 100644 --- a/docs/guides/governance/contributions/pull-requests/index.html +++ b/docs/guides/governance/contributions/pull-requests/index.html @@ -5,13 +5,13 @@ Pull Requests | SLIM - +

Pull Requests

A template to standardize pull-requests.

pr-screenshot-example

Example pull request template in action rendering

Introduction​

Background: Pull requests help manage contributions to projects, especially on platforms like GitHub. By using a standardized pull request template, projects can streamline the contribution process, providing clarity and consistency for both contributors and maintainers. This guide will help you implement a GitHub Pull Request Template to improve how contributions are made to your project.

Use Cases:

  • Standardizing the format of pull requests for clarity and efficiency.
  • Providing guidelines to contributors for submitting well-documented pull requests.

Prerequisites​

  • Access to a GitHub repository where you can add files.
  • Basic understanding of GitHub's file structure and Markdown formatting.

Quick Start​

⬇️ Pull Request Template (see example)

Our recommended pull request template for projects.

📔 GitHub Pull Request Template Documentation

Recommendations from GitHub.com on how-to facilitate the use of pull request templates.

Step-by-Step Guide​

  1. Team Discussion: Discuss the benefits of a pull request template with your team. Gain consensus on adopting this approach for consistency in contributions. Below is an explanation of our recommended Pull Request Template file's fields. Adjust as necessary.

    • Purpose: To clearly state the intention behind the pull request. This helps reviewers understand the context and significance of your changes.
    • Proposed Changes:
      • [ADD] for new features or content the contributor introduced.
      • [CHANGE] for modifications to existing features or code.
      • [REMOVE] for removals features or code.
      • [FIX] for bug fixes the contributor implemented.
    • Issues: To link any related issues your PR addresses. This creates a traceable connection between the issue and the solution provided.
    • Testing: To document how the contributor tested the changes. Including links to test results or noting the operating systems on which the tests were performed. This assures reviewers of the reliability and effectiveness of changes.

  2. Create Template Directory:

    • In your GitHub repository, create a .github/ folder to hold community health files.

  3. Add Pull Request Template:

    • Copy the Pull Request Template into .github/PULL_REQUEST_TEMPLATE.
    • Commit and push this file to the main branch of your repository.

  4. Usage:

    • Once set up, this template will automatically appear in the pull request description box for contributors to fill out.

Frequently Asked Questions (FAQ)​

  • Q: How does a pull request template improve contributions?
  • A: It provides a structured format for contributors, ensuring all necessary information is included, which facilitates better review and collaboration.

Credits​

Authorship:

Feedback and Contributions​

We welcome feedback and contributions to enhance this guide. For contributing, please see our contribution guidelines.

- + \ No newline at end of file diff --git a/docs/guides/governance/governance-model/GOVERNANCE-TEMPLATE/index.html b/docs/guides/governance/governance-model/GOVERNANCE-TEMPLATE/index.html index cd40d04a7..28aff911d 100644 --- a/docs/guides/governance/governance-model/GOVERNANCE-TEMPLATE/index.html +++ b/docs/guides/governance/governance-model/GOVERNANCE-TEMPLATE/index.html @@ -5,13 +5,13 @@ GOVERNANCE-TEMPLATE | SLIM - +

GOVERNANCE-TEMPLATE

# [INSERT PROJECT NAME] Project Governance

This governance model aims to create an open source community that encourages transparency, contributions, and collaboration, but maintains sound technical and quality standards. Our goal is to build a community comprised of members across the [INSERT PROJECT DOMAIN] community and beyond, including from private organizations, universities, government organizations, and international organizations. 

The project follows a fairly liberal contribution model where people and/or organizations who do the most work will have the most influence on project direction. Roles determine decision making influence, and governing committees (e.g. technical steering, project steering) are set up to ensure the project's direction is in-line with requirements / goals while supporting flexibility for future growth and membership. Technical decision making will primarily be made through a "[consensus-seeking](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)" approach within the respective governing committees. 

## Roles

| Role                                | Restricted To | Description                                                                                                                                                                           | Read/Clone                           | Propose Pull Request                 | Comment in Tickets / Discussions     | Triage                               | Review                               | Commit                               | Technical Decisions                  | Project Decisions                    |
| ----------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ | ------------------------------------ | ------------------------------------ | ------------------------------------ | ------------------------------------ | ------------------------------------ | ------------------------------------ | ------------------------------------ |
| User                                | None          | Anyone downloading, deploying, or operating the software to meet a specific objective.                                                                                                | ✅ | ✅ | ✅ | ❌    | ❌    | ❌    | ❌    | ❌    |
| Contributor                         | None          | Anyone providing input to the project, including: code, issues, documentation, graphics, etc.                                                                                         | ✅ | ✅ | ✅ | ❌    | ❌    | ❌    | ❌    | ❌    |
| Triager                             | Contributor   | Subset of contributors demonstrating a strong familiarity with the project.                                                                                                           | ✅ | ✅ | ✅ | ✅ | ❌    | ❌    | ❌    | ❌    |
| Collaborator                        | Contributor   | Subset of contributors granted write access to one or more of the project repositories upon selection by TSC                                                                          | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌    | ❌    |
| Technical Steering Committee Member | Collaborator  | A subset of collaborators having technical decision making authority and admin privileges                                                                                             | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌    |
| Project Steering Committee Member   | Stakeholders  | Sponsor organization representatives (i.e. those providing funding to the project) and key stakeholders with authority to guide project based on requirements, budget, schedule, etc. | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Product Manager                     | Stakeholders  | Overall manager of project with final authority over all key decisions when consensus cannot be reached                                                                                    | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |

### User

Anyone who has downloaded, deployed, or operated [INSERT PROJECT NAME] to meet a specific objective. This project was primarily designed for [INSERT DESCRIPTION OF PROJECT PURPOSE], but let us know if you've found other uses for it.  

### Contributor

Contributors include anyone that provides input to the project. This includes code, issues, documentation, graphics, designs, or anything else that tangibly improves the project. We encourage you to start contributing right away by joining our [Discussions]([INSERT LINK TO DISCUSSION BOARD OR MAILING LIST(S)]) or submitting an [Issue]([INSERT LINK TO ISSUE TRACKING SYSTEM]). 

### Triager

Subset of contributors who have demonstrated a strong familiarity with the project and are regularly contributing to the project via issue creation, commenting, discussions, etc. Triagers are given specific permissions do the following:

    - Label issues and pull requests
    - Comment, close, and reopen issues and pull requests

[List of current Triagers]([INSERT LINK TO GITHUB, GITLAB, ETC. TEAM ASSOCIATED WITH TRIAGERS])
 
### Collaborator

Subset of contributors who have been given write access to one or more project repositories. Both contributors and collaborators can propose changes to the project via pull requests, but only collaborators can formally review and approve (merge) these requests. Any contributor who has made a non-trivial contribution should be on-boarded as a collaborator in a timely manner. 

If you are planning on making a substantial contribution to the project or feel as though you should be given write access to a repository, please send a request to [INSERT LINK TO EMAIL/GITHUB USER HANDLE]

[List of current collaborators]([INSERT LINK TO GITHUB, GITLAB, ETC. TEAM ASSOCIATED WITH COLLABORATORS])

### Technical Steering Committee Member

A subset of the collaborators forms the Technical Steering Committee (TSC). The TSC has authority over the following aspects of this project:

- Technical direction and guidance
- Committee governance and process 
- Contribution policy
- Conduct guidelines
- Maintaining the list of collaborators

#### TSC Committee Members
- [INSERT MEMBER NAME] ([username1]([INSERT LINK TO USERNAME]), [INSERT ORG ASSOCIATION]
- [INSERT MEMBER NAME] ([username1]([INSERT LINK TO USERNAME]), [INSERT ORG ASSOCIATION]


<details>

<summary>Emeriti</summary>

#### TSC Emeriti
- [INSERT MEMBER NAME] ([username1]([INSERT LINK TO USERNAME]), [INSERT ORG ASSOCIATION]

</details>
 
#### Scope

The TSC is primarily responsible for the following project repositories:

- [INSERT LINK TO PROJECT REPOSITORIES]

However, the TSC also has the responsibility to interface with and monitor third-party dependencies of the project for key changes impacting [INSERT PROJECT NAME]. These third-party dependencies include:

- [INSERT LINK TO DEPENDENT PROJECT REPOSITORIES]


#### Decision Making Process

Any community member can create an issue or comment asking the TSC to review something. Prior to implementing a substantial contribution, the design of that contribution should be reviewed by at least one member of the TSC. If consensus-seeking fails during the review of a pull request or in design discussions, the issue will be addressed by the TSC to make a determination on direction. TSC members will meet regularly and will keep track of decisions made when consensus was not met. 

The TSC can nominate new members at any time. Candidates for membership tend to be collaborators who have shown great dedication to the project and/or experts in a particular domain or project component. TSC members are expected to be active contributors or members who have made significant contributions within the past 12 months. 

### Project Management Committee (PMC) Member

The Project Management Committee (PMC) is made up of sponsor organization representatives (i.e. those providing funding to the project) and key stakeholders who rely or plan to rely on the project to meet a critical need. The PMC has the following responsibilities:

- Maintaining the overall project roadmap
- Determining project requirements and commitments to sponsors and stakeholders
- Assessing available resources and allocating them across the project
- Monitoring and reporting on progress against the roadmap 
- On-boarding new sponsors and stakeholders
- Overall project governance (including this policy)
- Addressing any legal considerations

#### PMC Committee Members
- [INSERT MEMBER NAME] ([username1]([INSERT LINK TO USERNAME]), [INSERT ORG ASSOCIATION]
- [INSERT MEMBER NAME] ([username1]([INSERT LINK TO USERNAME]), [INSERT ORG ASSOCIATION]

<details>

<summary>Emeriti</summary>

#### PMC Emeriti
- [INSERT MEMBER NAME] ([username1]([INSERT LINK TO USERNAME]), [INSERT ORG ASSOCIATION]

</details>   

#### Scope

The PMC has management authority over the same project repositories over which the TSC has technical authority over.   

#### Decision Making Process

The PMC will consist of a product manager and additional representative from sponsors and key stakeholders. The PMC or sponsoring organizations can nominate new members at any time. Care should be taken not to include too many members from a single stakeholder project or organization.

Regular stakeholder meetings are held to discuss current project status and propose changes to the project roadmap. If stakeholder representatives and sponsors concur with these proposals during the meeting, they will be immediately adopted. A member of the PMC will ensure the changes have been captured and recorded. Regular stakeholder meetings will be open to the entire community, but only members of the PMC have decision making authority. 

Additional meetings may be held if consensus is not met or to discuss significant changes to the roadmap due to changes in stakeholder priorities or available resources. Any decision made outside of stakeholder meetings must still be approved by all sponsors and stakeholders. If full consensus cannot be made, the product manager has the final authority to determine project direction. Any non-concurrences from stakeholders or sponsors will be noted. 

### Product Manager

Overall manager of the project with final authority over all key decisions when consensus cannot be reached within the TSC or PSC. The product manager is often chosen at the onset of project initiation and can be reassigned by the PMC (with institutional approval, if applicable).

# Acknowledgements

Much of this governance model was adapted from the other notable open source projects including [node.js](https://github.com/nodejs/node/blob/main/GOVERNANCE.md), [OpenSSL](https://www.openssl.org/policies/omc-bylaws.html), [PostgresQL](https://www.postgresql.org/developer/), and [OpenMCT](https://github.com/nasa/openmct/blob/master/CONTRIBUTING.md). We would like to thank those projects for setting the foundation upon which this model was built.
- + \ No newline at end of file diff --git a/docs/guides/governance/governance-model/governance-template-small-team/index.html b/docs/guides/governance/governance-model/governance-template-small-team/index.html index 28f56ee41..80c0df9a7 100644 --- a/docs/guides/governance/governance-model/governance-template-small-team/index.html +++ b/docs/guides/governance/governance-model/governance-template-small-team/index.html @@ -5,13 +5,13 @@ governance-template-small-team | SLIM - +

governance-template-small-team

# [INSERT PROJECT NAME] Project Governance

This governance model aims to create an open source community that encourages transparency, contributions, and collaboration, but maintains sound technical and quality standards. Our goal is to build a community comprised of members across the [INSERT PROJECT DOMAIN] community and beyond, including from private organizations, universities, government organizations, and international organizations.

The project follows a fairly liberal contribution model where people and/or organizations who do the most work will have the most influence on project direction. Roles determine decision making influence, and a governing Steering Committee is set up to ensure the project's direction is in-line with requirements/goals while supporting flexibility for future growth and membership. Decision making will primarily be made through a "[consensus-seeking](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)" approach within the Steering Committee.

## Roles

| Role               | Restricted To | Description                                                                                                                                                                           | Read/Clone | Propose Pull Request | Comment in Tickets / Discussions | Triage | Review | Commit | Decisions                  |
| ------------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | -------------------- | -------------------------------- | ------ | ------ | ------ | ------------------------- |
| User               | None          | Anyone downloading, deploying, or operating the software to meet a specific objective.                                                                                                | ✅          | ✅                    | ✅                               | ❌       | ❌      | ❌      | ❌                         |
| Contributor        | None          | Anyone providing input to the project, including: code, issues, documentation, graphics, etc.                                                                                         | ✅          | ✅                    | ✅                               | ❌       | ❌      | ❌      | ❌                         |
| Committer       | Contributor   | Subset of contributors granted write access to one or more of the project repositories.                                                                                               | ✅          | ✅                    | ✅                               | ✅       | ✅      | ✅      | ❌                         |
| Steering Committee Member | Committer  | A subset of committers with decision making authority over technical and project aspects, including admin privileges.                                                               | ✅          | ✅                    | ✅                               | ✅       | ✅      | ✅      | ✅                         |
| Product Manager    | Steering Committee Member  | Overall manager of project with final authority over all key decisions when consensus cannot be reached within the Steering Committee.                                                 | ✅          | ✅                    | ✅                               | ✅       | ✅      | ✅      | ✅                         |

### User

Anyone who has downloaded, deployed, or operated [INSERT PROJECT NAME] to meet a specific objective. This project was primarily designed for [INSERT DESCRIPTION OF PROJECT PURPOSE], but let us know if you've found other uses for it.  

### Contributor

Contributors include anyone that provides input to the project. This includes code, issues, documentation, graphics, designs, or anything else that tangibly improves the project. We encourage you to start contributing right away by joining our [Discussions]([INSERT LINK TO DISCUSSION BOARD OR MAILING LIST(S)]) or submitting an [Issue]([INSERT LINK TO ISSUE TRACKING SYSTEM]). 

### Triager

Subset of contributors who have demonstrated a strong familiarity with the project and are regularly contributing to the project via issue creation, commenting, discussions, etc. Triagers are given specific permissions do the following:

    - Label issues and pull requests
    - Comment, close, and reopen issues and pull requests

[List of current Triagers]([INSERT LINK TO GITHUB, GITLAB, ETC. TEAM ASSOCIATED WITH TRIAGERS])
 
### Collaborator

Subset of contributors who have been given write access to one or more project repositories. Both contributors and collaborators can propose changes to the project via pull requests, but only collaborators can formally review and approve (merge) these requests. Any contributor who has made a non-trivial contribution should be on-boarded as a collaborator in a timely manner. 

If you are planning on making a substantial contribution to the project or feel as though you should be given write access to a repository, please send a request to [INSERT LINK TO EMAIL/GITHUB USER HANDLE]

[List of current collaborators]([INSERT LINK TO GITHUB, GITLAB, ETC. TEAM ASSOCIATED WITH COLLABORATORS])

### Steering Committee Member

A subset of collaborators form the Steering Committee. The Steering Committee has authority over all aspects of this project:

- Technical direction and guidance
- Project governance and process
- Contribution policy
- Conduct guidelines
- Maintaining the list of collaborators

#### Committee Members
- [INSERT MEMBER NAME] ([username1]([INSERT LINK TO USERNAME]), [INSERT ORG ASSOCIATION]
(Additional member listings)

<details>
<summary>Emeriti</summary>
#### Committee Emeriti
- [INSERT MEMBER NAME] ([username1]([INSERT LINK TO USERNAME]), [INSERT ORG ASSOCIATION]
(Additional member listings)
</details>

#### Scope
(Description remains the same as TSC Scope)

#### Decision Making Process
(Description remains the same as TSC Decision Making Process)

### Product Manager
(Description remains the same)

# Acknowledgements
(Description remains the same)
- + \ No newline at end of file diff --git a/docs/guides/governance/governance-model/index.html b/docs/guides/governance/governance-model/index.html index 8df55107a..3dbe62e79 100644 --- a/docs/guides/governance/governance-model/index.html +++ b/docs/guides/governance/governance-model/index.html @@ -5,13 +5,13 @@ Governance Model | SLIM - +

Governance Model

Establish a project guide for effective open source governance.

governance-screenshot-example

Example GOVERNANCE.md template rendering

Introduction​

Background: A governance model is essential for government-sponsored open source projects, particularly for medium and large-sized teams. It helps in liberal acceptance of public contributions while retaining decision-making authority with funding sources. This guide provides a template to integrate a generalized governance model into your project, promoting clear operational structure and community engagement.

Use Cases:

  • Structuring decision-making processes in open source projects.
  • Balancing open contribution with authoritative project direction.
  • Establishing clear roles and responsibilities within the project team.

Prerequisites​

  • Understanding of open source project management.
  • Familiarity with Markdown for editing GitHub documentation.

Quick Start​

Governance Model Template (see example)

Access our recommended template to start integrating a governance model into your project.

Step-by-Step Guide​

  1. Team Consultation: Collaborate with your team and stakeholders to discuss adopting the governance model template. You'll want to consider topics like:
    • Roles (and how contributors can be promoted between roles)
    • Committees (the groups that guide your project)
  2. Customize the Template:
    • View and download our Governance Model Template.
    • Place the template in a GOVERNANCE.md file within the root folder of your repository.
    • Modify and personalize the template, replacing [INSERT ...] text with specifics for your project.
  3. Implement the Governance Model:
    • Commit the GOVERNANCE.md file to the main branch.
    • Link to the governance document in your README.md file under the Contributing section.

Frequently Asked Questions (FAQ)​

  • Q: What is the importance of a governance model in open source projects?
  • A: It provides a framework for decision-making, contribution processing, and project management, ensuring transparent and structured project operations.
  • Q: What is the role of the Technical Steering Committee (TSC) in this governance model?
  • A: The TSC handles technical decisions, governance processes, and maintains collaborator lists, playing a key role in guiding the project's technical aspects.
  • Q: How are conflicts resolved in this governance model?
  • A: The model advocates for consensus-seeking; however, if consensus cannot be reached, the Product Manager has final authority, ensuring decision-making progresses.
  • Q: Can the governance structure be modified as the project evolves?
  • A: Yes, the model is flexible and can adapt to changing project needs, subject to agreement by the Project Steering Committee (PMC) and stakeholders.

Credits​

Authorship:

Acknowledgements:

This template was developed by evaluating best GOVERNANCE.md practices in the following organizations:

Feedback and Contributions​

We invite feedback and contributions to refine this guide. Visit our contribution guidelines.

- + \ No newline at end of file diff --git a/docs/guides/search/index.html b/docs/guides/search/index.html index c38df08eb..bedcef6a4 100644 --- a/docs/guides/search/index.html +++ b/docs/guides/search/index.html @@ -5,13 +5,13 @@ 🔍 Explore Our Guides | SLIM - +
-

🔍 Explore Our Guides

Explore our guides via the categories below or the left-hand navigation. You may also search our guides.


- +

🔍 Explore Our Guides

Explore our guides via the categories below or the left-hand navigation. You may also search our guides.


+ \ No newline at end of file diff --git a/docs/guides/software-lifecycle/application-starter-kits/python-starter-kit/index.html b/docs/guides/software-lifecycle/application-starter-kits/python-starter-kit/index.html index 9711f1fae..e3aa9164b 100644 --- a/docs/guides/software-lifecycle/application-starter-kits/python-starter-kit/index.html +++ b/docs/guides/software-lifecycle/application-starter-kits/python-starter-kit/index.html @@ -5,7 +5,7 @@ Python Starter Kit | SLIM - + @@ -15,7 +15,7 @@ Documentation requiring updates are marked with the keyword INSERT.

  • Apply Project Settings:

    • Update pyproject.toml to update build system dependencies
    • Update setup.cfg to specify build system configurations
      • Edit the metadata keywords to set appropriate keyword values to apply to your project.
        1. Set name to match your unique module name.
        2. Modify console_scripts to point at your entry-point:
          1. If your module launches from a command-line, define an executable inside your module: executable-name = my_package.module:function.
          2. Set the value as empty if there is no entry-point.
        3. Update URLs for your project.
          1. Replace NASA-AMMOS/slim-starterkit-python with the project/repo_name for your cloned project (or refactoring on an existing repo).
        4. Update author, author_email, description and keywords to reflect your project details

  • Build Locally: The application will build, install and deploy from a local command line when all configurations are properly set.

    • Install local tooling and requirements
    • Clean and build and clean again after module builds successfully

      Information
      To validate deployment, we publish the module to the Test PyPi sandbox by default. To publish on the official PyPi, a minor configuration change is required. All previous steps must be complete and the application must build successfully.

  • Build on GitHub: A release kicks off a build and release process in GitHub Actions.

    • Additional Files​

    This starter kit produces several deliverables deployed for distribution:

    Frequently Asked Questions (FAQ)​

    • Q: What tooling is necessary to use the starter kit?

    • A: Python 3 version 3.9 or greater must be installed with a working package manager (pip). As well, you'll need the latest versions of pip, build, setuptools, twine and wheel.

      python3 --version  # must report Python >3.9.x
      pip3 install --upgrade pip
      pip3 install --upgrade build setuptools setuptools_scm twine wheel

    • Q: How do I choose a unique module name for PyPi?

    • A: Research existing modules on PyPi and select a name that is not already in use. Consider using a creative and/or descriptive name relevant to your project.

    Credits​

    Authorship:

    Acknowledgements:

    • Inspiration and practices from modern Python tooling and GitHub CI/CD workflows.

    Feedback and Contributions​

    We welcome feedback and contributions to improve this guide. Please see our contribution guidelines.

    - + \ No newline at end of file diff --git a/docs/guides/software-lifecycle/continuous-integration/continuous-integration-frameworks/index.html b/docs/guides/software-lifecycle/continuous-integration/continuous-integration-frameworks/index.html index 9fdd08dca..12154cfd2 100644 --- a/docs/guides/software-lifecycle/continuous-integration/continuous-integration-frameworks/index.html +++ b/docs/guides/software-lifecycle/continuous-integration/continuous-integration-frameworks/index.html @@ -5,13 +5,13 @@ CI Tools and Frameworks | SLIM - +

    CI Tools and Frameworks

    - + \ No newline at end of file diff --git a/docs/guides/software-lifecycle/continuous-integration/index.html b/docs/guides/software-lifecycle/continuous-integration/index.html index 28d194dfb..38f9ce763 100644 --- a/docs/guides/software-lifecycle/continuous-integration/index.html +++ b/docs/guides/software-lifecycle/continuous-integration/index.html @@ -5,13 +5,13 @@ Continuous Integration | SLIM - +

    Continuous Integration

    A guide for implementing continuous integration in software projects.

    Introduction​

    Background: Continuous Integration (CI) is a critical practice in modern software development. This guide introduces a comprehensive approach to CI from analysis and testing to orchestration and release management. We focus on using a variety of tools like Git hooks, GitHub Actions, Jenkins and more to create a robust CI pipeline. By following this guide and combining these tools, developers can automate their build and testing processes, ensuring software is always ready for deployment.

    Use Cases:

    • Automating software integration, build and testing.
    • Streamlining software release and deployment.
    • Ensuring software quality and reliability through repeatable engineering processes.

    Prerequisites​

    • Basic knowledge of software development and version control systems.
    • Familiarity with CI/CD concepts and practices.

    Quick Start​

    📔 CI Tools and Frameworks

    Click the link above to explore various tools and systems for setting up and optimizing your CI pipeline.

    📔 CI Reference Architectures

    Click the link above to explore the overall sample architecture for a continuous integration system.

    Step-by-Step Guide​

    1. Explore CI Tools and Frameworks:

      • Start with the CI Tools and Frameworks guide to explore a range of task-focused CI tools.
      • Review different categories, such as Analysis and Testing, Credentialing, and Execution and Reporting Tests.
      • Based on your use case, select appropriate tools, e.g. Git hooks, GitHub Actions, Jenkins, Maven plugins or SetupTools, that are are designed for the software and technologies used in your product.

    2. Understand the Reference Architecture:

      • Dive into the CI Reference Architectures for an overview of the CI process and its components.
      • Understand the core concepts of the CI pipeline, which involves Developer systems, Continuous Integration services, Continuous Deployment platforms and other touchpoints.
      • Learn about the discrete process steps in a CI pipeline, such as Compile, Test, Package, Publish and Deploy (i.e. release or deliver), and how they contribute to building and releasing software.

    3. Combine Reference Architecture with Selected Tools:

      • With the understanding of CI tools from Step 1, and the architectural insights from Step 2, begin mapping tools to specific roles in your CI pipeline.
      • For example:
        • Use Git hooks for code check-ins and GitHub Actions for automated build and testing processes.
        • Utilize Jenkins or GitHub Actions for more complex workflows, like orchestrating builds across different environments or managing deployment strategies.
        • Implement credentialing tools like Jenkins Credentials Binding Plugin or OAuth for secure access to resources.
        • Ensure testing is thorough by integrating language-specific plugins or frameworks, such as Maven for Java or PyTest for Python, into your build process.
        • Use orchestration tools like Ansible for deployment, aligning them with your cloud infrastructure managed by Terraform or Kubernetes.
        • Package your application using Docker or appropriate tools, ensuring a streamlined process from development to deployment.
    • Update a copy of the reference architectural diagram with your selected tools.

    Frequently Asked Questions (FAQ)​

    • Q: How do I choose the right CI tools for my project?

    • A: Consider your project’s language, complexity and the specific needs of your deployment environment. Research and compare tools to find the best fit for your workflow.

    • Q: What is the difference between Continuous Integration, Continuous Deployment and Continuous Delivery?

    • A: These related concepts apply to different target stages of a comprehensive CI/CD process, but their definitions are often conflated. Each one of these stages determines the endpoint as builds progress in a given automation process.

      • Continuous Integration (code compiles) tests whether code when merged from different developer systems can be compiled together on a control system, e.g. the CI server.
      • Continuous Deployment (packages published) is the publishing of successfully compiled and packaged binaries to an artifact repository and/or local test servers.
      • Continuous Delivery (packages released) extends deployment by pushing packaged binaries immediately to production services upon successful build, test and publishing.

    Credits​

    Authorship:

    Acknowledgements:

    • This guide was inspired by the comprehensive tooling options available in the CI/CD ecosystem.

    Feedback and Contributions​

    Your feedback and contributions are vital to the continuous improvement of this guide. Please see our contribution guidelines for more information.

    - + \ No newline at end of file diff --git a/docs/guides/software-lifecycle/continuous-integration/reference-architecture/index.html b/docs/guides/software-lifecycle/continuous-integration/reference-architecture/index.html index 6d2a10116..2c8245d45 100644 --- a/docs/guides/software-lifecycle/continuous-integration/reference-architecture/index.html +++ b/docs/guides/software-lifecycle/continuous-integration/reference-architecture/index.html @@ -5,7 +5,7 @@ CI Reference Architectures | SLIM - + @@ -95,7 +95,7 @@ mechanism to produce reliable software that is transparent and self-validating. This lends itself to tested, reproducible software deliveries with the crisp reliability and speed of automated systems.

    - + \ No newline at end of file diff --git a/docs/guides/software-lifecycle/continuous-testing/index.html b/docs/guides/software-lifecycle/continuous-testing/index.html index 5aa55ea1e..46c9b9289 100644 --- a/docs/guides/software-lifecycle/continuous-testing/index.html +++ b/docs/guides/software-lifecycle/continuous-testing/index.html @@ -5,13 +5,13 @@ Continuous Testing | SLIM - +
    - + \ No newline at end of file diff --git a/docs/guides/software-lifecycle/continuous-testing/testing-frameworks/index.html b/docs/guides/software-lifecycle/continuous-testing/testing-frameworks/index.html index 529cbf0a4..389a76950 100644 --- a/docs/guides/software-lifecycle/continuous-testing/testing-frameworks/index.html +++ b/docs/guides/software-lifecycle/continuous-testing/testing-frameworks/index.html @@ -5,13 +5,13 @@ Testing Frameworks | SLIM - +

    Testing Frameworks

    - + \ No newline at end of file diff --git a/docs/guides/software-lifecycle/metrics/index.html b/docs/guides/software-lifecycle/metrics/index.html index 1335c213d..909ce0e08 100644 --- a/docs/guides/software-lifecycle/metrics/index.html +++ b/docs/guides/software-lifecycle/metrics/index.html @@ -5,14 +5,14 @@ Metrics | SLIM - +

    Metrics

    A Guide for Configuring and Deploying Software Lifecycle Metrics Tracking.

    slim-dashboard Example Metrics Dashboard using Apache DevLake

    Introduction​

    Metrics collection is important for project management and software quality assurance. We recommend Apache DevLake for easy tracking and analysis. This guide simplifies its installation and configuration, especially for developers new to metrics collection.

    Use Cases:

    • Collecting and analyzing DORA metrics along with many others for your project.
    • Creating a visual dashboard to view metrics from multiple sources (e.g., GitHub, JIRA) in one place.
    • Streamlining the setup and configuration of Apache DevLake through a single-command setup step.
    • Gain insight into organizational and project performance for software development and the overall software lifecycle.

    Why We Chose Apache DevLake:

    Our decision to select Apache DevLake was informed by thorough trade study documentation, available here.

    Prerequisites​

    • Familiarity with Docker as well as a running instance of it
    • A familiarity with validated software metrics is not required for this tool but it is recommended

    Quick Start​

    To quickly deploy DevLake on one of your servers or locally for testing, we've developed a convenient 1-step command. Please ensure Docker is running on your system before executing this command.

    The purpose of this script is to automate the installation process DevLake recommends here. The script does the following:

    • Checks for necessary software: ensures you have Docker and docker-compose installed to run DevLake.
    • Downloads required files: automatically retrieves setup files if they're not already present on your system.
    • Prepares setup files: adjusts file permissions and sets up the necessary environment variables for DevLake.
    • Secures the setup: generates a unique encryption key for data security.
    • Starts DevLake: uses Docker to initialize the DevLake application in the background and guides you to visit a web address to start using DevLake for data analysis and viewing dashboards.

    Run This Command in Your Terminal and Then Move on to the Next Step of the Configuration Guide:

    cd /path/to/your/chosen/deployment/directory
    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/NASA-AMMOS/slim/main/docs/guides/software-lifecycle/metrics/metrics-starter-kit/install_devlake.sh)"

    To Stop Services:

    1. Navigate to the directory containing your docker-compose.yml file (where you ran the above command).

    2. Run the following command to gracefully stop all containers defined in the docker-compose.yml file:

      docker-compose down

    To Restart Services:

    1. Navigate to the directory containing your docker-compose.yml file.

    2. Run the following command to start containers for services defined in the docker-compose.yml file:

      docker-compose up -d

      The -d flag runs containers in detached mode, allowing them to run in the background.

    Step-by-Step Configuration Guide​

    1. Run the Quick Start steps above.
    2. Once you have a working DevLake instance, we recommend going through DevLake's official start guide step-by-step, beginning with the data sources section.
    3. If you're interested in sharing your dashboards with your community but are unable to host a server, you can export your dashboards by following the instructions provided here.

    There are two additional topics we'd like to emphasize. Our recommendations for data sources and metrics to collect.

    We recommend, at a minimum, connecting the following data sources (see the DevLake docs on configuring data sources for further assistance):

    See this list of metrics on the DevLake documentation guide for why certain metrics are important and how to collect them. As a minium, we recommend the following metrics should be collected for your projects:

    • Change Failure Rate: "The percentage of changes that were made to a code that then resulted in incidents, rollbacks, or any type of production failure."
    • Lead Time for Changes: "The median amount of time for a code change to be deployed into production."

    Frequently Asked Questions (FAQ)​

    • Q: How do I customize the DevLake Quick Start script for more functionality?

    • A: If you have already provided DevLake with a data source, you can further configure your dashboard by following this guide. Use simple queries to gather the information you need.

    • Q: How do export the Grafana dashboard to a PDF?

    • A: You can use this tool.

    Credits​

    Authorship:

    Feedback and Contributions​

    We value your feedback and welcome contributions to improve this guide. Please see our contribution guidelines.

    Acknowledgements:

    • The NISAR and SWOT missions for their experience deploying and using DevLake.
    - + \ No newline at end of file diff --git a/docs/guides/software-lifecycle/security/github-security/index.html b/docs/guides/software-lifecycle/security/github-security/index.html index 932e4cb62..45a5f192d 100644 --- a/docs/guides/software-lifecycle/security/github-security/index.html +++ b/docs/guides/software-lifecycle/security/github-security/index.html @@ -5,13 +5,13 @@ GitHub Security Best Practices | SLIM - +

    GitHub Security Best Practices

    Recommendations for enabling GitHub security features for your repositories.

    gh-security-screenshot-example

    Example GitHub security tools rendering

    Introduction​

    Background: GitHub offers a suite of security features to help maintainers and developers protect their code and ensure the safety of their repositories. From automatically detecting vulnerabilities in dependencies to scanning for secrets and setting security policies, these tools are essential for any project, especially in today’s security-conscious environment.

    Use Cases:

    • Being alerted over e-mail or GitHub notifications about known vulnerabilities in your dependencies and having pull-requests automatically created to resolve the issues.
    • Being alerted if your dependencies have updated versions available.
    • Being alerted if your commits have potentially harmful secrets or sensitive information within the code - including being blocked from pushing your commits.

    Prerequisites​

    • A GitHub repository
    • Familiarity with GitHub’s user interface
    • Admin rights for certain security configuration tasks
    • Team discussion: before diving into any configurations, we recommend engaging with your development team about the importance of GitHub’s security features. Establish a consensus on which ones to prioritize and implement.

    Quick Start​

    The fastest way to enable recommended GitHub Security features is to perform it in bulk for all of your repositories within a given organization. Consult Enabling security features for multiple repositories for details. Organization administrative-level access is required.

    We recommend enabling the below features for all your repositories:

    img

    Specifically:

    • Dependency graphs (select "Enable All")
      • Select "Automatically enable for new private repositories"
    • Dependabot Alerts (select "Enable All")
      • Select "Automatically enable for new repositories"
    • Dependabot Security Updates (select "Enable All")
      • Select "Automatically enable for new repositories"
    • Code Scanning (select "Enable All")
      • Select the default "CodeQL high-precision queries" option

    If you do not have organizational permissions or if you wish to customize security features per repository, see our Step-by-Step guide below for repository-specific guidance.

    Step-by-Step Guide per Repository​

    1. Set Up Dependabot:
      • Navigate to your repository and click on the Settings tab.
      • From the left sidebar, select the Code security and analysis menu.
      • Under the "Dependabot" section:
        • We recommend enabling Dependabot alerts to stay informed about insecure dependencies in your project.
        • For added security, we suggest turning on Dependabot security updates to automatically generate pull requests for known vulnerabilities in your dependencies.
        • We also recommend enabling Dependabot version updates if you are using a package manager for your project. This will help you keep your dependencies up-to-date. To configure Dependabot version updates:
          1. Create a .github/dependabot.yml file in your repository.
          2. Specify the package-ecosystem, directory, schedule and branch to update. For example, the below demonstrates a Python dependabot.yml example from the SLIM Python Starter Kit:
            version: 2
            updates:
              - package-ecosystem: 'pip'
                directory: '/' # location of package manifests
                schedule:
                  interval: 'daily'
                  time: '09:00'
                  timezone: 'America/Los_Angeles'
                target-branch: 'main'
                labels:
                  - 'dependencies'
      • To view Dependabot alerts and version updates:
        • Head back to the main page of your repository.
        • Click on the Security tab. Here, you can select Dependabot alerts to view security alerts, and you can see version updates in the Pull requests tab labeled with "Dependabot".

    1. Enable Code Scanning:

      • In the Code security and analysis menu from the Settings tab, click the "Set Up" or enable the following workflows:
        • CodeQL Analysis workflow: a free tool provided by GitHub that scans your code for vulnerabilities across a variety of languages. Simply choose a CodeQL Analysis template (default is acceptable) and follow the instructions.
      • To view Code scanning alerts:
        • Return to the repository main page.
        • Click on the Security tab and select Code scanning alerts.

    2. Enable Secret Scanning:

      • In the Code security and analysis menu from the Settings tab:
        • Click on the Secret scanning enable button.
        • We recommend enabling "Push protection" for blocking commits containing secrets
      • To view Secret scanning alerts:
        • Navigate to the repository main page.
        • Click on the Security tab and select Secret scanning alerts.

    Frequently Asked Questions (FAQ)​

    • Q: Can these security features be used outside of GitHub?

      A: This guide specifically focuses on GitHub’s ecosystem. While some tools might have external equivalents, the integrations and configurations here are GitHub-specific.

    • Q: Are these security features available on GitHub Enterprise?

      A: It depends on your institution's particular version of GitHub deployed. You'll have to check your Settings tab to view the features that are provided. GitHub.com is the most up-to-date version we recommend for.

    • Q: If I receive security alerts, what should I do and how soon should I act?

      A: When you receive a security alert, it indicates a potential vulnerability in your repository. First, review the details of the alert to understand the severity and the affected component. Address critical vulnerabilities immediately, as they can pose a significant risk to your project. For less severe alerts, plan to address them in a timely manner. Always keep in mind that the sooner you act on security alerts, the better you can protect your code and users from potential threats.

    Credits​

    Authorship:

    Acknowledgements:

    • GitHub for providing the security features and related documentation. See GitHub’s Security Features to access an overview of the suite of security features GitHub provides for repositories.
    • OWASP DevSecOps Guideline for providing a Shift Left strategy to secure all phases of development.

    Feedback and Contributions​

    We welcome feedback and contributions to help improve and grow this guide. Please see our contribution guidelines.

    - + \ No newline at end of file diff --git a/docs/guides/software-lifecycle/security/secrets-detection/index.html b/docs/guides/software-lifecycle/security/secrets-detection/index.html index 7741fe563..31fc3afd6 100644 --- a/docs/guides/software-lifecycle/security/secrets-detection/index.html +++ b/docs/guides/software-lifecycle/security/secrets-detection/index.html @@ -5,13 +5,13 @@ Secrets Detection | SLIM - +

    Secrets Detection

    Guide to identify and automatically prevent leaking of sensitive information into your codebase.

    secrets-screenshot-example

    Example secrets scanning rendering

    Introduction​

    Background: Sensitive information like API keys, passwords or tokens may be inadvertently committed to your repository. Such slip-ups can pose significant security risks. We recommend not only recurring scans for sensitive information, but proactively preventing sensitive information from getting infused. To support these goals, we recommend a tool called detect-secrets that mitigates these risks. It scans for common sensitive information categories like passwords and other high-entropy values that contain sensitive data. It also provides a plugin system to support additional customization. It's fast for use in continuous integration pipelines and quickly executes on local-developer machines. It uses a "baseline file" approach, leveraging .secrets.baseline, that streamlines management of legitimate secrets and reduces false positives. This helps both new and established projects detect and prevent secrets from entering the code base.

    Use Cases:

    • Finding and preventing commits of sensitive information such as:
      • Username / passwords
      • High entropy strings
      • IP addresses
      • E-mail addresses
      • AWS sensitive information
    • Scanning local client repositories for exposed sensitive information before making them public.
    • Preventing secrets from being committed to a local repository using pre-commit hooks.
    • Implementing a safety net in continuous integration (CI) pipelines using GitHub Actions to catch inadvertent secret commits.
    • Streamlining the management of known secrets and false positives during codebase audits.

    Prerequisites​

    To get the most out of detect-secrets, you'll need:

    • Python 3 with the pip tool installed.
    • (Optional) Familiarity with Python for potential custom plugin development.
    • (Optional) A GitHub repository supporting GitHub Actions.

    Quick Start​

    1. Install slim-detect-secrets:

      ℹ️ Note: the SLIM project has customized the Detect Secrets tool to identify additional sensitive keywords such as IP addresses, file paths, and AWS information. These additions are currently under review by the detect-secrets team for merge into the tool's main codebase. Until then we recommend using our SLIM fork as described below. 

      pip install git+https://github.com/NASA-AMMOS/slim-detect-secrets.git@exp

    2. Execute a baseline scan:

      detect-secrets scan --all-files --disable-plugin AbsolutePathDetectorExperimental --exclude-files '\.secrets.*' --exclude-files '\.git*' > .secrets.baseline

    3. Review the .secrets.baseline file for any detected secrets via an audit:

      detect-secrets audit .secrets.baseline

    Additional steps like whitelisting accepted values and false positives, establishing pre-commit hooks and/or enabling further automation are covered in detail below.

    Step-by-Step Guide​

    There are three recommended layers of protection we suggest you enable to ensure comprehensive security. Please see below sections for further details.

    Layer 1: Full Scan and Audit (Client-side)​

    This layer directly scans the developer's local environment using the detect-secrets tool. After scanning, a baseline file containing detected secrets is generated. Developers can audit this file for detailed information on detected secrets.

    Steps​

    1. Installation

      • Install the experimental version of slim-detect-secrets.
        pip install git+https://github.com/NASA-AMMOS/slim-detect-secrets.git@exp

    2. Scanning

      • Scan all local files from the current directory and output results to a baseline file.
        detect-secrets scan --all-files --disable-plugin AbsolutePathDetectorExperimental --exclude-files '\.secrets.*' --exclude-files '\.git*' > .secrets.baseline

    3. Checking Results

      • View the results in the baseline file.
        cat .secrets.baseline

    4. Analysis

      • Analyze results using the audit tool.
        detect-secrets audit .secrets.baseline

    View more on Auditing Secrets in Baseline

    ℹ️ Note: If you've marked any secrets as true positives, make sure to remove all references to these secrets and rerun a full scan.

    Layer 2: Git Commit Scan (Client-side)​

    This layer represents a prevention mechanism in the local developer environment that scans changes when a developer tries to commit and if new secrets are detected, the commit is blocked.

    To support this strategy, we recommend the installation of another third party tool called pre-commit, which is integral in allowing specialized plugins to run during the local developer's commit phase of using Git. It allows detect-secrets to prevent commits that are flagged with sensitive information.

    Steps​

    1. Installation

    2. Configuration

      • Create a .pre-commit-config.yaml configuration file with the below contents.

          repos:
            - repo: https://github.com/NASA-AMMOS/slim-detect-secrets
              # using commit id for now, will change to tag when official version is released
              rev: 91e097ad4559ae6ab785c883dc5ed989202c7fbe
              hooks:
                - id: detect-secrets
                  args:
                    - '--baseline'
                    - '.secrets.baseline'
                    - '--exclude-files'
                    - '\.git*'
                    - '--exclude-files'
                    - '\.secrets.*'

    3. Hook Installation

      • Install the pre-commit hook into your local environment, ensuring the hook gets invoked during local git commits.

        pre-commit install

    4. Committing Changes

      • Commit changes. If new secrets are detected, the commit will be blocked.

    ℹ️ Note: The pre-commit hook does not automatically update the .secrets.baseline file. Update it by re-running the scan command.

    Layer 3: Server-side Push to GitHub.com​

    This strategy provides a final layer of protection by scanning server-side commits for sensitive information during pull request creation. It leverages the pre-commit tool and GitHub Action. The scan is triggered during a push or pull request and any detected new secrets are reported while blocking merges or pushes to protected branches.

    Steps​

    1. Workflow Creation
      • The first step is to create a detect-secrets.yaml workflow file in the .github/workflows directory to define the GitHub action. Copy and paste the below while ensuring the correct branch of your codebase is referenced. For example (from the Slim Python Starter Kit):
    name: "Secret Detection"
    on:
      push:
        branches: [main, develop]
      pull_request:
        # The branches below must be a subset of the branches above
        branches: [develop]

    jobs:
      secret-detection:
        name: Secret-Detection
        runs-on: ubuntu-latest
        permissions:
          actions: write
          contents: read
          security-events: write
        steps:
        - name: Checkout repository
          uses: actions/checkout@v4
          with:
            fetch-depth: 0
        - name: Upgrade tooling
          run: |
            python3 -m pip install --upgrade pip
            pip install --upgrade git+https://github.com/NASA-AMMOS/slim-detect-secrets.git@exp
            pip install --upgrade jq
        - name: Create baseline config
          run: |
            if [ ! -f .secrets.baseline ] ; 
            then
                # This generated baseline file will only be temporarily available on the GitHub side and will not appear in the user's local files.
                # Scanning an empty folder to generate an initial .secrets.baseline without secrets in the results.
                echo "⚠️ No existing .secrets.baseline file detected. Creating a new blank baseline file."
                mkdir empty-dir
                detect-secrets scan empty-dir > .secrets.baseline
                echo "✅ Blank .secrets.baseline file created successfully."
                rm -r empty-dir
            else
                echo "✅ Existing .secrets.baseline file detected. No new baseline file will be created."
            fi
        - name: Scan
          run: |
            # scripts scan repository for new secrets
            # backup list of known secrets
            cp -pr .secrets.baseline .secrets.new
            # find secrets in the repository
            detect-secrets scan --disable-plugin AbsolutePathDetectorExperimental --baseline .secrets.new \
                --exclude-files '\.secrets..*' \
                --exclude-files '\.git.*' \
                --exclude-files '\.mypy_cache' \
                --exclude-files '\.pytest_cache' \
                --exclude-files '\.tox' \
                --exclude-files '\.venv' \
                --exclude-files 'venv' \
                --exclude-files 'dist' \
                --exclude-files 'build' \
                --exclude-files '.*\.egg-info'
            # break build when new secrets discovered
            # function compares baseline/new secrets w/o listing results -- success(0) when new secret found
            compare_secrets() { diff <(jq -r '.results | keys[] as $key | "\($key),\(.[$key] | .[] | .hashed_secret)"' "${1}" | sort) <(jq -r '.results | keys[] as $key | "\($key),\(.[$key] | .[] | .hashed_secret)"' "${2}" | sort) | grep -q '>' ; }
            # test baseline versus new secret files
            if compare_secrets .secrets.baseline .secrets.new; 
            then
                echo "⚠️ Attention Required! ⚠️" >&2
                echo "New secrets have been detected in your recent commit. Due to security concerns, we cannot display detailed information here and we cannot proceed until this issue is resolved." >&2
                echo "" >&2
                echo "Please follow the steps below on your local machine to reveal and handle the secrets:" >&2
                echo "" >&2
                echo "1️⃣ Run the 'detect-secrets' tool on your local machine. This tool will identify and clean up the secrets. You can find detailed instructions at this link: https://nasa-ammos.github.io/slim/continuous-testing/starter-kits/#detect-secrets" >&2
                echo "" >&2
                echo "2️⃣ After cleaning up the secrets, commit your changes and re-push your update to the repository." >&2
                echo "" >&2
                echo "Your efforts to maintain the security of our codebase are greatly appreciated!" >&2
                exit 1
            else
                echo "🟢 Secrets tests PASSED! 🟢" >&1
                echo "No new secrets were detected in comparison to any baseline configurations."  >&1
                exit 0
            fi 
     > ℹ️  Explanation: The GitHub Action checks out code, installs necessary packages, checks for a baseline file, and scans the repository for secrets. If new secrets are detected, the build fails and provides guidance.

    After setting this up, GitHub will run the workflow during pushes or pull requests. If any new secrets are detected, the status check will fail and the user will be notified in the pull request.

    ⚠️ Warning: The check ensures specific lines of code that may contain sensitive information are not disclosed publicly. In GitHub Action logs only a yes/no indication of sensitive information appears. However, the surface area exists for potential attackers to readily identify sensitive information. Monitor your pull requests actively to respond and always ensure your team actively uses Layer 1 and Layer 2 to mitigate issues in the first place.

    Frequently Asked Questions (FAQ)​

    • Q: If secrets are detected in my code, what should I do?

      A: Follow these steps:

      • Identify and Confirm: Review the identified secrets in the .secrets.baseline or any other report generated. Ensure that they are indeed secrets and not false positives.
      • Removal: Remove or replace all references to the detected secrets from your codebase. Ensure that no trace of the secret remains in the code, comments, or commit history. If you want to ignore the secret as a false positive during a pre-commit scan, you can follow directions here.
      • Rotation: If the detected secret was an API key, password, or any other form of authentication, consider it compromised. Rotate the secret immediately, i.e., generate a new secret/key and update it wherever required.
      • Rerun Scans: After you've made the necessary changes, run the detect-secrets tool again to ensure no secrets remain.
      • Commit Safely: When you're sure all secrets have been removed, you can safely commit your changes. Remember, the Git commit scan (Layer 2) and the server-side push scan (Layer 3) will provide additional layers of checks.
      • Educate and Prevent: To avoid such instances in the future, educate your team on the importance of not committing secrets and the potential risks associated with it. Consider adopting practices or tools that prevent the accidental inclusion of secrets in your codebase.

    • Q: Does detect-secrets scan the entire Git history?

      A: No, it's designed to scan the current state of a project for efficiency.

    • Q: How are commits containing secrets removed permanently from Git history?

      A: The process of scrubbing errant commits and their content involves a destructive rewrite of repository commit history. Backups are essential and changes must be handled with precision and caution. One solution is to start a new repository from scratch with only the latest cleaned code, thereby negating the need to change existing repository content. Solutions involving more entropy include Git filter commands or well-known cleaning applications, such as BFG Repo-Cleaner. Because of the risks involved in mutating repository history and content, such changes always must be handled with backups, expertise and extreme care.

    • Q: Where can I find more configurations and options for detect-secrets?

      A: Refer to the official documentation for detect-secrets and pre-commit.

    Credits​

    Authorship:

    Acknowledgements:

    Feedback and Contributions​

    We value your feedback and contributions. Enhance and expand this guide by referring to our contribution guidelines.

    - + \ No newline at end of file diff --git a/docs/join/index.html b/docs/join/index.html index 6692e7f7f..f91a3581e 100644 --- a/docs/join/index.html +++ b/docs/join/index.html @@ -5,14 +5,14 @@ Join | SLIM - +

    Join

    SLIM best practice guides and recommendations are community generated, which means you can join our community!

    Some ways you can get involved with SLIM:

    Use Our Guides​

    The fastest way to join the SLIM community is to start using our best practice guides in your project(s).

    As you use our best practices, we always recommend working with your project by creating pull-requests. An excellent tool to automate the infusion of our best practices in your repositories (especially if you have many) is to use a tool like multi-gitter if you're using Git to create pull-requests.

    Some Pro ⭐️ tips:

    • Add the following badge to your README.md so that your other team members can help: SLIM
    • 👀 Watch our repo so you get updates on activities right away. In particular, ensure your notifications are set up to monitor our Releases page for key updates.

    Join Our Community of Projects​

    What does it mean to join the SLIM community as a member project? It means the SLIM project will reach out to you about new updates and best practices and offer automated pull-requests for select best practices to be sent to your project's repositories (at no cost!). We welcome new project members who are keen on improving software lifecycle processes within their projects.

    For instance:

    • See our current community members in our About page here.
    • See an example of automated pull requests in-action for our community member repos here.

    Here's how you can tell us you're interested in joining:

    1. Publicly: Start a Discussion: Head over to our discussion forum and file a new thread expressing your interest in joining SLIM. This is a great way to introduce your project and outline how you think SLIM could benefit you.

    2. Privately: Contact Us: You can directly contact @riverma or the @slim-steering group on GitHub to express your desire to join. We'll have a chat, and try to identify which repositories in your project make sense for best practice infusion as well as identify a point-of-contact.

    Contribute to Our Guides​

    We'd be delighted to see your contribution! Please see our Contributing Guide on details for how to contribute. We accept many non-code contributions as well, so feel free to think creatively.

    Spread the Word​

    The more people & projects using, contributing, and maintaining SLIM, the more robust and long-term this effort will last.

    You can help by:

    Socializing on GitHub​

    ⭐ Star our Repo

    👀 Watch our Repo

    😀 Discuss our Repo

    Website​

    Share our website (https://nasa-ammos.github.io/slim) with your friends and colleagues

    - + \ No newline at end of file diff --git a/index.html b/index.html index 49077f3d6..1a4559819 100644 --- a/index.html +++ b/index.html @@ -5,13 +5,13 @@ Home | SLIM - +

    A community-resource for exchanging and implementing best practices in software lifecycle improvements.

    See our Best Practice Guides
    Submit a Best Practice Guide

    Our Scope

    We focus on best practices related to software project governance, documentation, and development life-cycles.

    Community Based

    We solicit improvement ideas and solutions from our community deliver best practices back to our members. See our community planning board.

    Open Source

    We develop best practices through standards-as-code. We iteratively improve our recommendations through the open source tickets and pull requests.

    - + \ No newline at end of file diff --git a/markdown-page/index.html b/markdown-page/index.html index a205392eb..d68a48498 100644 --- a/markdown-page/index.html +++ b/markdown-page/index.html @@ -5,13 +5,13 @@ Markdown page example | SLIM - +

    Markdown page example

    You don't need React to write simple standalone pages.

    - + \ No newline at end of file