This is Gitea test Portainer repository mirror from Github
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long. 3.8 KiB

  1. # Contributing Guidelines
  2. Some basic conventions for contributing to this project.
  3. ## General
  4. Please make sure that there aren't existing pull requests attempting to address the issue mentioned. Likewise, please check for issues related to update, as someone else may be working on the issue in a branch or fork.
  5. * Please open a discussion in a new issue / existing issue to talk about the changes you'd like to bring
  6. * Develop in a topic branch, not master/develop
  7. When creating a new branch, prefix it with the *type* of the change (see section **Commit Message Format** below), the associated opened issue number, a dash and some text describing the issue (using dash as a separator).
  8. For example, if you work on a bugfix for the issue #361, you could name the branch `fix361-template-selection`.
  9. ## Issues open to contribution
  10. Want to contribute but don't know where to start?
  11. Some of the open issues are labeled with prefix `exp/`, this is used to mark them as available for contributors to work on. All of these have an attributed difficulty level:
  12. * **beginner**: a task that should be accessible with users not familiar with the codebase
  13. * **intermediate**: a task that require some understanding of the project codebase or some experience in
  14. either AngularJS or Golang
  15. * **advanced**: a task that require a deep understanding of the project codebase
  16. You can use Github filters to list these issues:
  17. * beginner labeled issues:
  18. * intermediate labeled issues:
  19. * advanced labeled issues:
  20. ## Commit Message Format
  21. Each commit message should include a **type**, a **scope** and a **subject**:
  22. ```
  23. <type>(<scope>): <subject>
  24. ```
  25. Lines should not exceed 100 characters. This allows the message to be easier to read on github as well as in various git tools and produces a nice, neat commit log ie:
  26. ```
  27. #271 feat(containers): add exposed ports in the containers view
  28. #270 fix(templates): fix a display issue in the templates view
  29. #269 style(dashboard): update dashboard with new layout
  30. ```
  31. ### Type
  32. Must be one of the following:
  33. * **feat**: A new feature
  34. * **fix**: A bug fix
  35. * **docs**: Documentation only changes
  36. * **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
  37. semi-colons, etc)
  38. * **refactor**: A code change that neither fixes a bug or adds a feature
  39. * **test**: Adding missing tests
  40. * **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
  41. generation
  42. ### Scope
  43. The scope could be anything specifying place of the commit change. For example `networks`,
  44. `containers`, `images` etc...
  45. You can use the **area** label tag associated on the issue here (for `area/containers` use `containers` as a scope...)
  46. ### Subject
  47. The subject contains succinct description of the change:
  48. * use the imperative, present tense: "change" not "changed" nor "changes"
  49. * don't capitalize first letter
  50. * no dot (.) at the end
  51. ## Contribution process
  52. Our contribution process is described below. Some of the steps can be visualized inside Github via specific `status/` labels, such as `status/1-functional-review` or `status/2-technical-review`.
  53. ### Bug report
  54. ![portainer_bugreport_workflow](
  55. ### Feature request
  56. The feature request process is similar to the bug report process but has an extra functional validation before the technical validation as well as a documentation validation before the testing phase.
  57. ![portainer_featurerequest_workflow](