WeBlog is a community module, built by the community.

If you'd like to get involved and contribute to the module, this page contains useful information for you.

Branching

We use gitflow as a branching model. No particular tools or extensions are prescribed, but the model must be followed.

As such, the master branch contains the latest release and all development should take place on the develop branch. Make sure to use feature branches for any feature implementations. If bug fixes are relatively small they can be done directly in the develop branch.

Code Reviews

Code reviews are done for features, so once a feature implementation is complete, issue a pull request to have the feature branch merged back into develop. Small bug fixes don't generally need to be reviewed but if a bug is large or complex it might be a good idea to push it out to a feature branch and treat it as a feature-bug, using a PR and code review to have it merged back to develop.

Anyone who didn't work on the feature may perform the code review. The reviewer should assign the PR to themselves so others know the PR is being processed.

Test Suite

Pass the Test Suite

Before issuing a pull request, make sure the test suite is passing. We will generally reject any PR that breaks tests.

Add Tests

Although not a requirement, it would be nice to have unit tests in the test project to validate your contribution, if applicable.

Issue Tracker

Assign Issues

Assign the issue to yourself before commencing work on it. This will help avoid multiple devs working on the same issue at once. Also, if a issue is already assigned, don't reassign it to yourself without first checking with the current assingee if they're actively working on it.

Assign a Milestone

Issues should be also be assigned to a milestone before commencing work. This makes it much easier to track when issues were fixed and also to prepare release notes. Users often need to know which exact version a particular issue is fixed in so they know if they need to upgrade or not.

Bugs will normally be assigned to the next minor version of the module and large features to the next major version, though the size of the version may need to be determined closer to release.

Issue Labels

Labels are used on issues to help identify what they are for. For example, use the enhacement label for new features and the bug label for a bug.

Issue Workflow

We use labels on issues in the issue tracker to note at what point in the issue workflow an issue is. Labels starting with a number are workflow labels.

The workflow is as follows:

• 0 - Backlog: The issue is being considered.
• 1 - Ready: The issue is ready to be started.
• 2 - In progress: The issue is being actively worked on.
• 3 - Implemented: The issue is done and is awaiting release.