зеркало из https://github.com/mozilla/dinobuildr.git
2.3 KiB
2.3 KiB
Contributing to dinobuildr
Anyone may contribute issues or code to dinobuildr as long as the following guidelines are adhered to.
-
All contributors are expected to follow the Mozilla Community Participation Guidelines outlined at https://www.mozilla.org/en-US/about/governance/policies/participation/
-
Issue naming schema (Recommended):
- The following are naming conventions already in production. There may also be open issues that do not conform to the schema as well.
- Bug: [short description of the bug]
- Documentation: [short description of requested documentation]
- Feature: [short description of the feature]
- Update: [short description of the update]
- Update should be used for changes to existing Documentation, Features, etc Please note: other issue types can be created as needed, per the discretion of Mozilla staff maintaining the project
-
Naming branches:
- Branch names should be written in kebab-case (https://en.wikipedia.org/wiki/Kebab_case) and should and should follow the following pattern:
- bug-shortbugname
- doc-shortdocummentname
- feat-shortfeaturename
- upd8-shortupdatename
- Kebab-case helps distinguish between files in the repositories, which are mostly in snake_case (and will primarly transition entirely to snake_case with future commits)
- Branch names should be written in kebab-case (https://en.wikipedia.org/wiki/Kebab_case) and should and should follow the following pattern:
-
Commits:
- Each commit should be small, complete, and isolated to a specific change.
- In example:
- If you're updating the link to the DMG installer of a piece of software the changes in the commit should be limited to updating the path for the installer in the appropriate *_manifest.json and the hash for the DMG.
- A second commit should then be performed to update the hash of the *_manifest.json file in dino_engine.py
- In example:
- Each commit should be small, complete, and isolated to a specific change.
-
Pull Requests:
- Pull requests should reflect a tightly focused group of commits that serve a singular purpose, like updating the files associated with a particular software download, or naming convention change.
- Pull Request naming should reflect the changes that were made
- Pull Request comments should explain the changes that were made in the commits that made up the PR
- Pull Requests must be reviewed by at least one additionl project member, and can only be merged by project admins
- Pull requests should reflect a tightly focused group of commits that serve a singular purpose, like updating the files associated with a particular software download, or naming convention change.