Added initial guidline docs

BuildTimeLogger/Loggers/InfluxDBLogger.cs

@@ -262,7 +262,7 @@ public sealed class InfluxDBLogger: IBuildLogger
 
 
         /// <summary>
-        /// Private construuctor to confrom to singleton pattern imposed by base class
+        /// Class constructor
         /// </summary>
         public InfluxDBLogger()
         {

CHANGELOG.md

@@ -0,0 +1,9 @@
+# Changelog
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
+
+## 0.5 - 2022-07-08
+### Added
+- Marks the first open source release to github.
+- Core extension functionality working with logging to InfluxDB implemented

CONTRIBUTING.md

@@ -0,0 +1,29 @@
+# How to Contribute
+
+## Git Branching Strategy
+
+This project aims to keep a simple git history by having one long running branch (`main`) where branches are created, rebased onto, and then merged. Releases are simply tagged commits along the main branch.
+
+When creating a branch, prefix the branch with the type of change being made:
+- `feature/<feature-name>` for new features
+- `bugfix/<bugfix-name>` for bux fixes
+
+Prior to merging all branches should be rebased onto `main`, and ideally squashed into a single commit or a set of clear logical commits. After a merge, the branch will be deleted. 
+
+## Creating a Pull Request
+
+- Pull requests should be done against the `main` branch.
+- Pull requests should only have a single commit (with no merge commits) and should be rebased onto the latest commits on `main` when submitted.
+- If adding new major features to the plugin, ensure appropriate tests have been added to the `BuildTimeLoggerTests` project that help verify the feature is working as intended.
+- Provide a clear description of the purpose of your pull request. Is it a big fix, an additional feature? What is the rationale behind the work you have done? If you are planning on adding a large new feature, it is reccommended to open a ticket with the feature idea beforehand to ensure your intentions align with that of the maintence team and ensure your work has the best chance of being merged when done.
+
+## Development Environment
+
+As an extension project for Visual Studio, it is reccommended to use Visual Studio 2019 for any development work. While possible to build the extension without it, it does provide the tooling and testing framework out of the box for developing extensions - in particular, the ability to test the extension in an isolated Debug version of Visual Studio.
+
+As an alternative, building of the extension can also be done using the appropriate Microsoft Build tools. An example of how to do this with a container built with a provided `Dockerfile` can be found in the base `REAMDE` of this repository.
+
+
+## Reporting Issues
+
+Please feel free to post issues in the issues section of the repository. Please follow the template [here](https://gist.github.com/auremoser/72803ba969d0e61ff070) as a guide for how to format your issues.

MAINTAINERS.md

@@ -0,0 +1,35 @@
+# Maintainers
+
+## Git Branching Policy
+
+This project aims to keep a simple git history by having one long running branch (`main`) where branches are created, rebased onto, and then merged. Releases are simply tagged commits along the main branch.
+
+When creating a branch, prefix the branch with the type of change being made:
+- `feature/<feature-name>` for new features
+- `bugfix/<bugfix-name>` for bux fixes
+
+Prior to merging all branches should be rebased onto `main`, and ideally squashed into a single commit or a set of clear logical commits. After a merge, the branch should be deleted. 
+
+When there is a commit suitable for releasing, it should be tagged with the release version. The version released should match the source code in this tagged commit.
+
+
+## Handling a Pull Request
+
+- Assess whether the pull request is inline with the intended purpose of the extension.
+- Ensure pull requests have been rebased onto the `main` branch prior to accepting the merge request.
+
+## Creating a Release
+
+### Prior to Releasing
+
+- Ensure all unit tests are passing. 
+- As of this writing there are no end-to-end tests configured, so it is highly reccommended to run the extension in a test environment with access to logging endpoints (e.g. InfluxDB) and ensure data is being captured and logged as expected.
+
+### Release Process
+
+As of this writing there is no automated release process. As a result, the steps to create a release are as follows:
+
+- Update the extension version in the `source.extension.vsixmanifest` file.
+- Update `CHANGELOG.md` file with the changes made in this release version.
+- Tag the commit 
+- Upload the updated built extension to the Visual Studio marketplace.

README.md

@@ -4,7 +4,7 @@
 
 ## Purpose
 
-This extension is designed to capture information about build times and the log them to an external platform. As of this writing, the only external database supported is InfluxDB, however other logging targets could quite easily be added by creating additional implementations of the `IBuildLogger` interface and modifying the settings to allow selection of the new logging service and any configuration required for accessing the logging database.
+This extension is designed to capture information about build times and log them to an external platform. As of this writing, the only external database supported is InfluxDB, however other logging targets could quite easily be added by creating additional implementations of the `IBuildLogger` interface and modifying the settings to allow selection of the new logging service and any configuration required for accessing the logging database.
 
 ## Extension Structure