Skip to content

Working Process

Jump to bottom
zero edited this page Feb 12, 2019 · 2 revisions

To ensure a high quality of code in official NubeIO repositories

Git

We currently use pull requests to manage all code that gets pushed to the main repositories. In order to make the management of all pull requests I would like to suggest the usage of git-flow.

Simple rule

  • If you've done any work, push your work branch at least once a day. It doesn't matter if it's not finished. It doesn't matter if it doesn't compile. Pushing your work serves two main purposes:

    • It provides visibility to the other developers, and to the wider community about the approach you are taking.
    • Other developers can make comments on commits and discuss progress. It avoids situations where a developer has spent 2 months working on something behind closed doors before presenting it, only to find out it's taken a completely wrong approach. If you don't push the assumption will be no coding is going on.
    • It provides a backup.

  • After working on your work branch, when you think your code is ready to be merged to master, you need to make sure it meets the following criteria:

    • It must adhere to the project code style guidelines.
    • There must be very good test coverage that covers all functionality.
    • The public interface(s) of the component must have JavaDoc that can be used by the docgen tool to generate manual documentation [This requirement won't come into action until docgen is complete]
    • New projects must provide a README.md which, at the least, gives an overview of the component.
    • You would be happy to personally use your work in an application upon which your livelihood depended.
    • Make sure CI build green
    • Open new pull request and assign reviewer.
    • Always drop me @zero-88 in PR at early project phase, at least until release v1.0.0.

Pull request

  • The PR must be reviewed by at least one other developer. Other developers are welcome to make comments on the PR too. The review should be carried out by placing comments on the PR in GitHub, not by sending private emails or other means. This provides visibility and provides a public record.
  • Review comments will probably require further changes to the code before the PR is accepted. This is completely normal. Do not expect PRs to be accepted without further changes. Make those changes and tell the reviewer by adding a comment on the PR that you have made them and are ready for the changes to be reviewed.
  • Repeat the above to and fro until there is concensus the work is ready to be merged into master. Once that point is reached, it can be merged.
  • Concensus is always preferable, but if concensus on an approach cannot be reached, the Project Lead should decide on which approach to take.
  • The process is fair and is applied to every developer, without exception.
  • After closed PR, remember closing and appending appropriate labels (S: or R: Fixed)

Branch naming rule

  • Feature/Enhancement/Improvement branch start with feature/<issue_name>
  • Bug fix branch start with bugfix/<issue_name>
  • Master branch is master
  • Release branch is release/<version>
  • Release tag is v<version>

In which:

Handling Issues

  • Must include labels
  • Notice when creating new issue:
    • Ensure it is not already existed (by reviewing label or GitHub suggestion)
    • Reference to other closed/wip issues if it is relating to or regression problem. Otherwise, make update to existed issue
    • Follow issue template of feature/enhancement/improvement or bug

Complexity level

complexity_levels

table_complexity

Code style

Must be adhere to one standard code-style to make reviewer easier. The templates must be downloaded from here then apply it in your IDE

Clone this wiki locally