Skip to content

Rules of engagement

Andy Johansson edited this page Jan 27, 2021 · 3 revisions

This page describes the workflow and the collaboration for the project.

Basic workflow

The basic idea for the workflow is that the source of truth on what we should be working on is GitHub, represented as issues. Clearly visible on the project KanBan Board. The work should be prioritized primarily by Billmate but in collaboration with all parties involved.

Communication

Contextual communication is the preferred communication method. In practice this means that we communicate on issues. However, sometimes other forms of communication is necessary, such as Slack, Teams or a phone call. The important thing is that the outcome of the discussions is documented, contextually on the issue. We all have many things to do and this way keeps us organized and we know where we can find answers.

Planning meeting

A fixed meeting once a month needs to be scheduled to prioritize the work for the upcoming month.

Prioritization

Bugs and defects that have an impact on users production environments should always be prioritized before new features.

Urgent issue

If an urgent issue / situation shows up that requires immediate action the preferred communication method is a phone call between the involved parties. The phone call should result in a plan of immediate actions to resolve the issue / situation.

New idéas

New ideas needs to be submitted through the portal, https://woocommerce.portal.billmate.se/ Billmate defines the roadmap and decides which ideas submitted finally becomes a part of the plugin. If ideas is discovered as an issue in GitHub the label enhancement should be applied so that the product team can easily find the feedback. All new features & improvements will be defined properly in ProductBoard before being created as issues in GitHub. Only features that are committed to start work on should be represented as issues on GitHub. Everything else is handled on ProductBoard.

Bugs & other defects

Bugs and other defects are mainly reported three ways from users. One way is through Billmate support. All reported defects and bugs to the Billmate Support needs to be created as issues in GitHub. The second way is through the WordPress.org Support Forum, https://wordpress.org/support/plugin/billmate-order-management-for-woocommerce/. This forum needs to be monitored by Billmate so that those questions will be answered and resolved. The third way is if a user submits an issue directly on GitHub. The important thing is that all work that needs to be done is represented as an issue on GitHub.

Testing

Developer tests their own code, always, before submitting a pull request. The pull request will then be tested in isolation

Unit testing

Needs addition. Mattias maybe have some ideas?

User acceptance testing

A person with knowledge of the user, or an actual user, should always be conducting the user acceptance testing if a user acceptance test is required.

Pull requests

All code changes needs to go through a pull request. The master branch is protected and should always be deployable.

Naming convention

Commits

Mattias could add some details?

Pull requests

Mattias could add some details?

Releasing

Automatic Mattias could add some details?

Semantic Versioning

This project uses semantic versioning, https://semver.org/. Please follow the standard.