update custom issue template backend tickets

.github/custom-issue-template/backend-kit/0. Generate project and establish integration point.md

@@ -2,6 +2,14 @@
 
 To make tasks parallelizable, we should create kits via integration branches to make PRs smaller and easier to read while not breaking the upstream build. Integration branches may be cleaner and easier to implement in isolation as kits are isolated to their own directory anyway.
 
+# Kit Naming Guidelines
+
+Kits are named to reflect the key technologies used to comprise the kit. For backend kits, this is defined as: <framework>-<middleware>-<store>. This is to help with uniqueness in naming different kits.
+
+- Framework: This should be the main application framework used to define the backend service. Some examples for this value are: ExpressJS, NestJS, Serverless Framework, etc. Ideally, this is technology responsible for running a server when the “dev” script command is run that starts a local server.
+- Special tech: This is a piece of technology that helps distinguish this kit from other backend kits using the same key framework and store. If using GraphQL as an API, specifying which middleware is a great option, e.g. Apollo, Relay, etc. If using a different RPC, defining the implementation is ideal. If using standard REST, it is okay to omit this feature of the name.
+- Store: This should represent the ORM or Data Source selected for the kit. If using a database without an ORM, the database name is acceptable. If using an ORM (TypeORM, Prisma, Sequelize, etc.), that should be used here instead. If there is no ORM or database and a CMS or 3rd party API is used instead, the selected CMS should be used, but if it’s strictly a 3rd party API, use the convention “headless” to describe the kit.
+
 # Acceptance
 
 - [ ] Generate new project in the `starters/` creating a name that includes `<framework>-<special-tech>-<store>` format

.github/custom-issue-template/backend-kit/1. Add linting and prettier configurations.md

@@ -2,6 +2,11 @@
 
 Having code style consistency is important for any project. A standardized set of options should be set that can be overwritten by the implementer at a later date.
 
+- ESLint: Code formatting should be enforced via ESLint rules. Rules should be set to the strictest setting and enforced via CI. The standard rules for a stack should be selected and if there are specialized plugins, those should be utilized and appropriately tuned.
+- Prettier: Prettier should be configured to save on format and align with the established ESLint rules.
+- EditorConfig: Most editors support the EditorConfig syntax. Setting the project’s editor settings to align with the selected ESLint & Prettier rules should be established for code conformity and to improve the developer experience.
+- Tabs: It has been proven that tabs are better than spaces for accessibility purposes. As such, all tooling should be configured to use tabs when possible. YAML is a known exception.
+
 # Acceptance
 
 - [ ] Establish eslint/tslint rules and configuration

.github/custom-issue-template/backend-kit/4. Final checks.md

@@ -0,0 +1,10 @@
+# Background
+
+There are a few final details that need to be in place for each backend kit.
+
+# Acceptance
+
+- [ ] Typescript - kit uses the latest version of TypeScript
+- [ ] .nvmrc - A .nvmrc file should be provided with the kit to specify the node version used to ensure users are using the targeted node version
+- [ ] No lock files - the lockfile from the project should be excluded to allow users to utilize their package manager of choice
+- [ ] Pinned dependency versions - because the lockfile is excluded, kits should pin their dependency version numbers to a fixed value

.github/custom-issue-template/frontend-kit/3. Update the readme.md

@@ -1,82 +1,87 @@
 # Background
+
 The kit should include a thorough README with all architectural decisions the user should be aware of when utilizing it. It shouldn't rewrite docs for existing libraries but any key decisions should be documented. This is what will be visible to users on the website when they look at the details page.
 
 # Acceptance
+
 - [ ] Update the below template with relevant information for users who want to utilize this kit with appropriate instructions.
 
 # Template
 
 > # <kit name> starter kit
-> 
+>
 > This starter kit features <technology list>.
-> 
+>
 > ## Table of Contents
-> 
+>
 > - [Overview](#overview)
 >   - [Tech Stack](#tech-stack)
 >   - [Included Tooling](#included-tooling)
->   - [Example Components](#example-components)
+
+    - [Architectural Decisions](#architectural-decisions)
+
+> - [Example Components](#example-components)
 > - [Installation](#installation)
 >   - [CLI](#cli)
 >   - [Manual](#manual)
 > - [Commands](#commands)
 > - [Demo Implementation](#demo-implementation)
-> 
+>
 > ## Overview
-> 
+>
 > ### Tech Stack
-> 
+>
 > - List of technologies used with links to relevant doc pages
-> 
+>
 > ### Included Tooling
-> 
+>
 > - List of tooling used, e.g. jest, Storybook, ESLint, Prettier, etc., with their relevant doc pages linked
 > - [Jest](https://jestjs.io/) - Test runner
 > - [TypeScript](https://www.typescriptlang.org/) - Type checking
 > - [Storybook](https://storybook.js.org/) - Component library
 > - [ESLint](https://eslint.org/) - Code linting
 > - [Prettier](https://prettier.io/) - Code formatting
-> 
+>
 > ### Architectural Decisions
-> 
+>
 > List all important architectural decisions here and patterns users should be aware of.
-> 
+>
 > ### Example Components
-> 
-> In this `starters/<kit path>/src` directory you will find the  <Component Names> directories.
-> 
+>
+> In this `starters/<kit path>/src` directory you will find the <Component Names> directories.
+>
 > <explain each components structure with relation to the architectural decisions outlined>
-> 
+>
 > ## Installation
-> 
+>
 > ### CLI (Recommended)
-> 
+>
 > ```bash
 > npx create-starter-dev
 > ```
-> 
+>
 > - Follow the prompts to select the <kit name> starter kit and name your new project.
 > - `cd` into your project directory and run `npm install`.
 > - Run `npm run dev` to start the development server.
 > - Open your browser to `http://localhost:3000` to see the included example code running.
-> 
+>
 > ### Manual
-> 
+>
 > ```bash
 > git clone https://github.com/thisdot/starter.dev.git
 > ```
-> 
+>
 > - Copy and rename the `starters/<kit name>` directory to the name of your new project.
 > - `cd` into your project directory and run `npm install`.
 > - Run `npm run dev` to start the development server.
 > - Open your browser to `http://localhost:3000` to see the included example code running.
-> 
+>
 > ## Commands
-> 
+>
 > - List of helpful package.json scripts and their purpose
-> 
+>
 > ## Demo Implementation
-> 
+>
 > [Repository](https://github.com/thisdot/starter.dev-showcases/tree/main/<kit name>)
-> 
-> The demo application re-implements some of GitHub's pages and functionality. It uses the OAuth credentials in GitHub to authenticate users with their GitHub accounts and uses RxJS to fetch data from the GitHub API. Check out the link above to learn more or check out the demo!
+>
+> The demo application re-implements some of GitHub's pages and functionality. It uses the OAuth credentials in GitHub to authenticate users with their GitHub accounts and uses RxJS to fetch data from the GitHub API. Check out the link above to learn more or check out the demo!