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 Projects

1. Select the "New Issue" button on the Issues page.
2. Select the Project template ("Get started" button).
3. Add a Title. Keep the [PROJECT] label.
4. Fill out as many details as possible. Call out other participants to add more details if needed.
5. Under Task List, select the task list button in the tool bar. This makes it easier to add linked tasks later.
6. Select the Infrastructure Working Group at NEAR project on the right.
7. Select the "Submit new issue" button.
8. Select the carrot under Projects and set the status to "Project".
9. Select the correct Area the project will cover.
10. Select the primary Team for the project.
11. Leave the cycle blank for now.
12. Choose a Start and End date. This can be an estimate and can be changed later.
13. After creating tasks, you can return to the project to add tasks.
14. Use the search under the task list to find and select child tasks.

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 Tasks

After creating a project, you will need one or more tasks that show how the project will be completed.

1. Select the "New issue" button.
2. Select the Task template ("Get started" button).
3. Enter in a Title. Keep the [TASK] prefix.
4. Fill out as many of the details as you can. Comment other participants to add details as needed.
5. Under the Projects section on the right, select the Cog, and choose "Infrastructure Working Group" under NEAR.
6. Select "Submit new issue" button.
7. On the right, under projects, select the carrot to expand the options.
8. Leave the Status as Triage.
9. Choose the Area the task applies to.
10. Choose the primary Team responsible for the task.
11. Leave the Cycle blank.
12. Choose an appropriate Start and End date.
13. You can return to the project to add these tasks under the task list.

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 Defects

Things to consider when creating a Defect;

Creating 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.

Project & Tasks Workflow

Defect Workflow

Decision Workflow