Refactor the Developer sections

* Add the Thanks page in.
* Split out the developer guides for documentation and appliction to make them more distinct.
* Simplify some of the Git info.
* Add more cross links to appropriate sections.

assets/scss/_styles_project.scss

@@ -1,4 +1,4 @@
 .td-page-meta--child { display: none !important; }
-.td-page-meta--edit { display: none !important; }
+//.td-page-meta--edit { display: none !important; }
 
 

content/en/developer/_index.md

@@ -5,71 +5,24 @@ aliases: [/docs/contribution-guidelines]
 menu:
   main:
     weight: 100
-description: How to contribute to Vixen
+description: How to contribute to the Vixen project.
 cascade:
   - type: docs
 ---
 
-Vixen is an open source project and we love getting patches and contributions to make Vixen and its docs even better.
-
-## Contributing to Vixen
-
-The Vixen code itself lives in <https://github.com/vixenlights/vixen>.
+Vixen is an open source project and we love getting patches and contributions to make Vixen and its docs even better. Even people who are willing to test and provide feedback are a welcome benefit to the project.
 
 ### Contributor License Agreement
 
 Contributions to this project become part of the project and are subject to the open source licensing.
 
-### Code reviews
-
-All submissions, including submissions by project members, require review. We
-use GitHub pull requests for this purpose. Consult
-[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
-information on using pull requests.
-
-### Community guidelines
-
-This project follows
-[Google's Open Source Community Guidelines](https://opensource.google.com/conduct/).
-
-### Creating issues
-
-Alternatively, if there's something you'd like to see in Vixen (or if you've found something that isn't working the way you'd expect), but you're not sure how to fix it yourself, please create an [issue](https://bugs.vixenlights.com).
-
-## Contributing to these docs
-
-This user guide is a Docsy site that uses the Hugo static site generator. We welcome updates to the docs!
-
-### Updating a single page
-
-If you've just spotted something you'd like to change while using the docs, Docsy has a shortcut for you:
-
-1. Click **Edit this page** in the top right hand corner of the page.
-1. If you don't already have an up to date fork of the project repo, you are prompted to get one - click **Fork this repository and propose changes** or **Update your Fork** to get an up to date version of the project to edit. The appropriate page in your fork is displayed in edit mode.
-
-### Previewing your changes locally
-
-If you want to run your own local Hugo server to preview your changes as you work:
-
-1. Follow the instructions in [Getting started](/docs/getting-started) to install Hugo and any other tools you need.
-1. Fork the [Vixen Website](https://github.com/vixenlights/web.vixenlights.com) repo into your own project, then create a local copy using `git clone`:
-
-    ```sh
-    git clone git@github.com:VixenLights/web.vixenlights.com.git
-    ```
-
-1. Change to the `web.vixenlights.com` directory and run the following Hugo command to build the site and start the Hugo server.
-
-    ```sh
-    cd web.vixenlights.com
-    hugo server
-    ```
+### Code Reviews
 
-    By default your site will be available at http://localhost:1313/. Now that you're serving your site locally, Hugo will watch for changes to the content and automatically refresh your site.
+All submissions, including submissions by project members, require review. We use GitHub pull requests and review process for this purpose. Consult [GitHub Help][1] for more information on using pull requests.
 
-2. Continue with the usual GitHub workflow to edit files, commit them, push the
-  changes up to your fork, and create a pull request.
+### Community Guidelines
 
-### Creating an issue
+This project follows [Google's Open Source Community Guidelines][2].
 
-If there's something you'd like to see in the docs, but you're not sure how to fix it yourself, please create an issue in [this repository](https://github.com/vixenlights/we/vixenlights.com). You can also create an issue about a specific page by clicking the **Create Documentation Issue** link in the top right hand corner of the page.
+[1]: https://help.github.com/articles/about-pull-requests/
+[2]: https://opensource.google.com/conduct/

content/en/developer/contribute-docs.md

@@ -0,0 +1,54 @@
+---
+title: Contribute to Documentation
+author: Vixem Team
+weight: 20
+description: How to contribute to the Vixen documentation.
+---
+
+### Overview
+
+Vixen is an open source project and we love getting patches and contributions to make Vixen and its docs even better.
+
+This user guide is a Docsy themed site that uses the Hugo static site generator. The code for the website is hosted on [Github][5].
+
+We welcome updates to the docs!
+
+### Updating a single page
+
+If you've just spotted something you'd like to change while using the docs, Docsy has a shortcut for you:
+
+1. Click **Edit this page** in the top right hand corner of the page.
+2. If you don't already have an up to date fork of the project repo, you are prompted to get one - click **Fork this repository and propose changes** or **Update your Fork** to get an up to date version of the project to edit. The appropriate page in your fork is displayed in edit mode.
+3. Submit a pull request to the develop branch in the repository and it will be reviewed for inclusion.
+
+### Previewing your changes locally
+
+If you want to run your own local Hugo server to preview your changes as you work:
+
+1. Follow the instructions in [Docsy Getting Started][6] to install Hugo and any other tools you need.
+2. Fork the [Vixen Website][5] repo into your own project, then create a local copy using `git clone`:
+
+    ```sh
+    git clone git@github.com:VixenLights/web.vixenlights.com.git
+    ```
+
+3. Change to the `web.vixenlights.com` directory and run the following Hugo command to build the site and start the Hugo server.
+
+    ```sh
+    cd web.vixenlights.com
+    npm install
+    hugo server
+    ```
+
+    By default your site will be available at http://localhost:1313/. Now that you're serving your site locally, Hugo will watch for changes to the content and automatically refresh your site.
+
+4. Continue with the usual GitHub workflow to edit files, commit them, push the
+  changes up to your fork, and create a pull request.
+
+### Creating an issue
+
+If there's something you'd like to see in the docs, but you're not sure how to fix it yourself, please create an [Issue][7] on Github for this repository. You can also create an issue about a specific page by clicking the **Create Documentation Issue** link in the top right hand corner of the page.
+
+[5]: https://github.com/vixenlights/web.vixenlights.com
+[6]: https://www.docsy.dev/docs/get-started/
+[7]: https://github.com/VixenLights/web.vixenlights.com/issues/new

content/en/developer/contribute-vixen.md

@@ -0,0 +1,49 @@
+---
+title: Contribute to Vixen
+author: Vixen Team
+weight: 10
+description: How to contribute to the Vixen application.
+---
+
+### Overview
+
+Vixen is an open source project and we love getting patches and contributions to make Vixen and its docs even better.
+
+The Vixen application code is hosted on [Github][1]. You can clone the repository to get a copy of the source code to work with.
+
+### Development Libraries
+
+There are a few libraries and tools that you need to have installed in order to get the application to build. Depending on how much you develop in other projects you may have these already installed.
+
+* Windows 10 or higher.
+* Visual Studio 2022
+* Git
+* Microsoft .NET Framework 4.8
+* Microsoft Visual C++ 2019 x86 Redistributable
+* Microsoft Visual C++ 2019 x64 Redistributable
+
+The current build target is .NET 4.8 and Visual C++ 2019, but we are actively migrating to .NET 6 and will be using Visual C++ 2022.
+
+See this [article][4] on Visual Studio settings you should use.
+
+See this [article][5] for information on Git.
+
+### Workflow
+
+When contributing to Vixen, we like to track all issues and improvements in our [JIRA bug tracker][2]. Work should have an associated issue created for it. It is a good idea to have an account in JIRA so you can work with the issues. See [Lifecycle][7] of an issue for guidance on how we manage issues.
+
+You should strive to name your branches with the ticket number. i.e. VIX-2345. Any commits to the branch should start with the ticket number as well and then follow Git guidlines for commit messages. All submissions are done through pull requests on Github. See [Branching Practices][6] for guidance on this topic.
+
+More information on how we manage JIRA can be found [here][3].
+
+### Creating Issues
+
+Alternatively, if there's something you'd like to see in Vixen (or if you've found something that isn't working the way you'd expect), but you're not sure how to fix it yourself, please create an [Issue][2] in our JIRA board for anything in the application.
+
+[1]: https://github.com/vixenlights/vixen
+[2]: https://bugs.vixenlights.com
+[3]: {{< ref issue-management >}}
+[4]: {{< ref visual-studio >}}
+[5]: {{< ref git-information >}}
+[6]: {{< ref "git-information#branching-practices" >}}
+[7]: {{< ref "issue-management#lifecycle-of-a-ticket" >}}

content/en/developer/git-information.md

@@ -1,14 +1,17 @@
 ---
 title: Git Information
 author: Vixen Team
-weight: 10
+weight: 30
+description: This section covers the source code tooling.
 ---
 
-### Tools
+### Overview
+
+The Vixen project uses [Git][2] for our source code management. [Github][1] is our collaboration tool.
 
-The Vixen project uses Git for our source code management. Github is our collaboration tool.
+### Tools
 
-There are many tools to work with a Git based project. Yo uwill at minimum need the Git libraries installed.
+There are many tools to work with a Git based project. You will at minimum need the Git libraries installed.
 
 [Git SCM][2]
 
@@ -18,26 +21,23 @@ TortoiseGit is a UI tool that can make it easier for some to use Git. This allow
 
 [TortoiseGit Manuals][4]
 
-Visual studio also has support within it for Git and there are also many other plugins that provide integrations as well. You are welcome to use whatever you like and are comfortable with.
+Visual Studio also has support within it for Git and there are also many other plugins that provide integrations as well. You are welcome to use whatever you like and are comfortable with.
 
 ### Branching Practices
 
 The general idea is that the master branch is, tracking the development for the next version. It's stuff that's going into the product, and will be included in the next version unless something is found to have an issue in testing.
 
-(a) You should not commit stuff to your master branch. You should keep it up to date with the real master and make branches off of it for any new work your do. When you first decide to do work on Vixen, you would fork the master at [Vixen Source][5] to your own copy of it. You should be able to build and get a running version of Vixen from that is current. Then you can easily make branches from that to work on. Tools like TortoiseGit make it easier to manage changing branches and committing work.
-
-As a maintainer, even I do not commit any work directly to the master branch. All commits on the master branch are actually merges of work from other branches.
-
-(b) All work should be done based off of a ticket in the [JIRA Bug Tracker][6]. When you take on work for a particular item, you should create a branch off of the current master and name it the same as the ticket you are working on. I.E. VIX-1024. This provides a clear reference back to the description of the problem or feature. In addition to this, each commit should start with the ticket number as well. This will allow those commits to be linked to the ticket when they are eventually merged into the master. You should ensure you have an open ticket to begin work so that this tracking can occur. Once the ticket it open and assigend to you, you can move it to start work. This will indicate to other developers you are working on the ticket. Once you complete the work, you can submit a pull request to the Vixen repository where it can be reviewed. The JIRA ticket will reflect that a PR has been submitted. Once reviewed and approved, the ticket will transition states based on it being merged, built and closed automatically. You will not need to transition JIRA beyond the initial start work in normal circumstances. JIRA will track the changes when they are committed to the main repository. The build that corresponds to the change will be marked in the JIRA ticket along with links to the commits involved.
+* You should not commit code to your master branch. You should keep it up to date with the real master and make branches off of it for any new work you do. When you first decide to do work on Vixen, you should fork the master at [Github][5] to your own copy of it. You should be able to build and get a running version of Vixen from that is current. Then you can easily make branches from that to work on.
 
-(c) If the item you are working on will span some time and the current master gets updated with new features from other developers, you can keep your branch in sync by rebasing your changes onto the current version of the master. You would sync your copy of the master from the master branch tree first. Then you can rebase your branch onto that. This will replay your commits onto the tail of the master giving you a up to date branch. Try to avoid merging the changes in the master into your own branch as this creates a messy commit history. More information on how to rebase can be found [here][7].
+* All work should be done based off of a ticket in the [Bug Tracker][6]. When you take on work for a particular item, you should create a branch off of the current master and name it the same as the ticket you are working on. I.E. VIX-1024. This provides a clear reference back to the description of the problem or feature. In addition to this, each commit should start with the ticket number. This will allow those commits to be linked to the ticket when they are eventually merged into the master. You should ensure you have an open ticket to begin work so that this tracking can occur. Once the ticket it open and assigend to you, you can move it to start work. This will indicate to other developers you are working on the ticket. Once you complete the work, you can submit a pull request to the Vixen repository where it can be reviewed. The JIRA ticket will reflect that a pull request has been submitted. Once reviewed and approved, the ticket will transition states based on it being merged, built and closed automatically. You will not need to transition JIRA beyond the initial start work in normal circumstances. The build that corresponds to the change will be marked in the JIRA ticket along with links to the commits involved. The maintainer will close the ticket when it is merged.
 
-(d) If you are collaborating with another developer, then you may want to share work on a branch. Here you can both work on the same branch shared publicly or you can merge changes between yourself. This is not very common in our development structure so ask questions if it comes up and we can help guide you through it.
+* If the item you are working on will span some time and the current master gets updated with new features from other developers, you can keep your branch in sync by rebasing your changes onto the current version of the master. You would do a git pull to your master from the master branch tree first. Then you can rebase your branch onto that. This will replay your commits onto the tail of the master giving you a up to date branch. Try to avoid merging the changes in the master into your own branch as this creates a messy commit history. More information on how to rebase can be found [here][7].
 
-(e) If you want to have a play with someone else's branch (to test, or add features to it), as long as they have pushed a copy of it out to their public repository, then you can always make your own branch at that point, and go from there. For example, Jeff might take a look at Jon's _VersionControl_ branch, and make a new one for himself, called _copy-branch_ or something. He can do some more work to do with the version control, maybe updating stuff, adding a new feature, etc. Then, if Jon likes it, he can merge from Jeff's VC branch back into his own VC branch. (since it's all separate to 'master', he can do what he likes with it.) Once all the work is done between the two developers, the version with all the changes compiled together can be merged into the master.
+* If you are collaborating with another developer, then you may want to share work on a branch. Here you can both work on the same branch shared publicly or you can merge changes between yourself. This is not very common in our development structure, so ask questions if it comes up and we can help guide you through it.
 
-(f) When work is complete on a branch, That branch should be pushed to your public repository and a pull request against the Vixen master created to indicate it is ready to be reviewed and merged.
+* Larger bodies of work will be conducted on a feature branch in the repository. Here something like an Epic can we worked on by multiple developers, or broken up into multiple parts and that can be assembled on the feature branch and then a singular pull request can merge the entirety of that back to master. 
 
+[1]: https://github.com
 [2]: https://git-scm.com
 [3]: https://tortoisegit.org
 [4]: https://tortoisegit.org/docs/