Project Board and Issues

Overview

The HUU team uses one GitHub Project Board, creating tasks, tickets, Epics, and User stories, etc. as Issues for all teams.

Project Board

Our Project Board is a Kanban style board, which organizes cards into columns.

Weekly Tasks:

These issues are for recurring meetings and tasks that occur on a weekly basis.

• All Team Meeting Agenda
• PM Meeting Agenda
• PM/Org Meeting Agenda
• Board Check

Columns/Statuses

The columns are broadly used as Statuses for the cards/issues within them

Typical column flow for issues

Start Here

This column (was) used for helpful tips/links for anyone who might be using the board. Those tips will be moved to the Wiki (see #705).

Recurring Items

This column is for Issues that are left open to be used on an ongoing basis. For example Agendas, Recurring Checklists, Onboarding/Offboarding, General Questions.

Agendas

Recurring Checklists

Onboarding/Offboarding

Ice Box

This column is for Issues identified that are going to get addressed, but are not being started yet because of dependencies.

All issues in the Ice Box should have a dependency issue that is a blocker so that it is clear when the issue will come out of the Ice Box.

New Issue Approval

This column is for all issues that are newly created or coming out of the icebox that need to be reviewed by Product to make sure they are complete and prioritized.

Prioritized Backlog

This column is for Features that are ready to work and a priority. This column should be prioritized from top to bottom by most important at the top.

In Progress

This column is for tasks that are actively being worked on by an individual team member and have been assigned to them in the issue.

For Review/Feedback Needed

This column is for Issues which need review or feedback in order for the person assigned to progress towards completing the issue. This column is also used as a "Blocked" column.

Any Issues in this column should use one of the following labels, so the appropriate team/lead can easily find it:

• Ready for Product
• Ready for Dev Lead
• Ready for Design Lead
• Ready for Research Lead

User Acceptance Testing

This column is for features that are ready to proceed with User Acceptance Testing, so that we can confirm that the feature is working effectively for Users.

Done

This column is for Issues that are complete. There should not be any work left to be performed for these Issues.

All issues in this column should be marked as Closed.

Legacy Tickets

This column is for Issues [DESCRIPTION NEEDED]

Issues

Closing Issues

Close as completed

Close as not planned

Comments

Saved Replies

Milestones

Milestone	Description
1- Setup project
5-Stakeholder Demo
6- MVP
7- Post MVP
Legal Compliance
x- Continuous
y - Cleanup

Formatting

General Issues/Tasks

For general issues/tasks, the Blank Issue Template can be used. It can be selected from the Templates list when creating a new Issue. It is also pasted below:

**UPDATE LABELS: Add the following labels to each new issue, and remove defaults:**
* Role
* Feature
* Points 
* Milestone

### Overview
REPLACE THIS TEXT -Text here that clearly states the purpose of this issue in 2 sentences or less.

### Action Items
REPLACE THIS TEXT -If this is the beginning of the task this is most likely something to be researched and documented.

REPLACE THIS TEXT -If the issue has already been researched, and the course of action is clear, this will describe the steps.  However, if the steps can be divided into tasks for more than one person, we recommend dividing it up into separate issues, or assigning it as a pair programming task.

### Resources/Instructions
REPLACE THIS TEXT -If there is a website which has documentation that helps with this issue provide the link(s) here. For example, a link to Figma, if applicable.

User Stories

User Stories currently follow a consistent format.

This document has been created to document the current User Story Template.

• This template still needs to be reviewed
• The template currently has a lot of sections, could maybe be cut down
• Once the template is finalized it should be added to the Issue Templates

Epics

Assignees

There should only be one person Assigned to each issue. They should be the one responsible for completing the work in the issue.

Labels

Each issue should have the appropriate labels.

Some labels are part of a category. Instructions for how and when to use labels are below.

Difficulty and Time

Complexity

Ask Yourself	Answer
When	Complexity labels should primarily be used for Engineering/Development issues.
Why	The purpose of this label is to categorize issues by complexity so that developers can progress through the levels over time.
How	See this issue for a description of the progression of issue complexity for developers.

Points

Ask Yourself	Answer
When	Points labels should be used for all issues.
Why	Points labels are used to estimate the amount of time an issue will take.
How	Each Points issue has a description with the range of hours that the points represent. Select the most appropriate Points amount based on your estimate of hours.

List of Variations:

Label	Description
points: 1	Can be done in 6 hours or less
points: 2	Can be done in 7-12 hours
points: 3	Can be done in 13-18 hours
points: 5	Can be done in 19-30 hours
points: 8	Can be done in 31-48 hours
points: 13+	Must be broken down into smaller issues

Features and Sections

Feature

Ask Yourself	Answer
When
Why	The Feature labels are meant to relate issues to functionality for the HUU application.
How	The labels are based on the Master User Stories document

List of Variations:

Label	Description
Feature: Accessibility	Enhancements to website accessibility
Feature: Administrative	Administrative chores, etc...
Feature: Agenda
Feature: Analytics
Feature: Architecture
Feature: Board/Github Maintenance	Repeated project board maintenance
Feature: Design System
Feature: Infrastructure	Changes to site technical Architecture
Feature: Missing
Feature: Refactoring
Feature: Security/Regulatory Compliance
Feature: Tech Debt
Feature: Testing
Feature: Wiki

p-Feature

Similar to the "Feature" label, "p-Feature" are features which are end user facing.

List of Variations:

Label	Description
p-Feature: Accept/Reject
p-Feature: Application Guest
p-Feature: Application Host
p-Feature: Calendaring
p-Feature: Dashboard Admin Coordinator
p-Feature: Dashboard Coordinator
p-Feature: Dashboard Guest
p-Feature: Dashboard Host
p-Feature: Guest Bookmarking Hosts
p-Feature: Guest Dashboard
p-Feature: Guest Registration	Issue related to Guest Registration
p-Feature: Host dashboard
p-Feature: Host Registration	Issue related to Host Registration
p-Feature: IAM	Identity Access Management
p-Feature: Landing Page
p-Feature: Matching
p-Feature: Profile Coordinator
p-Feature: Profile Guest
p-Feature: Profile Host

i-Interface

Ask Yourself	Answer
When
Why	The i-Interface label is for items related to the interface and experience of the HUU application.
How

List of Variations:

Label	Description
i-Interface: Coordinator Interface	Items related to the Coordinator interface & experience.
i-Interface: Guest Interface	Items related to the Guest interface & experience.
i-Interface: Host Interface	Items related to the Host interface & experience.
i-Interface: Master Admin Coordinators	Items specific to Master Admin Coordinators

Section

Ask Yourself	Answer
When
Why	The Section label is used for relating issues to the relevant Major Flows Section
How

List of Variations:

Label	Description
Section: 1	Related to Major Flows Section 1: Account Creation
Section: 2	Related to Major Flows Section 2: Application & Onboarding Process
Section: 3	Related to Major Flows Section 3: Matchmaking / Relationship Creation Process
Section: 4	Related to Major Flows Section 4: Relationship Management / Monitoring Process
Section: 5	Related to Major Flows Section 5: Relationship Termination Processes
Section: 6	Related to Major Flows Section 6: Special Cases

Teams and Reviews

Ready for

Ask Yourself	Answer
When	If you need help/feedback/review from a team/lead on an issue you have added to the "For Review/Feedback Needed" column.
Why	The "Ready for" label allows for the appropriate team/lead to easily filter and identify issues which they are being asked to help/review/provide feedback for.
How	The different variations of the "Ready for" label specify different teams/leads that can help/review/provide feedback for your issue.

List of Variations:

Label	Description
Ready for: Design Lead	Issues which need review by a Design Lead before it is ready for the Prioritized Backlog
Ready for: Dev Lead	Issues which need review by a Dev Lead before it is ready for the Prioritized Backlog
Ready for: Product	Issues which need review by Product before it is ready for the Prioritized Backlog
Ready for: Research Lead	Issues which need review by a Design Lead before it is ready for the Prioritized Backlog

Role

Ask Yourself	Answer
When	All issues should have a Role label
Why	The Role label allows for teams to easily filter to see only the issues that their team owns
How	There should only be one Role per issue

List of Variations:

Label	Description
Role: Back End
Role: Data Science
Role: Design
Role: DevOps
Role: Front End
Role: missing
Role: PM
Role: Research
Role: UI/UX	To be deprecated, being split into Design and Research. See #704

Other Labels

Label	Description
bug	Something isn't working
Code Design
Common	common process or feature appears across all users
dependencies	Pull requests that update a dependency file
Dependency
documentation	Improvements or additions to documentation
draft
duplicate	This issue or pull request already exists
enhancement	New feature or request
Epics
Goals
good first issue	Good for newcomers
help wanted	Extra attention is needed
invalid	This doesn't seem right
javascript	Pull requests that update Javascript code
Main
Performance
python	Pull requests that update Python code
requirements
Research
Rewrite Issue
User Stories
wontfix	This will not be worked on