Add templates for initial project documentation.

These templates are meant to be used as a starting point for creating project
documentation. Likely for smaller projects following standard coding practices
their content can be reduced. The more experience the project has with working
with contributors the more helpful those documents will get.

Author: MaineC

project-setup/templates/CONTRIBUTING-template.md

@@ -0,0 +1,40 @@
+# Contributing to ____
+
+## Types of contributions
+
+Provide information on what kinds of contributions your project is looking for
+here. For example these can be bug reports, help with answering user questions,
+improving documentation, fixes to bugs, as well as new feature implementations.
+
+## Bug reports
+
+Add information on how to submit bug reports here. This should include
+hints about which type of information the project will need in order to
+reproduce and fix issues. It can also include information on commonly found
+mis-configurations that look like bugs.
+
+Also include information on what contributors can expect in terms of time to
+first response and process after that.
+
+## Feature requests
+
+Add information on how to submit feature requests here. Also include information
+on what contributors can expect in terms of time to first response and process
+after that.
+
+## Contributing documentation
+
+Include information on any documentation best practices your project follows as
+well as how to build documentation, checks to run and how to submit the changes
+made back to the project.
+
+## Contributing source code
+
+This section should contain information on
+
+- How to access the project source code,
+- General project layout,
+- Any requirements to the development environment,
+- Code formatting guidelines,
+- How to run the test suite.
+

project-setup/templates/README-template.md

@@ -0,0 +1,73 @@
+# Insert the name of your project here
+
+## Mission
+
+This should contain a brief (3-5 sentences) description of the mission of your
+project. The goal is to state what you are planning to work on and help external
+contributors understand roughly which types of features will likely be welcome
+for this project.
+
+See also [mission statement
+chapter](https://producingoss.com/en/producingoss.html#mission-statement) in
+Producing Open Source Software.
+
+## Getting Started
+
+This section should contain brief documentation written for first time users on
+how to get started using the project. Further more detailed documentation can be
+linked to from here.
+
+## Getting involved
+
+This section should include information on how to get in touch with the project:
+Typically this will contain links to archived, searchable and linkable
+communication channels.
+
+## Who we are
+
+This is a good place to give credit to Trusted Committers of the project.
+
+It's also a good place to include information on what being a Trusted Committer
+means for this project - although ideally all projects in an organisation use
+the same definition that is only linked to from here. The reason to keep the
+link here is for colleagues who have no or little experience with working in and
+contributing to InnerSource projects to have a direct link back to company wide
+information from the technological projects they need for their daily work.
+
+### How to become a Trusted Committer
+
+This section should make the process for becoming a Trusted Committer explicit
+if that route is open to contributors.
+
+### How to nominate Trusted Committers
+
+This section serves as a reminder to existing and explanation for new Trusted
+Committers detailing how to add others to the host team. Again ideally this
+information is identical for all projects in the organisation so central
+information can be linked to from here. 
+
+## Contributing
+
+This section should document (or link to documentation) on all things that a
+first time contributor needs to know to get started. Typically not all of the
+topics below will be covered. Focus on what differs in your project from
+standard setup and what previous contributors found hard to understand.
+
+- Finding the source code.
+- Finding a list of issues that your project needs help with - these can be
+  both, technical and non-technical issues. Typically you will keep those in an
+  issue tracker accessible to contributors.
+- Links to further documentation e.g. about the architecture of the project,
+  general coding conventions, testing conventions...
+- For technical contributions: Making changes, building the project and testing
+  your changes.
+- Submitting your changes back to the project.
+
+Ideally you also include information on what the preferred process for changes
+looks like for the project: Should contributors first open an issue and submit a
+proposal, or are they welcome to submit changes right away? What is important to
+you when reviewing contributions?
+
+Over time you will notice that this section grows substantially. In that case
+think about moving the information to separate files, e.g. a CONTRIBUTING.md and
+TESTING.md