Update Contribution Guide

[1adamf]

Problem Statement

Update the contribution guide to cover new organisation features

Summary of Issue/Change

After the change to an organisation repo the workflow for contributing should be something like this:

For first time users

• Join Discord etc (can stay the same)
• Fork the repository
• Clone your fork(creates your own copy of the fork on your PC so you can access the files locally and not just on the GitHub)

Now you're ready to work on an issue

For working on an issue:

• Make sure the master branch of your fork is up to date with the master branch of the main repository.
• Create a branch for the issue from the master branch of your fork. If the issue is called "This is an issue" and it's #37 the branch should actually be named "ThisIsAnIssue-#37" since you cannot have spaces in branch names in visual studio
• Create a pull request that compares your branch for that issue to the master branch of the main GitHub. This should mean 1 pull request per issue and yes you should create the pull request at the beginning so we can track what being worked on at any given time in the project boards
• Make your changes following the structure and documentation guide that I've still not got round to making. I'll make something for the front end code style and structure once I've got more of an idea of how we are doing it and for now it's me doing all the OO side of things so again no need for a document. A short sentence to summarise this similar to the current contribution guide would be good
• Commit your changes (I do this for each individual change so roughly when you would save) with a meaning full commit name ("add commentary for constructor" or "create isAtisValid helper function")
• Push your commits to your own fork but on the GitHub server (I tend to do this at the end of each day of working which would be recommended)
• No longer necessary to add changes to changelog initial as I'm shortly going to delete the file when I clean up the repository
• Make sure you test any changes you have made and if necessary add screenshots of the working version to the pull request
• Once you've finished with the issue and the pull request is ready request a review. Best option is probably to request a review from whoever made the issue as they will know what they are expecting.
• At this point the pull request will be reviewed and most likely changes requested(don't worry about this in software development there are almost always changes request on the first review)
• Once it's been reviewed make any changes following the same process as above and then request a review again once it's ready.
• Eventually, once we are happy with the changes the pull request will get the testing label
• At this point we are getting a second person who hasn't worked on the issue to test it. Not 100% how we will do this yet so another note explaining the details haven't been designed yet is needed
• Once we have tested it either changes will be requested from the testing or the changes will be approved
• After they are approved one of the lead developers will look at any merge conflicts and merge the pull request into the master branch and the pull request will be closed

Keep the note at the end about asking questions.

This is just a workflow so try and change the contribution guide to have all these steps in the same order but try and reword it to fit the current style of the contribution guide

Files effected

.github/Contribution Guide.md

[LEWISC44]

So i just add this to the .md file? @1adamf

[1adamf]

No, Basically update the .md guide to follow the workflow there. That's just a rough guide of what order stuff should be done in but if you could turn that into an actual document and try and make it a bit more concise to match the style of the current contribution guide. Also some of these steps are already in the contribution guide so they won't need to be added