zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-05-29 08:50:01 +02:00
Code Issues Projects Releases Packages Wiki Activity

Updating branch naming standards in contributing.md

Browse source
This commit is contained in:
Erin Song 2024-10-04 10:49:27 -07:00
parent 980f997dbc
commit c20f7e6679
No known key found for this signature in database
2 changed files with 13 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

21
CONTRIBUTING.md
View file

@ -14,17 +14,6 @@ There are a handful of things we do not commit to the repository:
For developers, you can auto-deploy your code to your sandbox (if applicable) by naming your branch thusly: jsd/123-feature-description
Where 'jsd' stands for your initials and sandbox environment name (if you were called John Smith Doe), and 123 matches the ticket number if applicable.
## Approvals
When a code change is made that is not user facing, then the following is required:
- a developer approves the PR
When a code change is made that is user facing, beyond content updates, then the following are required:
- a developer approves the PR
- a designer approves the PR or checks off all relevant items in this checklist
Content or document updates require a single person to approve.
## Project Management
We use [Github Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) for project management and tracking.
@ -39,14 +28,6 @@ Every issue in this respository and on the project board should be appropriately
We also have labels for each discipline and for research and project management related tasks. While this repository and project board track development work, we try to document all work related to the project here as well.
## Pull request etiquette
- The submitter is in charge of merging their PRs unless the approver is given explicit permission.
- Do not commit to another person's branch unless given explicit permission.
- Keep pull requests as small as possible. This makes them easier to review and track changes.
- Bias towards approving i.e. "good to merge once X is fixed" rather than blocking until X is fixed, requiring an additional review.
- Write descriptive pull requests. This is not only something that makes it easier to review, but is a great source of documentation.
## Branch Naming
Our branch naming convention is `name/topic-or-feature`, for example: `lmm/add-contributing-doc`.
Our branch naming convention is `name/issue_no-description`, for example: `lmm/0000-add-contributing-doc`.

16
docs/dev-practices/code_review.md
View file

@ -1,7 +1,7 @@
## Code Review
Pull requests should be titled in the format of `#issue_number: Descriptive name ideally matching ticket name - [sandbox]`
Any pull requests including a migration should be suffixed with ` - MIGRATION`
Pull requests including a migration should be suffixed with ` - MIGRATION`
After creating a pull request, pull request submitters should:
- Add at least 2 developers as PR reviewers (only 1 will need to approve).
@ -9,19 +9,27 @@ After creating a pull request, pull request submitters should:
- If any model was updated to modify/add/delete columns, run makemigrations and commit the associated migrations file.
- If any updated dependencies on Pipfile, also update dependencies in requirements.txt.
## Pull request approvals
Code changes on user-facing features (excluding content updates) require approval from at least one developer and one designer.
All other changes require a single approving review.
The submitter is responsible for merging their PR unless the approver is given explcit permission. Similarly, do not commit to another person's branch unless given explicit permission.
Bias towards approving i.e. "good to merge once X is fixed" rather than blocking until X is fixed, requiring an additional review.
## Pull Requests for User-facing changes
When making user-facing changes, test that your changes work on multiple browsers including Chrome, Microsoft Edge, Firefox, and Safari.
Add new pages to the .pa11yci file so they are included in our automated accessibility testing.
## Other Pull request norms
- Keep pull requests as small as possible. This makes them easier to review and track changes.
- Write descriptive pull requests. This is not only something that makes it easier to review, but is a great source of documentation.
[comment]: The Coding standards section will be moved to a new code standards file in #2898. For now we're simply moving PR template content into the code review document for consolidation
## Coding standards
(The Coding standards section may be moved to a new code standards file in a future ticket.
For now we're simply moving PR template content into the code review document for consolidation)
### Plain language
All functions and methods should use plain language.
TODO: Plain language description and examples in code standards ticket.
TODO: Plain language description and examples in code standards ticket.