New project board functionality

[fyliu]

This is an ongoing documentation of how the project board is set up, what the various tabs show, and how they're intended to be used.

Tabs that work as-is

All tab

• view:
  • displays the project board view, which shows everything with no filters
• audience:
  • everyone
    • this is where to go to find an issue or PR, by typing the name in the filter box
    • it's general purpose and everything can be done in this view
    • it contains all the issue statuses that they would progress through
  • PM
    • can manually move issues in the Prioritized Backlog... to prioritize them by milestone and then by what need to be done first
• possible changes
  • some of the statuses are not states that issues can be in
    • Question/Review are issue needs rather than a state of the issue. The issue is still In Progress or it's On Hold if it's blocked waiting for something to happen
    • Issue: New issue, ready for work, in progress, on hold, done
    • PR: needs review, being reviewed,

Assignee

• view:
  • displays the issues that are being worked on (or at least assigned), grouped by status, sliced by Assignees
• audience:
  • contributor:
    • See the My Issues tab description
  • PM:
    • can see what contributors are working on, where the left sidebar shows each contributor's issues count
    • to see if contributors are working to too many issues at the same time
    • to see if contributors may be able to work on something new
    • to see if issues being worked on has the wrong status (i.e. still in the Prioritized backlog)

My Issues

• view:
  • displays the issues the contributor them self is working on (or at least assigned), grouped by status
• audience:
  • contributor:
    • can see select their name in the left sidebar to see what they're currently working on
    • to make sure what they're working on is In progress
    • to get back on track with the work
    • to follow up on what they need to continue working on the issues
    • to follow up on re-requesting reviews of their PRs

PM

• view: All columns view filtered for issues for role: product and ready for product
• audience: PM
  • to see issues that concern them
  • this is the combined view of Prioritized Backlog: Product and Ready for: Product views

db architect

• view: All columns view filtered for issues for role: db architect and ready for Architect
• audience: DB Architect
  • to see issues that concern them
  • this is the combined view of Prioritized Backlog: DB Architect and Ready for: Architect views

design

• view: All columns view filtered for issues for role: design
• audience: designers
  • to see issues they can work on and where they are in the status pipeline
  • this view is not task-focused but is more general-purpose
  • if looking for design issues, the designer can go to Prioritized Backlog
  • if looking for issues they're working on, they can go to Assignee
  • if there isn't something else useful about this view, it might be a candidate for removal

backend

• view: All columns view filtered for issues for role: back end
• audience: backend developers
  • to see issues they can work on and where they are in the status pipeline
  • this view is not task-focused but is more general-purpose
  • if looking for backend issues, the dev can go to Prioritized Backlog
  • if looking for issues they're working on, they can go to Assignee
  • if there isn't something else useful about this view, it might be a candidate for removal

initial version

• view: All columns view filtered for issues with the v0.01 - initial setup milestone, hiding milestone and status in the issue cards
• audience:
  • PM looking at all the issues remaining to be worked on and where they are in the status pipeline
• possible variation with proposed changes
  • hide labels and show Role, Size, Complexity if added, for a less cluttered view of each issue

Tabs that require changes

1. New fields
   • I already created some fields in order to show how the views could work
   • they mirror what's already in labels, but there are advantages as noted below
   • the fields are added on and can be deleted if we don't think they're useful enough
   • I'm manually updating the field values but they can and should be automated if we keep them

Prioritized Backlog

• view:
  • list view of issues in the Prioritized Backlog column that contains a role label, grouped by milestone, sliced by Role
• audience:
  • contributors looking for a project to work on
    • they should select their role on the left sidebar to see the issues available to them
    • the Complexity field in the issue rows show how hard they are
    • the good first issue and size labels may need to be typed in the box if the user wants to filter by those.
  • PM looking to see if there are issues without a role
    • click on the No Role(if visible) in the left sidebar to show issues with no role
    • right now, this depends on the issues having a role: missing label
    • we can automate this just like the role: missing to mark issues without roles
• possible variation
  • columns view by Complexity
    • visually separates Small, Medium, Large complexity issues
    • No Complexity abnormality shows up prominently as a column
• changes needed
  • Role field isn't officially added
    • it mirrors the role labels
    • it allows us to show just the field's values in the left sidebar (as opposed to all the label values)
  • Complexity field isn't officially added
    • it mirrors the complexity labels
    • it allows us to display it as an issue column (as opposed to label)
  • Size field can be added to eliminate the manual filtering for it
    • I think it makes sense to add it. Reasoning later.

Ready for

• view:
  • list of issues requiring attention from the smaller groups of project leads, grouped by status, sliced by Ready for
• audience:
  • members of the project lead groups: Architect, Dev Lead, and Product
    • they should select their group from the left sidebar to see the issues requiring their attention
• changes needed
  • Ready for field isn't officially added
    • it mirrors the ready for labels
    • it allows us to show just the field's values in the left sidebar (as opposed to all the label values)
    • what it doesn't cover is cases where there are multiple ready for labels. Fields can have just a single value.

PRs

• view:
  • displays a list of open PRs showing Assignees and Reviewers, sorted by Reviewers, and grouped by status
• audience:
  • reviewers can look at what PRs are in the PR Needs review... status and review them
  • developers
    • can see which of their PRs are being reviewed in the PR being reviewed status
    • can see if their PRs are not being reviewed and request a review
  • PM can see if PRs are not being reviewed and ask for more reviewers
• notes:
  • PR Assignees is being set to the PR author in order to display who it belongs to in this view
• changes needed
  • automation to assign the PR to its author

Roadmap

• view:
  • a timeline view of issues being worked on and completed over time
• audience:
  • PM can see what issues are being done and the speed they're being completed
    • gives a better estimate for the remaining issues?
• changes needed
  • add start and end fields for starting to work on an issue to time of completion
  • automations to set the start and end times

Suggested changes

1. convert labels to fields

   1. "Required" fields
      • role
      • size
      • complexity
      • feature (can have multiple features, so not suitable)
      • stakeholder (can have multiple stakeholders, so no suitable)
      • milestone (already a separate issue field)
   2. Other fields
      • choices
        • ready for
      • toggles
        • PII
        • dependency (infrequently used)
        • draft (infrequently used but maybe handy to have as a separate field to toggle
        • epic
        • good first issue
        • question

2. add fields

   • add start and end fields

3. automations

   1. sync between labels and fields
      • role
      • size
      • complexity
   2. on PR creation, assign the PR to the author. See PRs tab description for how it's used
   3. on issue moved to In progress the first time, automation to set the start time
   4. on issue moved to Done, automation to set the end time