|
| 1 | +# Contributing to PlanDev UI |
| 2 | + |
| 3 | +Thanks for taking the time to consider contributing! We very much appreciate your time and effort. This document outlines the ways you can contribute to PlanDev UI and the conventions we follow. |
| 4 | + |
| 5 | +- [Prerequisites](#prerequisites) |
| 6 | +- [Communication Channels](#communication-channels) |
| 7 | +- [Our Development Process](#our-development-process) |
| 8 | +- [Submitting a Pull Request](#submitting-a-pull-request) |
| 9 | +- [Coding Rules](#coding-rules) |
| 10 | +- [Pull Request Title and Labels](#pull-request-title-and-labels) |
| 11 | +- [Ways to Contribute](#ways-to-contribute) |
| 12 | + |
| 13 | +## Prerequisites |
| 14 | + |
| 15 | +### License |
| 16 | + |
| 17 | +Our project's licensing terms are documented in [LICENSE](LICENSE). Please review it before contributing — it impacts how your contributions may be redistributed. |
| 18 | + |
| 19 | +### Code of Conduct |
| 20 | + |
| 21 | +We follow the [Contributor Covenant](CODE_OF_CONDUCT.md). By participating, you agree to its terms. |
| 22 | + |
| 23 | +### Developer Environment |
| 24 | + |
| 25 | +For details on running, building, and testing PlanDev UI locally, see: |
| 26 | + |
| 27 | +- [README.md](README.md) — quick start and project overview |
| 28 | +- [docs/DEVELOPER.md](docs/DEVELOPER.md) — local development setup |
| 29 | +- [docs/ENVIRONMENT.md](docs/ENVIRONMENT.md) — environment variables |
| 30 | +- [docs/TESTING.md](docs/TESTING.md) — running unit and end-to-end tests |
| 31 | + |
| 32 | +At a minimum you'll need: |
| 33 | + |
| 34 | +1. A GitHub account |
| 35 | +2. Git installed locally |
| 36 | +3. Node.js (see `.nvmrc`) and npm |
| 37 | +4. The ability to build and test the project on your local machine |
| 38 | + |
| 39 | +## Communication Channels |
| 40 | + |
| 41 | +Before contributing, it's a good idea to socialize your idea early. Our channels are: |
| 42 | + |
| 43 | +- [Issue tracker](https://github.com/NASA-AMMOS/plandev-ui/issues) — report issues or propose changes |
| 44 | +- [Discussions](https://github.com/NASA-AMMOS/plandev-ui/discussions) — design conversations and show-and-tell |
| 45 | +- [Slack channel][slack] — real-time chat |
| 46 | + |
| 47 | +## Our Development Process |
| 48 | + |
| 49 | +```mermaid |
| 50 | +flowchart TD |
| 51 | + repo_proj[(NASA-AMMOS/plandev-ui)]-->|Fork|repo_fork[(Your Fork)] |
| 52 | + repo_fork-->|Branch off develop|patch(Your Changes) |
| 53 | + patch-->|Submit|pr(Pull Request) |
| 54 | + pr==>|Approved + Squash & Merge|repo_proj |
| 55 | + pr-->|Changes Requested|repo_fork |
| 56 | +``` |
| 57 | + |
| 58 | +We integrate changes through pull requests against the `develop` branch. Forking is preferred over direct branching for external contributors; core team members typically branch directly. |
| 59 | + |
| 60 | +### Find or File an Issue |
| 61 | + |
| 62 | +Make sure people know what you're working on. Check [the issue tracker][github-issues] for a related issue, or file a new one to start the conversation. |
| 63 | + |
| 64 | +### Choose the Right Branch |
| 65 | + |
| 66 | +`develop` is the default branch and the integration target for all new work. Branch off `develop`. |
| 67 | + |
| 68 | +## Submitting a Pull Request |
| 69 | + |
| 70 | +1. Search [GitHub][github-pulls] for an open or closed PR that relates to your submission to avoid duplicating effort. |
| 71 | +2. Confirm an issue describes the problem or feature. Discussing the design up front helps ensure the work will be accepted. |
| 72 | +3. Clone the [NASA-AMMOS/plandev-ui repo][github] (or your fork). |
| 73 | +4. Create a branch off `develop`: |
| 74 | + |
| 75 | + ```shell |
| 76 | + git checkout develop |
| 77 | + git pull origin develop |
| 78 | + git checkout -b my-fix-branch develop |
| 79 | + ``` |
| 80 | + |
| 81 | +5. Make your changes. |
| 82 | +6. Follow our [Coding Rules](#coding-rules). |
| 83 | +7. Commit your changes: |
| 84 | + |
| 85 | + ```shell |
| 86 | + git commit -a |
| 87 | + ``` |
| 88 | + |
| 89 | + The optional `-a` flag will automatically `add` and `rm` edited files. Intra-PR commits get squashed at merge time, so their shape is up to you — what matters is the [PR title and label](#pull-request-title-and-labels). |
| 90 | + |
| 91 | +8. Push your branch: |
| 92 | + |
| 93 | + ```shell |
| 94 | + git push origin my-fix-branch |
| 95 | + ``` |
| 96 | + |
| 97 | +9. Open a pull request against `plandev-ui:develop`. |
| 98 | + |
| 99 | +### Responding to Review |
| 100 | + |
| 101 | +If reviewers request changes: |
| 102 | + |
| 103 | +- Make the updates and follow the [Coding Rules](#coding-rules). |
| 104 | +- [Rebase][rebase] and force-push to update the PR: |
| 105 | + |
| 106 | + ```shell |
| 107 | + git rebase develop -i |
| 108 | + git push -f |
| 109 | + ``` |
| 110 | + |
| 111 | +If your branch falls behind `develop`: |
| 112 | + |
| 113 | +- Rebase locally as above, **or** |
| 114 | +- Use the GitHub UI's "Update branch" dropdown → "Update with rebase". |
| 115 | + |
| 116 | +### Merging |
| 117 | + |
| 118 | +Once approved, prefer **Squash and merge** to keep `develop` history clean. Update the squash commit message body to include only what's relevant. Do **not** modify the PR title at squash time — that breaks our release-notes tracking. |
| 119 | + |
| 120 | +After merge: |
| 121 | + |
| 122 | +```shell |
| 123 | +git push origin --delete my-fix-branch # delete remote branch |
| 124 | +git checkout develop # back to develop |
| 125 | +git pull origin develop # pull the merged change |
| 126 | +git branch -D my-fix-branch # delete local branch |
| 127 | +``` |
| 128 | + |
| 129 | +## Coding Rules |
| 130 | + |
| 131 | +Before opening a PR, run: |
| 132 | + |
| 133 | +1. `npm run format:write` |
| 134 | +2. `npm run lint` |
| 135 | +3. `npm run lint:css` |
| 136 | +4. `npm run check` |
| 137 | +5. Follow the testing procedures in [docs/TESTING.md](docs/TESTING.md) |
| 138 | + |
| 139 | +## Pull Request Title and Labels |
| 140 | + |
| 141 | +PRs are squash-merged, so the **PR title becomes the commit on `develop`**. Use a descriptive sentence — recent examples: |
| 142 | + |
| 143 | +- "Allow sequence name to be chosen during filter application" |
| 144 | +- "Swap table cookie persistence for localStorage" |
| 145 | +- "Fix inconsistent file extension handling in workspaces" |
| 146 | + |
| 147 | +For release-note categorization, apply one of the labels configured in [.github/release.yml](./.github/release.yml): |
| 148 | + |
| 149 | +| Label | Category | |
| 150 | +| ----------------- | ----------------------------- | |
| 151 | +| `breaking change` | Breaking Changes | |
| 152 | +| `feature` | New Features | |
| 153 | +| `fix` | Bug Fixes | |
| 154 | +| `performance` | Performance Improvements | |
| 155 | +| `refactor` | Refactoring | |
| 156 | +| `test` | Testing | |
| 157 | +| `ci` | Continuous Integration | |
| 158 | +| `documentation` | Documentation | |
| 159 | +| `build` | Build System and Dependencies | |
| 160 | +| `style` | Style | |
| 161 | + |
| 162 | +PRs without a matching label fall under "Other Changes". |
| 163 | + |
| 164 | +## Ways to Contribute |
| 165 | + |
| 166 | +### Code |
| 167 | + |
| 168 | +Before writing code, check the [issue tracker][github-issues]: |
| 169 | + |
| 170 | +1. Look for duplicate issues covering your idea — comment there with your thoughts. |
| 171 | +2. If none exist, file a new issue and start a conversation before opening a PR. |
| 172 | + |
| 173 | +When ready to contribute code: |
| 174 | + |
| 175 | +1. Make sure development [prerequisites](#prerequisites) are met. |
| 176 | +2. Follow our [development process](#our-development-process). |
| 177 | +3. Open a PR per [Submitting a Pull Request](#submitting-a-pull-request). |
| 178 | + |
| 179 | +### Documentation |
| 180 | + |
| 181 | +Documentation lives in: |
| 182 | + |
| 183 | +- Top-level: [README.md](README.md), [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md), [CONTRIBUTING.md](CONTRIBUTING.md) |
| 184 | +- [docs/](docs/) — developer docs (deployment, environment, release, testing, developer setup) |
| 185 | +- [PlanDev documentation site](https://nasa-ammos.github.io/plandev-docs/) — user-facing docs |
| 186 | + |
| 187 | +Documentation contributions follow the same [development process](#our-development-process) as code contributions. |
| 188 | + |
| 189 | +### Security Vulnerabilities |
| 190 | + |
| 191 | +Please **do not** file security vulnerabilities to the public issue tracker. Report them privately to [plandev_support@jpl.nasa.gov](mailto:plandev_support@jpl.nasa.gov). |
| 192 | + |
| 193 | +When reporting, please include: |
| 194 | + |
| 195 | +- Severity assessment |
| 196 | +- Any known workarounds |
| 197 | +- Return contact information for follow-up |
| 198 | + |
| 199 | +[github]: https://github.com/NASA-AMMOS/plandev-ui |
| 200 | +[github-issues]: https://github.com/NASA-AMMOS/plandev-ui/issues |
| 201 | +[github-pulls]: https://github.com/NASA-AMMOS/plandev-ui/pulls |
| 202 | +[rebase]: https://dev.to/maxwell_dev/the-git-rebase-introduction-i-wish-id-had |
| 203 | +[slack]: https://app.slack.com/client/T024LMMEZ/C0163E42UBF |
0 commit comments