Home

Welcome to the dip-access-interface wiki! Following are some guidelines for how CCARchitects and Artefactual will use Waffle to manage the DIP access (now called Scope) project:

Waffle column definitions

Principles:

• Cards move to the right only, never to the left. If blocked, use tag ‘blocked’
• Link issue to PR in original comment in Github wherever relevant
• Using # and the pull request will auto-link the issue and the PR - eg #23

Inbox

• All new and open issues will show up here. Be sure to filter using the appropriate tags
• Can be assigned or not
• Tagged appropriate labels including: phase of project, target release

Backlog

• Cards cannot be moved to this column unless they are assigned to someone.
• Cards in this column must include tags.
• Cards in this column may require further discussion or articulation.
• This is the step between identifying a problem and taking concrete action to resolve the problem.
• Cards in this column may be discussed and closed if no action needs to be taken.
• Cards requiring development work should be reviewed by CCA before they can be moved to the Ready column.

Ready

• Cards are moved to this column when they are ready to be worked on.
• Cards requiring development work are in this column only after CCA approval.
• Team members can assign a card to themselves, move the card to ‘In progress’ and begin work.

In progress

• Cards are moved to this column when a developer is actively working on the issue.

Review

• Issues that have been resolved by a merged PR and are now ready for client or analyst QA.
• Cards are moved to this column when they are ready for review by the CCA (or by team members).
• Cards in this column should be assigned to at least one person for review.
• Client should make comments to the issue or PR to demonstrate that they have reviewed.

Done

Cards are moved to this column when

• An issue is closed
• A pull request has been merged
• CCA has agreed that the work is complete

Workflow for Feature Files

Some issues can be resolved without code changes - an issue may require just an answer, or the issue can be resolved in a specific deployment with a configuration change.

When the issue requires a code change the first step should be to create a feature file describing the desired outcome.

There are multiple ways this workflow could happen - here is one suggestion:

1. Issue #1 filed by client - shows up in inbox
2. Moved to refining - additional detail added to issue by devs/analysts as required
3. Feature file developed, PR in acceptance tests filed - tagged as ‘fixes #1’
4. Issue #1 is moved to ready - client reviews and agrees feature file describes the required outcome/behaviour.
5. Feature file is merged
6. Issue #1 is moved to in progress as a dev starts work on implementing the feature
7. New PR made in some other repo that solves the issue, issue is moved to Review
8. Client reviews pr (or just analysts and devs do) issue is moved to Done