process flow

Getting Started

This section covers how to use a Github project area/repository the 'Citizen way'. Knowledge of this process is important to everyone, as it sets the common process and expectations, which enables us to rely on each other and our content. As a developer in a project area your tasks may very. Please modify the order of these flows to best suit your needs, while maintain the core sprit of the flow.

Tasking

Tasking/Work tracking is handled though github issues. By using detailed issues, we can track progress, have meaningful conversations and maintain a detailed record of all the knowledge we have surrounding a problem or idea. Clean, effective issues is the backbone to our ability develop rapidly and exceptional confidence in our project to our clients. While it can be time consuming especially for small tasks, the importance can not be neglected. As such, no work can be passed though a pull request without an parent issue to document.

Creating a task

• Go to the issue tab and click create new issue in the upper right
• Copy the issue template found here and review the purpose of the sections
• If this is a draft issue, Put a note on the top of the page as you work on the issue
• Fill in the template sections as needed -## Ensure the following
• The body text is written in a tone that is engaging and clearly notes:
  • Who wants this
  • Why we need this
  • What we are doing
  • Why are we doing this
• The correct labels are applied for what features/categories are being referenced
• There is a size (EPIC, Sprint, Story, Task) assigned
• The task is singular in its topic and has a good title.
  • The task when possible should be broken down the into its smallest component parts over many issues

Assigning a task

• If the work you want to do, is not in a GitHub issue. Create the issue by following the (creating a task) flow
• In the issue set the assignee to the person who is responsible to see the issue to completion
• Assign the issue to the current project board into the "Todo"
• Review the milestone and labels to make sure they are still relevant This is generally the task of a Team Leader. If your project does not have one, you are free to choose your own tasks.

Showing progress

Project Board

Meaningful commits

• Do all your work with meaningful commits in your branch

Standup Meetings

Daily check ins.

Weekly reviews

Completion of a task

Code review

Code review is the process to which we commit code to the main branch. You are encouraged to review anyone’s work that you feel that you can review properly.

General practice

The general process for code review is to:

• Create a pull request when you are done to signal a code review
• Address any concerns and review comments
• Commit your code to the main branch

Pull requests

• Write in full, in the pull request all the changes that were done in the branch/pull request
• If detailed testing was required, list all the testing you did
• List what you were trying to achieve and the acceptance criteria for this pull request to pass
  • Linking to the issue is recommended
• Pull requests signal that you are looking for comments and review of your work
• Pull requests can be made at any time, but prefered to be made when work is complete
• When ready for review, mark it as ready for review with a label.
  • If you are a team lead you may assign the best person for the review at this time
  • You may pick up any review for yourself but your own. Unless the project allows self-review.

Closing the issue

Deleting the branch

Handling found bugs

Create a issue marked with the label PR detailing the problem and if applicable, reference the pull request and the original issue that this bug was introduced from. This will give context around what we were trying to achieve and any conversations we may have had around the issue..