Get the template started

.env.example

@@ -0,0 +1,2 @@
+VARIABLE=example-without-spaces
+TEXT_VARIABLE="This is an example of a string with spaces"

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,32 @@
+---
+name: Bug Report
+about: Create a report to help us improve
+title: "[Bug] "
+labels: bug
+assignees: ''
+
+---
+
+## Overview
+
+Give context and what branch or conditions this problem exists under.
+
+### Expected Behavior 
+
+Describe what you expect to happen
+
+
+### Current Behavior
+
+Describe what actually happens
+
+
+### Steps to Reproduce
+
+1. Provide a link to a live example, or an unambiguous set of steps to reproduce this bug
+1. Include code to reproduce this bug, if relevant
+1. It is also helpful to include a screenshot if you can
+
+### Possible Solution:
+
+Not obligatory, but suggest a fix/reason for the bug,

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,26 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: "[Feature Request] "
+labels: ''
+assignees: ''
+
+---
+
+## Overview
+
+_Reminder: please add appropriate label(s) and milestone to your issue._
+
+Describe *why* you would like this feature.
+If your feature is related to a problem, provide a clear and concise description of what the problem is.
+Ex. I'm always frustrated when [...]
+
+
+### Requested Feature
+
+A clear and concise description of what you want to happen.
+
+
+### Additional context
+
+Add any other context or screenshots about the feature request here.

.github/pull_request_template.md

@@ -0,0 +1,23 @@
+## Overview
+
+Provide an overview of the changes to be reviewed, the issue they are trying to solve, and anything to note as the reviewer goes through them.
+
+<!-- ### Self check
+- [ ] Have the guidelines detailed in the contributing.md been followed?
+- [ ] Can someone who is new to the project read the overview and come away with what the problem is and how it's being solved?
+- [ ] Can the code handle exceptions and errors if design by contract is violated?
+- [ ] For changes in the backend, create tests for your contribution. These tests should demonstrate functionality, and tests that fail intentionally should be added. 
+- [ ] Make sure reviewers know to review this by assigning either the team lead or two team members in the 'reviewers' tab in the sidebar or under the PR text depending on your view.
+- [ ] If you are unsure of next steps or if you are missing something, please reach out in the Slack channel. -->
+
+### Does this close any currently open issues?
+
+<!-- Change ### to #[number of issue], e.g. #1 -->
+Closes ###
+
+### Testing Instructions
+
+- Provide instructions to test the changes
+- Bullet lists are helpful
+- [ ] Checkboxes also help for specific tasks
+- The "happy path" is helpful, but knowing how the changes respond to errors is extra helpful

.gitignore

@@ -0,0 +1,2 @@
+# Basics
+.env

README-example.md

@@ -0,0 +1,33 @@
+# PROJECT-NAME
+
+## Overview
+
+A brief description of the project. This should include what problem the project is solving, how it hopes to help, and what tech is involved. Included here are example sections that you should include and you are welcome to add more sections as your project requires.
+
+Any of these sections can be broken out into their own files and linked from these sections if they get too long or unwieldy.
+
+## Setup
+
+A detailed set of instructions to set up the code for the first time.
+
+If CLI commands are involved, they should be included in test blocks.
+
+```sh
+# It is good practice to describe what each line does
+# Especially for bash commands which can be esoteric
+echo "Be helpful to your volunteers"
+```
+
+## Contributing
+
+Include rules and expectations that you want volunteers to follow as they work on the project. This especially includes how you want them to use `git`, like branching conventions, branch names, and merging PRs. Also if you are picky about variable names, file names, etc.
+
+If you have a lot of rules, or feel like this section is getting too long, it can be helpful to include a `CONTRIBUTING.md` file in the root of the project, and to link to it in this section. GitHub recognizes the `CONTRIBUTING.md` filename and will include it when contributors are writing PRs and issues for the first time.
+
+## Testing
+
+Include instructions on how to run your project's tests. Testing is valuable not just to make sure your code is working how you expect it to, but also can be a great way for new contributors to learn what you expect your code to do and can help them acclimate.
+
+## Deployment
+
+Include detailed instructions on how to deploy your code to production. This will probably be more necessary later on in the project, but once you figure it out for the first time, please include it here immediately so you don't have to relearn it the hard way the next time you go to deploy.

README.md

@@ -1,2 +1,48 @@
-# project-template
-A basic repository template with the essentials ready to spin up new projects
+# SJH Project Template
+
+## Overview
+
+A basic repository template with the essentials ready to spin up new projects. This template sets up for GitHub specifically including some conventions for automating processes.
+
+This template does not prescribe any specific technologies. Your project team should determine the appropriate tech to use to solve your specific requirements and should follow the repository conventions for that tech as appropriate.
+
+What is included here is to get some of the more tedious GitHub things out of the way so that you can get started coding as soon as you are ready. This template should set you up for success and help you create a project repository ready for volunteers to jump in.
+
+## Usage
+
+This template is meant to be forked, and then edited to make it ready for your team to use.
+
+### Forking
+
+For project repos hosted in the `socialjusticehackathon` GitHub organization, this step should be done by a Social Justice Hackathon organizer, but just in case (or for them to follow):
+
+On the project template repo page, click the `Fork` button as shown below:
+
+![Screenshot of the project template page with a red circle around the fork button](./assets/fork-image.png)
+
+Then in the next page (shown below), replace `project-template` with a hyphenated name of the project, and a description of the project. We recommend keeping the checkbox for only forking the `main` branch for a cleaner start to the project's `git` files
+
+![Screenshot of the pagfe where you declare the basic info for the project](./assets/fork-info-page.png)
+
+### Renaming Project Name
+
+For now the only PROJECT-NAME in the project that needs to be renamed is in the first header of the [`README-example.md`](./README-example.md) page. That should be changed to the name of your project.
+
+### Adding your own instructions
+
+In the [`README-example.md`](./README-example.md), you will have to fill out your own instructions to setup, develop, and deploy the project. This may not be very fleshed out yet since this is the beginning of the project, but as you build your project, filling out the corresponding sections will make your volunteers' lives easier (as well as your own later!)
+
+### Making it your project
+
+There are a few files here that are just to get new projects set up but aren't needed once the project starts. To remove extraneous files and move the files we want to keep in the project to the right places, we have included these commands to run in your terminal (Windows users may need to follow different steps for WSL or PowerShell):
+
+```sh
+# Remove README
+rm README.md
+
+# Make the example README the new README
+mv README-example.md README.md
+
+# Remove the example photos about forking
+rm -rf assets
+```