Skip to content

Projects & Tasks

Trentin C Bergeron edited this page Jun 7, 2024 · 7 revisions

Introduction

The following outlines the process and procedures for using the repo and project: 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 according to the Project Team's desired work cadence. This is important so Tasks can be prioritized for the current workstream compared to future workstreams.
  • Issue = Do not confuse it 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 organize its effort into logical subjects. Examples of categories are indexers, validators, nodes, databases, APIs, relayers, and explorers.
  • Team = For a Project Team encompassing multiple organizational or community teams. Allows projects and tasks to be categorized by the team most responsible for the work.

Basic Structure/Issue Types

Important Labels are provided on Issues to designate the Issue Type below. These are vital to organizing tabs on the GitHub project.

  • 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 reasonably achievable projects.'
  • Committee Project = Similar to a project, except the initiative is focused on the committee or is work to be completed by the committee.
  • Maintenance Project = A completed Project that is now in regular maintenance.
  • Task = an item that tracks one "thing that needs to be done" to complete the project.
  • 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. Sometimes, it might result in a narrower or more focused Decision. In other cases it might simply result in deciding not to move forward.
  • 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 regularly " prune" 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 currently being worked on.
  5. 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.
  6. Done = Work on this task or project is complete.

Workflow

  1. A Project is submitted (with Project status) with all pertinent details to accomplish the Project.
  2. Tasks are submitted in Triage status and linked under that Project with a Task List outlining the specific steps required to accomplish the Project.
  3. The Working Group, Committee, and each specific project team plan what Projects and Tasks are the highest priority for the current Cycle.
  4. Tasks are Triaged to determine complexity, severity, and priority. If they are moved to selected status, they will be completed in the current cycle. They will be picked up in a future cycle if they are set to Backlog status.
  5. Participants from partners and ecosystem devs should be added to the repo and Github Project so they can be assigned tasks and keep everyone apprised of their progress.
  6. Project teams should report on any changes, blockers, and finished tasks by setting the appropriate status and commenting on Tasks.
  7. Project teams should include dates on both Projects and Tasks. These can be the best estimates. Teams should update dates when delays or changes occur. Updating dates before the original deadline is a best practice.

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] prefix.
  4. Fill out as many details as possible. Call out other participants to add more details if needed.
  5. select the task list button in the toolbar under Task List. 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 correct Area the project will cover.
  9. Enter the primary Team for the project.
  10. Leave the cycle blank for now.
  11. Leave the Status as Triage.
  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 those tasks.
  14. Use the search under the task list to find and select child tasks. The correct label is automatically added when using the templates provided under New Issue.

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?
  • Can details, requirements, and/or specifications 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 the "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. Enter 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 to the task list. The correct label is automatically added when using the templates provided under New Issue.

Things to consider when creating a task;

  • Are any other dependencies or tasks required before this task can be started?
  • Is this task a reasonable effort within the specified time?
  • 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

Errors may arise after something is completed (released to production). These errors should be submitted as Defects.

  1. Select the "New issue" button.
  2. Select the Defect template ("Get started" button).
  3. Enter in a Title. Keep the [DEFECT] prefix.
  4. Be sure that all areas are defined, including steps to reproduce.
  5. Be sure to include what you expected!
  6. Under the Projects section on the right, select the Cog, and choose "Infrastructure Working Group" under NEAR.
  7. Select the "Submit new issue" button.
  8. On the right, under projects, select the carrot to expand the options.
  9. Leave the Status as Triage.
  10. Choose the Area the task applies to.
  11. Enter the primary Team responsible for the task.
  12. Leave the Cycle blank.
  13. Choose an appropriate Start and End date.
  14. If applicable, return to the affected Project and add it to the Task List. The correct label is automatically added when using the templates provided under New Issue.

Things to consider when creating a Defect;

  • Be as precise as possible.
  • Include steps to reproduce! This is very important in diagnosing the defect.
  • Include error logs or stack traces.
  • Include screenshots.
  • Include information that may be hidden or obscure.
  • Consider who will read it and ensure your description is easy to follow.

Creating Decisions

  1. Select the "New issue" button.
  2. Select the Decision template ("Get started" button).
  3. Enter in a Title. Keep the [DECISION] prefix.
  4. Verify that all areas are defined.
  5. Under the Projects section on the right, select the Cog, and choose "Infrastructure Working Group" under NEAR.
  6. Select the "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. Enter the primary Team responsible for the task.
  11. Leave the Cycle blank.
  12. Choose an appropriate Start and End date. The correct label is automatically added when using the templates provided under New Issue.

Things to consider when creating a decision;

  • Is the summary clear enough to make a solid decision? Is it one decision, or must it 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.

Creating Feature Requests

  1. Select the "New issue" button.
  2. Select the Feature Request template ("Get started" button).
  3. Enter in a Title. Keep the [FEATURE REQUEST] prefix.
  4. Verify that all areas are defined.
  5. Under the Projects section on the right, select the Cog, and choose "Infrastructure Working Group" under NEAR.
  6. Select the "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. Enter the primary Team responsible for the task.
  11. Leave the Cycle blank.
  12. Leave start and end dates blank. The correct label is automatically added when using the templates provided under New Issue.

Things to consider when creating a Feature Request;

  • Is this Feature Request related to a problem or other Defect? Consider linking it in this request.
  • Try to provide as many details on the solution as possible. Feel free to write out a specification or requirements or provide wireframes in another app and link them in this request.
  • Have you considered alternatives? Please provide in that section.
  • Provide additional details you feel would be helpful.

Project Workflow

  1. The Project is created on the GitHub repo.

Task Workflow

Defect Workflow

Decision Workflow