Projects & Tasks

Introduction

The following outlines the process and procedures for how the repo and project are used. Linked Project.

Overview

The basic structure is one of "issues" -- the generic Github item type -- configured into a logical hierarchy, with public discussions, workflows, and status reporting. The goal is to have a "shared task list" organized by project, where various teams can effectively collaborate without confusion or duplication of effort.

Terms

• Cycle = A specified period of time, divided into periods as per the Project Team's desired work cadence. This is important so Tasks can be prioritized for a current workstream vs. future workstreams.
• Issue = Not be confused with a Defect, this is the generic term for all items in this section of the Github repo. All Projects, Tasks, Decisions, and Defects are Github Issues.
• Area = a category defined by the Project Team to break down that team's effort into logical subjects. Example for an Infrastructure team; indexers, validators, nodes, databases, APIs, relayers, and explorers.
• Team = For a Project Team that encompasses multiple organizational or community teams. Allows projects and tasks to be categorized by the team most responsible for the work.

Basic Structure

1. Project = an item that tracks the top level project or initiative. The goal here should be to identify a specific accomplishable "thing". Broader initiatives should be broken down into reasonable achievable projects.
2. Task = an item that tracks one "thing that needs to be done" to complete the project.
3. Decision = an item that tracks an outstanding decision that needs to be made. The goal here is to not only make the Decision, but to take action after the Decision is made. The outcome could drive the creation of a project, several projects, and/or tasks. In some cases it might result in a narrower or more focused Decision. In other cases it might simply result in deciding not to move forward.
4. Defect = an item tracking a problem or system failure. These are usually nested under a project. The goal here is to identify the issue, identify the impact, find resources to address it, and then address it. Defects are often triaged to determine severity, priority, and complexity. These details should be recorded on the Defect. Note; This is the default use of the "Issues" section of Github.

Status

1. Triage = a new item that needs to be prioritized and refined by the team. High priority work can be added to the current cycle while lower priority work can be added to the Backlog.
2. Backlog = this status is for items that will be worked on in later cycles. The project team should have a regular cadence of "pruning" the repository and planning cycles by selecting appropriate projects and tasks from the Backlog.
3. Selected = Items that have not been started. The project team planners have selected these items for work in the current cycle.
4. In Progress = A task that is current being worked on.
5. Pending Approval = A task or project that has completed work and is awaiting approval from the project leadership verifying it has been completed as per the agreed functionality, quality, and expectations of the proposal, requirements, expectations, or specifications.
6. Blocked = Something is preventing this task or project from being completed. Work has stopped. This could be due to an upstream dependency, technical issue, or pending decision.
7. Done = Work on this task or project is complete.
8. Project = a special status for Project items, to keep them seperate from Tasking workflow. This helps keep the Kanban board focused on tasks while projects can be listed in the roadmap.

Workflow

1. A Project is submitted in Triage status with all pertinent details to accomplish the Project.
2. Tasks are submitted in Triage and linked under that Project with a Task List, outlining the specific steps required to accomplish the Project.
3. The Project Team plans what Projects and Tasks are the highest priority for the current Cycle.

Creating & Tracking Projects

• Things to consider when defining a project;
• What needs to be accomplished to complete the project?
• Is the scope defined enough to be a reasonable effort within the time and budget requested?
• Are there enough details, requirements, and/or specifications to accomplish this project?
• Are there milestones or goals identified? Agreements on when these will be reported?
• What is the acceptable quality or measurement that defines completion?

Creating & Tracking Tasks

Things to consider when creating a task; - Are there any other dependencies or other tasks required before this task can be started? - Is this task a reasonable amount of effort within the overall time specified? - Are there enough details for a resource to accomplish this task? - Does this task block other tasks as a requirement or fall within a specified order? Is it linked to those other tasks?

Creating & Tracking Issues

Creating a Tracking Decisions

Things to consider when creating a decision;

• Is the summary clear enough to make a solid decision? Is it really one decision or does it need to be broken up?
• Is the solution or outcome limited? Is this communicated in the decision? If looking for proposals for solutions, you should communicate that upfront! Otherwise, list the limited potential solutions.
• Is the likely outcome another narrower decision? Include that potential outcome.

Nesting Items Under a Project

Project Workflow

Task Workflow

Issue Workflow

Decision Workflow