Skip to content

Trello workflow

Jacob Wegner edited this page Jun 26, 2020 · 5 revisions

The Scaife Viewer team currently uses three boards to coordinate development:

See below for an overview of each board and an explanation on how they relate to one another.

Scaife : Roadmap

Used to track high-level functionality across the Scaife Viewer ecosystem

The labels attached to cards help to indicate which subsystems will require changes to implement the new functionality.



Features directly related to reading texts

Navigation / Search

Features relating to navigating / searching texts


Features related to annotating texts


Features related to the ATLAS text server

Other Services

Features related to other (non text-server) services

Corpus Management

Features related to managing a corpus

Content Access

Features related to controlling access to texts

Localization / Accessibility

Features related to improving localization / accessibility

Scaife : Planning

Used to plan out concrete epics that implement features, and track future improvements to existing features


Backlog : *

Capture future improvements to an existing feature area

Epics to Groom : *

Used to collect individual cards that make up a concrete epic that implements a feature

Epics Ready for Dev

Once an epic has been built in "Epics to Groom", we create an epic card and attach all story cards as children. The story cards are transferred to "Ready for Dev" on the Scaife : Development board

Epics In Progress

When a developer pulls a story within an epic from "Ready for Dev" to "In Progress" on the Scaife : Development board, the parent epic card is mirrored here to show progress.

Done This Quarter

After an epic has been implemented, its completion is tracked by moving it to this list.

Done Last Quarter

At the end of the quarter, tasks in "Done This Quarter" will migrate to "Done Last Quarter".

The previous "Done Last Quarter" will change to a "Done YYYY-##" list that will be archived.

Scaife : Development

Used to track implementation of user stories relating to the epics groomed on the planning board.



Capture tasks, features, and bug reports. Larger features are groomed as "Epics" on the "Planning" board.

Ready for Dev

Cards in ready for Dev should have a defined acceptance criteria (a definition of what is required to consider the card "done"). They should likely be linked to an epic on the "Planning" board.

In Progress

Team members should assign themselves to a card and move it to "In Progress" when they start working on it.

Pull Request

For development cards, this column signifies that the feature or bug is ready for peer-based code review.

Ready for Review

After a feature or bug has passed peer review and been approved, the developer should notify the product owner (currently @jtauber) that the feature has been implemented and provide a link to a preview deploy and/or screenshots demonstrating the feature.

If the feature has been implemented as defined by the acceptance criteria, the product owner will move the card to "Done/Accepted".

If further changes are required, the "BLOCKED" label should be applied to the card and a comment should be left discussing what further changes / updates should be made.

Done / Accepted

Once a feature has been implemented and accepted, the product owner moves the card to "Done / Accepted".

The release manager (currently @jacobwegner) will then merge the approved PR into develop and deploy to the QA instance.

Deployed This Month

After features have been accepted by the product owner, the release manager will prepare a release PR from develop to master. Once the release PR is closed, a new version of the applicable site (sv-mini or explorehomer) will be deployed.

Deployed Last Month

At the end of the month, tasks in "Deployed This Month" will migrate to "Deployed Last Month".

The previous "Deployed Last Month" will change to a "Deployed YYYY-MM" list that will be archived.