Skip to content

Latest commit

 

History

History
104 lines (74 loc) · 6.23 KB

CONTRIBUTING.md

File metadata and controls

104 lines (74 loc) · 6.23 KB
Raw

Contributing guidelines

First of all, thanks for your interest in helping us build Divi! As more coders are joining our cause, we had to create these guidelines to set some standards and keep everyone on the same track. So here are a few rules and tips to get you started faster and make everyone's life a bit easier.

  1. Dev workflow
    1. Issues
    2. Pull Requests (PRs)
      1. Create new branch
      2. Commit your code
      3. Submit PR
  2. Dev resources (Angular, components, layouts, icons)

Dev workflow

Quick overview of the workflow:

  1. Bug is found or feature is suggested → new Issue (always check if the issue exists first)
  2. New branch is created with code solving the Issue → Pull Request initiated
  3. After PR is finished, tested and approved (by at least 1 Team member) → merge to dev branch
  4. When multiple PRs are merged, new Release is prepared → merged to master branch

1. Issues

When bug is found or new feature/suggestion proposed, new Issue gets created. Our repo has predefined Issue template to help you started with that (the more info you provide the better).

  • Always keep the Issue's title short and descriptive!
    • Examples:
      • ✅ "Pagination in Address book doesn't work (macOS)"
      • ❎ "When you click next page in address book nothing happens and 2 pages are hidden please help!!!1!"
  • Include as much related information in Issue's description as you can (the predefined template will help you with that)
    • For bugs: what's happening, how to reproduce it, what OS/version are you using, ...
  • Tag the Issue with Labels to categorize it (is it a bug or just an enhancement of existing feature?). If you're not sure which label to use, leave them empty, someone else will do that (better no labels at all than wrong ones)
    • bug - for broken functionality/UI, bad behaviour
    • feature - adding new functionality
    • enhancement - tweaks for existing features

It's usually up to Project Manager or someone from the Team to:

  • Assign workers to Issues
  • Assign Milestones (AKA "releases") for concrete Issues – please don't assign Milestones to your own Issues if you're not absolutely certain, that the feature/bug must be included in certain release!

2. Pull Requests (PRs)

PRs are working "packages" of code, solving one bug / new feature and are usually connected to existing Issues. For creating new PRs, you must first fork this repository to your own account.

2.1. Create new branch

After your repo is ready, create new branch.

  • Again, keep branch names short and descriptive
  • Ideally also tag your branch with prefix/.. – this helps categorizing all the branches at first glance. Some examples:
    • fix/.. - for bug fixing, e.g. fix/createwallet
    • feature/.. - for new features, e.g. feature/coldstaking
    • gfx/.. - for graphic/UI/UX tweaks, e.g. gfx/typography

When your branch is ready, do your changes and push them to the branch. Be sure to push only the changes related to the connected Issue! Don't solve multiple Issues in one PR.

2.2. Commit your code

  • Write meaninful commit messages (PRs will be refused if they are not described correctly) – commit messages should make sense on their own. Don't forget that when your PR is merged, its context is lost. Meaning that once your commits get to dev branch, it's harder to say what each commit does just by its name:
    • ❎ Bad commit message: "fixed button"
    • ✅ Good: "Receive: fixed 'copy address' button"

2.3. Submit PR

When your code is complete and ready, submit new Pull Request.

  • Always set your base branch to dev (never to master or others!) – dev is our main development branch
  • As always, write short and descriptive title (you can keep it the same name as your branch)
  • Describe what has been done in description – what does this PR solves? We usually list all the changes and even include a screenshot/GIF overview of the original issue and the final result. This greatly helps the Reviewers and Testers as they know what to focus on.
  • Include references to Issues that this PR solves – Writing Fixes #[number] automatically connects this PR to Issue [number] and when this PR gets merged later, the corresponding Issue gets automatically closed.
  • Tag your PR with Labels – Labels help other to see at first sight what's needed next. The most common are:
    • WIP - "work in progress" for ongoing work, not meant to be merged yet (if you're on a longer task)
    • GFX - for tasks needing graphic work (e.g. functionality is ready, but it's missing design tweaks)
    • PRG - same, but for programming work (e.g. design is ready, but it's missing functionality)
    • ready for review - task is done and waiting to be reviewed and merged
  • Don't assign any milestones! Leave that for the Project Manger or Core Team members

After your PR is 100% ready, label it as ready for review and optionally assign one/some of the Reviewes:

  • for development (Angular etc.): @pciavald @kewde @rynomster
  • for design (GFX, layouts etc.): @gerlofvanek @allienworks

Reviewers will either ask you for some code changes or approve the PR and merge it.

Dev resources