|
1 |
| -# Contributing to Vortex on Github |
| 1 | +# Contributing to Vortex |
2 | 2 |
|
3 |
| -## Github Details |
4 |
| -- There are two main repos, `vortex` (public, this one) and `vortex-dev` (private) |
5 |
| -- todo: Most current development is on `vortex` |
6 |
| -- If you have a legacy version of `vortex`, you can use the releases branch or tags to access the repo at that point in time |
| 3 | +## Github |
| 4 | +Vortex uses Github to host its git repositories. |
| 5 | +There are a lot of ways to use the features on Github for collaboration. |
| 6 | +Therefore, this documentation details the standard procedure for contributing to Vortex. |
| 7 | +Development of Vortex is consolidated to this repo, `vortex` and any associated forks. |
| 8 | +Previously, there was active work done on a private repo named `vortex-dev`. |
| 9 | +`vortex-dev` has officially been deprecated and fully merged into this public repo, `vortex`. |
| 10 | +If you are returning to this project and have legacy versions of Vortex, you can use the releases branches to access older versions. |
7 | 11 |
|
8 | 12 | ## Contribution Process
|
9 |
| -- You should create a new branch from develop that is clearly named with the feature that you want to add |
10 |
| -- Avoid pushing directly to the `master` branch instead you will need to make a Pull Request (PR) |
11 |
| -- There should be protections in place that prevent pushing directly to the main branch, but don't rely on it |
12 |
| -- When you make a PR it will be tested against the continuous integration (ci) pipeline (see `continuous_integration.md`) |
13 |
| -- It is not sufficient to just write some tests, they need to be incorporated into the ci pipeline to make sure they are run |
14 |
| -- During a PR, you might receive feedback regarding your changes and you might need to make further commits to your branch |
| 13 | +In an effort to keep `vortex` organized, permissions to directly create branches and push code has been limited to admins. |
| 14 | +However, contributions are strongly encouraged and keep the project moving forward! Here is the procedure for contributing: |
15 | 15 |
|
| 16 | +1. Create a fork of `vortex` |
| 17 | +2. In your fork, create a branch from `master` that briefly explains the work you are adding (ie: `develop-documentation`) |
| 18 | +3. Make your changes on the new branch in your fork. You may create as many commits as you need, which might be common if you are making multiple iterations |
| 19 | +4. Since you are the owner of your fork, you have full permissions to push commits to your fork |
| 20 | +4. When you are satisfied with the changes on your fork, you can open a PR from your fork using the online interface |
| 21 | +5. If you recently made a push, you will get automatically get a prompt on Github online to create a PR, which you can press |
| 22 | +6. Otherwise, you can go to your fork on Github online and manually create a PR (todo) |
| 23 | +(todo): how to name and format your PR, what information you should add to the PR, does not need to be too strict if you are attending the weekly meetings* |
| 24 | +7. Github uses the following semantics: `base repository` gets the changes from your `head repository` |
| 25 | +8. Therefore, you should set the `base repository` to `vortexgpgpu/vortex` and the `base` branch to `master` since the master branch is protected by reviewed PRs. |
| 26 | +9. And you should assign the `head repository` to `<your-github-username>/vortex` (which represents your fork of vortex) and the `base` branch to the one created in step 2 |
| 27 | +10. Now that your intended PR has been specified, you should review the status. Check for merge conflicts, if all your commits are present, and all the modified files make sense |
| 28 | +11. You can still make a PR if there are issues in step 10, just make sure the structure is correct according to steps 7-9 |
| 29 | +12. Once the PR is made, the CI pipeline will run automatically, testing your changes |
| 30 | +13. Remember, a PR is flexible if you need to make changes to the code you can go back to your branch of the fork to commit and push any updates |
| 31 | +14. As long as the `head repository`'s `base` branch is the one you edited, the PR will automatically get the most recent changes |
| 32 | +15. When all merge conflicts are resolved, changes are made, and tests pass you can have an admin merge your PR |
16 | 33 |
|
17 |
| -## Creating and Adding Tests |
18 |
| -see `testing.md` |
| 34 | +## What Makes a Good Contribution? |
| 35 | +- If you are contributing code changes, then review [testing.md](./testing.md) to ensure your tests are integrated into the [CI pipeline](continuous_integration.md) |
| 36 | +- During a PR, you should consider the advice you are provided by your reviewers. Remember you keep adding commits to an open PR! |
| 37 | +- If your change aims to fix an issue opened on Github, please tag that issue in the PR itself |
0 commit comments