Add CONTRIBUTING and SUPPORT files

Author: kmurray

CONTRIBUTING.md

@@ -0,0 +1,163 @@
+# VTR Contribution Guidelines
+
+Thanks for considering contributing to VTR!
+Here are some helpful guidelines to follow.
+
+## Common Scenarios
+
+### I have a question
+If you have questions about VTR take a look at our [Support Resources](SUPPORT.md).
+
+If the answer to your question wasn't in the documentation (and you think it should have been), consider [enhancing the documentation](#enhancing-docs).
+That way someone (perhaps your future self!) will be able to quickly find the answer in the future.
+
+
+### I found a bug!
+While we strive to make VTR reliable and robust, bugs are inevitable in large-scale software projects.
+
+Please file a [detailed bug report](#filling-bugs). 
+This ensures we know about the problem and can work towards fixing it.
+
+
+### It would be great if VTR supported ...
+VTR has many features and is highly flexible.
+Make sure you've checkout out all our [Support Resources](SUPPORT.md) to see if VTR already supports what you want.
+
+If VTR does not support your use case, consider [filling an enhancement](#filling-enhacements).
+
+### I have a bug-fix/feature I'd like to include in VTR
+Great! Submitting bug-fixes and features is a great way to improve VTR.
+See the guidlines for [submitting code](#submitting-code).
+
+## The Details
+
+### [Enhancing Documentation](#enhancing-docs)
+Enhancing documentation is a great way to start contributing to VTR.
+
+You can edit the [documentation](https://docs.verilogtorouting.org) directly by clicking the `Edit on GitHub` link of the relevant page, or by editing the re-structured text (`.rst`) files under the `doc/src` folder.
+
+Generally it is best to make small incremental changes.
+If you are considering larger changes its best to discuss them first (e.g. file a [bug](#filling-bugs) or [enhancement](#filling-enhancements)).
+
+Once you've made your enhancements [open a pull request](#pull-requests) to get your changes considered for inclusion in the documentation.
+
+
+### [Filling Bug Reports](#filling-bugs)
+First, search for [existing issues](https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues) to see if the bug has already been reported.
+
+If no bug exists you will need to collect key pieces of information.
+This information helps us to quickly reproduce (and hopefully fix) the issue:
+
+* What behaviour you expect
+
+    How you think VTR should be working.
+
+* What behaviour you are seeing
+
+    What VTR actually does on your system.
+
+* Detailed steps to re-produce the bug
+
+    *This is key to getting your bug fixed.*
+
+    Provided *detailed steps* to reproduce the bug, including the exact commands to reproduce the bug.
+    Attach all relevant files (e.g. FPGA architecture files, benchmark circuits, log files). 
+
+    If we can't re-produce the issue it is very difficult to fix.
+
+* Context about what you are trying to achieve
+
+    Sometimes VTR does things in a different way than you expect.
+    Telling us what you are trying to accomplish helps us to come up with better real-world solutions.
+
+* Details about your environment
+
+    Tell us what version of VTR you are using (e.g. the output of `vpr --version`), which Operating System and compiler you are using, or any other relevant information about where or how you are building/running VTR.
+
+Once you've gathered all the information [open an Issue](https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/new) on our issue tracker.
+
+If you know how to fix the issue, or already have it coded-up, please also consider [submitting the fix](#submitting-code).
+This is likely the fastest way to get bugs fixed!
+
+### [Filling Enhancement Requests](#filling-enhancements)
+First, search [existing issues](https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues) to see if your enhancement request overlaps with an existing Issue.
+
+If not feature request exists you will need to describe your enhancement:
+
+* New behaviour
+
+    How your proposed enhancement will work (from a user's perspective).
+
+* Contrast with current behaviour
+ 
+    How will your enhancement differ from the current behaviour (from a user's perspective).
+
+* Potential Implementation
+
+    Describe (if you have some idea) how the proposed enhancement would be implemented.
+
+* Context
+
+    What is the broader goal you are trying to accomplish? How does this enhancement help?
+    This allows us to understand why this enhancement is beneficial, and come up with the best real-world solution.
+
+**VTR developers have limited time and resources, and will not be able to address all feature requests.**
+Typically, simple enhancements, and those which are broadly useful to a wide group of users get higher priority.
+
+Features which are not generally useful, or useful to only a small group of users will tend to get lower priority.
+(Of course [coding the enhancement yourself](submitting-code) is an easy way to bypass this challenge).
+
+Once you've gathered all the information [open an Issue](https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/new) on our issue tracker.
+
+### [Submitting Code to VTR](#submitting-code)
+VTR welcomes external contributions.
+
+In general changes that are narrowly focused (e.g. small bug fixes) are easier to review and include in the code base.
+
+Large changes, such as substantial new features or significant code-refactoring are more challenging to review.
+It is probably best to file an [enhancement](#filling-enhancements) first to discuss your approach.
+
+Additionally, new features which are generally useful are much easier to justify adding to the code base, whereas features useful in only a few specialized cases are more difficult to justify.
+
+### [Making Pull Requests](#pull-requests)
+It is assumed that by opening a pull request to VTR you have permission to do so, and the changes are under the relevant [License](LICENSE.md).
+
+Each pull request should describe it's motivation and context (linking to a relevant Issue for non-trivial changes).
+
+It should also describe:
+
+* The type of change (e.g. bug-fix, feature)
+
+* How it has been tested
+
+* What tests have been added
+
+    All new features must have tests added which exercise the new features.
+    This ensures any future changes which break your feature will be detected.
+    It is also best to add tests when fixing bugs, for the same reason
+
+    If you aren't sure what tests are needed, or how they should be added ask a developer.
+
+* How the feature has been documented
+
+    Any new user-facing features should be documented in the public documentation, which is in `.rst` format under `doc/src`, and served at https://docs.verilogtorouting.org
+
+
+**Tips for Pull Requests**
+The following are general tips for making your pull requests easy to review (and hence more likely to be merged):
+
+* Keep changes small
+
+    Large change sets are difficult and time-consuming to review.
+    If a change set is becoming too large, consider splitting it into smaller pieces; you'll probably want to file an issue to discuss things first.
+
+* Do one thing only
+
+    All the changes and commits in your pull request should be relevant to the bug/feature it addresses.
+    There should be no unrelated changes (e.g. adding IDE files, re-formatting unchanged code).
+
+    Unrelated changes make it difficult to accept a pull request, since it does more than what the pull request described.
+
+* Match existing code style
+    When modifying existing code, try match the existing coding style.
+    This helps to keep the code consistent and reduces noise in the pull request by avoiding re-formatting changes.

SUPPORT.md

@@ -0,0 +1,18 @@
+VTR Support Resources
+=====================
+For support using VPR please use these resources:
+
+1. Check the VTR Documentation: https://docs.verilogtorouting.org
+
+    The VTR documentation includes:
+      * Overviews of what VTR is, and how the flow fits together
+      * Tutorials on using VTR
+      * Detailed descriptions of tools and their command-line options
+      * Descriptions of the file-formats used by VTR
+
+2. Contact the VTR users mailing list: [email protected]
+
+    The mailing list includes developers and users of VTR.
+    If you have a specific usage case not covered by the documentation, someone on the mailing list may be able to help.
+
+3. If you've found a bug or have an idea for an enhancement consider filing an issue. See [here](CONTRIBUTING.md) for more details.