mirrors/woodpecker
1
0
Fork 0
mirror of https://github.com/woodpecker-ci/woodpecker.git synced 2024-11-19 00:11:16 +00:00
Code Issues Projects Releases Wiki Activity
woodpecker/CONTRIBUTING.md
Patrick Schratz bd46c01a3e
Use pre-commit (#2650)
2023-10-28 21:58:59 +02:00

3.8 KiB
Raw Blame History

Contributing

Maintainers

To make sure every Pull Request (PR) is checked, we have team maintainers.
Every PR MUST be reviewed by at least one maintainer (or owner) before it can get merged.
A maintainer should be a contributor and contributed at least 4 accepted PRs. A contributor should apply as a maintainer in the Discord #develop or Matrix Develop channel. The owners or the team maintainers may invite the contributor. A maintainer should spend some time on code reviews.

If a maintainer has no time to do that, they should apply to leave the maintainers team and we will give them the honor of being a member of the advisors team. Of course, if an advisor has time to code review, we will gladly welcome them back to the maintainers team. If a maintainer is inactive for more than 3 months and forgets to leave the maintainers team, the owners may move him or her from the maintainers team to the advisors team.

For security reasons, Maintainers must use 2FA for their accounts and if possible provide GPG signed commits.
https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/ https://help.github.com/articles/signing-commits-with-gpg/

Owners

Since Woodpecker is a pure community organization without any company support, to keep the development healthy we will elect two owners every year.
This can also happen when a owner propose a vote or the majority of the maintainers do so.
All maintainers may vote to elect up to two candidates. When the new owners have been elected, the old owners will give up ownership to the newly elected owners. If an owner is unable to do so, the other owners will assist in ceding ownership to the newly elected owners.

For security reasons, Owners must use 2FA.
(Docs: Securing your account with two-factor authentication)

To honor the past owners, here's the history of the owners and the time they served:

Code Review

Once code review starts on your PR, do not rebase nor squash your branch as it makes it difficult to review the new changes. Only if there is a need, sync your branch by merging the base branch into yours. Don't worry about merge commits messing up your tree as the final merge process squashes all commits into one, with the visible commit message (first line) being the PR title + PR index and description being the PR's first comment.

Once your PR gets approved, don't worry about keeping it up-to-date or breaking builds (unless there's a merge conflict or a request is made by a maintainer to make modifications). It is the maintainer team's responsibility from this point to get it merged.

Versioning

We use Semantic Versioning to be able, to communicate when admins have to do manual migration steps and when they can just bump versions up.

Development

pre-commit is used in this repository. To apply it during local development, first

  1. Install pre-commit via your favorite option
  2. Enable it via pre-commit install in the repository root.
  3. (Run it manually via pre-commit run --all-files in the repository root.)
  4. Now pre-commit will exec on all modified files before every commit.