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