Blockchain Dev Board

Our board consists of columns each having different meaning and purpose.

  1. Unsorted Ideas is an unsorted list of issues that are to be finished by the author and when needed confirmend by the product owner before they can be put into the Backlog column.

  2. Backlog column is an ordered list of issues, important being on top of the list. Please periodically check all items in that column and participate in discussions in order to prepare each issue. When adding a new issue to this column, put it on the very bottom of the list. Note only product owner should add/reorder items here

  3. Ready For Development column is an ordered list of issues that were discussed. Described features are clear to everyone and ready to be implemented. Only during a refinement session can we drag issues into this column. When picking work from that column, always take from the top.

  4. In progress contains issues that are in development. Remember to assign yourself when you take the responsibility for finishing the issue. Issue stays in this column until it is done.

  5. Needs review contains only pull requests (no issues) that require an approval.

  6. Reviewer approved contains only pull requests.

  7. Done contains issues that fulfill our Definition Of Done.

Code review and design decisions

Prepare the stage

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

When doing a Code Review

Please use the following notation to give some “weight” to your comments:

Notation

Blocking

  • Req (Required) - this needs to be changed and it is blocking this pull request from being merged

  • Q (Question) - the answer may provide additional information which may block the pull request. Therefore a question should be considered blocking as well unless marked as not blocking by the author

Non blocking

  • PP (Personal preference) - suggestion but no change is required

  • Note - random comment

Examples

  • Nice to have -> PP

  • Feature missing -> Req

  • Applause -> no prefix required

When reviewing a Design Document

It can take a very long to find some consensus with everybody. The author has spent some reasonable time and thoughts on providing a document already to solve a specific problem. Please appreciate this even if you had a different solution in mind before. Best would be to provide qualified feedback and have the process as short as possible.

Your feedback comment should:

  • always be actionable. Finishing your comment with a question might make it easier to continue the discussion,

  • contain an indication if you can accept the proposed solution (reactions like 👍 and 👎),

  • if the proposed solution is not acceptable, always write what is missing and why do you think it is necessary,

  • use the review notation to give your comments some weight.

How to use “reviewer” field on Github

With reviewers, you can assign one or multiple persons to give you feedback on a pull request. Please note that assigning multiple persons would slow the process as the pull request won’t get merged before everybody in that list has approved your pull request. It mostly is easier to assign a single person or leave this empty and ping the group via slack.

Changelog

We have decided to manually maintain the CHANGELOG.md file.

Each release contains a list of changes introduced. Breaking changes should be listed under Breaking changes subsection. When making a new release, change HEAD section to the release version and create a new empty HEAD section.

Each pull request must modify CHANGELOG.md file or the check will fail. Add #trivial to the comment to bypass this check.