-
Notifications
You must be signed in to change notification settings - Fork 0
Trello workflow
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.
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.
Reading
Features directly related to reading texts
Navigation / Search
Features relating to navigating / searching texts
Annotations
Features related to annotating texts
ATLAS
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
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.
Used to track implementation of user stories relating to the epics groomed on the planning board.
Inbox
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.