Community tracking of objectives & key results (OKRs)

[mistakia]

This pull request introduces the basic elements of a system for open planning of community-wide objectives and key results (OKRs) by laying out steps for discussing, finalizing, and tracking OKRs.

When no one is in charge, everyone is in charge. In order to facilitate this at a global scale, this pull request establishes standards and infrastructure to support the nano community operating as an asynchronous and distributed organization.

Community-wide objectives and key results are planned in the open by starting a new GitHub discussion. In these discussions, everyone can weigh in to help refine the objective and key results.

Objective

• describes what is to be achieved
• should be significant and inspirational

Key Results

• describes how it will be known it is achieved
• each objective should have 2-5 key results
• can be measured objectively
• should be challenging yet realistic

A well-formatted objective and key results can be easily and uniformly understood by anyone.

OKRs will be finalized through pull requests that update docs/OKRs.md. Once merged, repo maintainers may convert related GitHub discussions to GitHub issues (and/or create related sub-issues), that people can volunteer to take on. Issues related to finalized OKRs should be labeled YEAR/QUARTER.

[describe how OKRs are assigned]

Each individual should not take any more than two priority/critical items (unless they are quite small tasks).

OKR Lifecycle

1. Introduced via GitHub discussions
2. Finalized via git by updating docs/OKRs.md
3. Specific issues & pull requests are created to track tasks related to finalized OKRs
4. Issues are assigned to volunteers
5. Reviewed and graded quarterly

OKR Quarterly Grading & Review

• 0.0 – 0.3 — failed to make real progress
• 0.4 – 0.6 — made progress but fell short of completion
• 0.7 – 1.0 — delivered

Issue & Discussion Label Management An issue should be opened for anything specific, while discussions should be used for anything broad. All new issues & discussions will be labeled need/triage. Repo maintainers will ensure each issue & discussion has a priority, kind, and need label before removing the need/triage label.

Labels

Why git and GitHub

• Version control
• Public API (easy access and distribution)
• Easily forked

PR Todo

• [x] create labels
• [x] script to mange triage label
• [x] update docs/contributing.md

[npesc]

Proposition for objective characteristics:

• Specific: Objective description must be clear. Description must include what is expected, what will be done, where and by whom. Anyone reading the description can understand.
• Time-bound: Objective must have a timeline/deadline.
• Measurable: Objective's progress must be quantifiable. Description must state what will be the means used to measure/quantify the progress.
• Verifiable: Once the deadline is reached it should be possible to determine whether the objective has been achieved or not.

[mistakia]

Following up with a simple and concise format to describe OKRs as well as a standard 0-1 grading scale.

Objective

• describes what is to be achieved
• should be significant and inspirational

Key Results

• describes how it will be known it is achieved
• each objective should have 2-5 key results
• can be measured objectively
• should be challenging yet realistic

A well-formatted objective and its key results can be easily and uniformly understood by anyone.

OKR Quarterly Grading & Review

• 0.0 – 0.3 — failed to make real progress
• 0.4 – 0.6 — made progress but fell short of completion
• 0.7 – 1.0 — delivered

[mistakia]

@npesc thoughts on displaying OKRs and related tracker issues on the roadmap page (https://nano.community/design/roadmap)?

[npesc]

@npesc thoughts on displaying OKRs and related tracker issues on the roadmap page (https://nano.community/design/roadmap)?

@mistakia Makes sense. However we should mention that OKRs and issues are community driven since it's one of the community program's objectives. Perhaps renaming the page to something like "Upcoming" with it having two main subsections "Roadmap" and "Community objectives" can help nuance the ideas.

[mistakia]

This PR is ready for an initial review and has the basic functionality needed for an initial release, even in its incomplete form it is more useful than the existing placeholder "roadmap" page.

Follow-up / Remaining Tasks

• [ ] Determine how OKRs are assigned
• [ ] Determine how proposed OKRs are finalized and adopted
• [ ] Determine who grades & reviews previously finalized OKRs
• [ ] Add a section for guidelines on proposing OKRS to CONTRIBUTING.md

Release Tasks

• [ ] Finalize initial set of labels (reach out to community for feedback)
• [x] Create new labels on github & remove "old" labels
• [x] Apply labels to existing issues & discussions
• [x] Setup cron job for importing discussions
• [x] Setup cron job for importing issues
• [ ] Review and update existing discussion title and bodies (e.g. Dashboard / Homepage should be updated to a clear and concise objective)

Some half-baked thoughts on how proposed objectives could be finalized and adopted: For the purpose of an open system of categorizing/labeling community posts (reddit, discord, forum, etc), I've been toying with the idea of nano-linked accounts. It's a public-private key pair signed by the private key of an existing nano account. The signing would ideally happen directly in wallets people are already using (nault, natrium) so no additional exposure of the private key is created. This signed public-private key pair could be loaded into nano.community for the purpose of signing user actions like voting for (or against) a label for a certain post. These signed actions along with the linked nano account data (balance, age, etc) could be used to make display decisions. The idea is that the collective financial incentive to act in the best interest of their holdings will provide moderation of an open system.

A similar approach could be used to allow community members to sign a vote for a proposed objective (and sign an amount to pledge to those who contribute to its completion). These votes can then be used to adopt proposed objectives.

Being that nano-linked accounts could be a blocker of other features, I'm going to shift some of my focus on a basic initial design to build & trial.