The objective of this document is to outline a language and structured accounting logic for making and managing promises in order to effectively synchronise work across a distributed organisation and demonstrate to external customers that the organisation can keep our promises.

This language and accounting logic are designed to facilitate a cycle of task decomposition, promise-making & distribution of work, performance of work, re-composition, re-evaluation, re-planning, and subsequent repetition in a dynamic, distributed organisational environment with complex interdependencies between tasks, requirements that change as constraints are discovered, and interplay between research and engineering.

They are also designed to aid individuals and teams working at different levels of abstraction in a project to understand their individual priorities, surface how those priorities relate to the whole picture, and visualize progress at different levels of abstraction.

This language and structured accounting logic are tentatively called "Promise Graph", and often referred to in this set of documents simply as "the system". In the context of this document, "the system" should be understood as meaning exactly "the language and structured accounting logic".

Promise Graph builds on prior art, particularly the Collaborative Web of Galois and Informal Systems' Workflow, and bears some conceptual similarity to Promise Theory and multi-agent coordination.

Next, see design requirements.

Design requirements

This system must:

  • facilitate credible promise-making,
  • allow for causal dependence tracking,
  • use scale-invariant language and concepts,
  • be medium-agnostic,
  • allow for progressive structuring of data, and
  • enable progress visualization.

Let’s break each of these down in turn:

Credible promise-making

In order to collaborate effectively, we must break down work into smaller chunks, split up the chunks, work on them independently, then recombine them after completion. To help people coordinate across different timezones, we need to communicate to each other how long it will take to accomplish each chunk, and keep our overall estimates up to date as our task-specific estimates change.

The central aim of this system is to allow us to make credible promises with task definitions and deadlines, internally decompose (split up) and track progress of tasks, keep other parts of the organisation informed about any changes in deadlines, and discover our prediction error margins over time so that we can build resilience into work planning.

Causal dependence tracking

Our work frequently has complex interdependencies, not only in terms of implementation requirements but also in terms of decision-making: often we can’t decide some Y until we have decided some X upon which certain considerations for Y depend. This system should allow us to identify and continuously refine these dependencies and thereby identify which central items must be resolved first and prioritise them.

Scale-invariant

This system should use language and concepts independent of scale, which will save us time and complexity when changing the specific parameters, as we are likely to do.

Medium-agnostic

This system should define a syntax and semantics for promise-making and causal dependence tracking that is not tied to a particular medium, such that the medium could easily be changed in the future.

Note: medium-agnostic does not mean that you should be using different mediums at once - it just means that we should be able to define the system without reference to a particular medium and easily change mediums in the future should we decide to.

Progressive structuring

This system should be compatible with the maxim of “centralize first, organize later”, and allow for easy entry of data (e.g. not requiring many complex form fields) which can be organized later (and possibly by a third party).

Progress visualization

This system should provide the requisite data to visualize progress - how are we doing, relative to our higher-level goals - at all relevant layers of abstraction (so, all the way from the individual to the whole project).

Next, see conceptual structure.

Conceptual structure

Basic concepts

This system is based around three basic concepts for work, time, and contributors:

  • A task is a defined unit of work.
  • A period is a defined unit of time.
  • A team is a defined subset of contributors.

These three concepts are all scale-invariant:

  • All units of work that we will track are tasks.
  • All units of time that we will track are periods.
  • All subsets of contributors that we will track are teams.

Specific instances of each concept all have some scale-like dimension:

  • Tasks range from high-level ("release Anoma specs") to low-level ("write a Juvix example of the Collatz conjecture").
  • Periods range from long (quarter/year) to short (hour/day).
  • Teams range from large ("research department") to small ("Christopher").

Specific instances of each concept may be composed of sub-instances:

  • A specific task may be composed of sub-tasks, which can also be understood as dependencies.
  • A specific period may be composed of sub-periods (e.g. day composed of eight hours).
  • A specific team may be composed of a partially ordered set of sub-teams. The first element in this set is the team lead.

Eventually, any decomposition must result in an atomic instance (where what counts as "atomic" is subject to agreement between the customer and performer):

  • An atomic task could be "write a Collatz conjecture example in Juvix".
  • An atomic period could be "1 day".
  • An atomic team could be "Christopher".

Additional definitions:

  • A date is a defined point in time. Adding a period to a date results in another date.
  • A cycle is a numbered instance of a specific period.

Next, see Customers, perfomers, and teams.

Customers, performers, and teams

Each task corresponds to a relationship between two parties (may be an individual and a team, two different teams, or two individuals within the same team) within the organization:

  • The customer is responsible for defining the task clearly, so that the performer knows what to do, and checking that it has been completed by the agreed-upon deadline.
  • The performer is responsible for doing the work required to complete the task, satisfying the customer's requirements, and communicating any changes in details or completion time.

Teams all have a single designated lead (an individual). The team lead is the performer for team-level tasks and the customer for all tasks contained within their team (which are sub-tasks of those team-level tasks). Team leads are also responsible for serving as a discovery mechanism for other teams and individuals to discover which members of their team they should talk to / ask for help on a particular task or question. Cross-team communications do not need to go through team leads - but team leads are a good first person to ask.

Team members are responsible for doing the work they have agreed to do as performers in the team. Team members may be performers for tasks outside their team, and may be customers for tasks both inside and outside their team, but usually most of their tasks will come from planning conducted by and with their team lead. Team members are responsible for declining requests for work from others outside their team if it would endanger their ability to deliver on previously agreed-upon deadlines.

Teams as a whole are responsible for crafting good social structure, checking in with each other, pairing, sharing knowledge, etc. in ways not explicitly tracked by this system. Teams may negotiate within themselves and with their lead to define more specific responsibilities in these areas.

Next, see task states.

Task states

Tasks exist in 8 states:

  • Unplanned
  • In Planning
  • Planned
  • In Progress
  • In Review
  • Done
  • Cancelled
  • Superseded

These states are used as following:

  1. Any newly created task is Unplanned. A newly created task need only have a definition of completion. It MAY have a customer.
  2. When the customer starts planning a task, they mark it In Planning.
  3. When the customer and performer complete the planning process, the task moves to Planned. These tasks MUST have:
    • A customer (a specific team)
    • A performer (a specific team)
    • An deadline by which the performer promises to complete the task.
    • For tasks with an individual as the performer, an estimated duration of work required in addition to work on any dependencies.
  4. When the performer starts actually working on the task, they move it to In Progress.
  5. When the performer thinks that they have completed the task, they move it to In Review.
  6. The customer then reviews the task. If the task is in fact done, they move the task to Done. If the task is not in fact done, the task moves back to In Planning, and the customer and performer replan it in order to figure out where their understandings differed.
  7. At any point in time, if the customer decides that the task no longer needs to be done, they move it to Cancelled.
  8. At any point in time, if the customer plans a task for which the definition of done entails that this task is also done, but for which this task is not a dependency, they must move it to Superseded.

Note: The customer and performer may sometimes be the same team or person, but they should understand themselves as playing the two roles at different times. In an organization with many teams and individuals, they will usually be different teams.

In a diagram, this state flow looks as following:

flowchart TD
   Unplanned
   InPlanning["In Planning"]
   Planned
   InProgress["In Progress"]
   InReview["In Review"]
   Done
   Cancelled
   Superseded
   AnyState["Any State"]
   Unplanned -->|Customer starts planning| InPlanning
   InPlanning -->|Customer & performer complete planning| Planned
   Planned -->|Performer starts task| InProgress
   InProgress -->|Performer finishes task| InReview
   InReview -->|Customer reviews & approves| Done
   InReview -->|Task not in fact complete| InPlanning
   AnyState -->|Customer decides to cancel task| Cancelled
   AnyState -->|Customer plans superseding task| Superseded
   style Unplanned color:green;
   style InPlanning color:#8B8000;
   style Planned color:orange;
   style InProgress color:red;
   style InReview color:purple;
   style Done color:blue;
   style Cancelled color:black;
   style Superseded color:black;

Next, see Task properties.

Task properties

Reified as a data structure, a task must consist of, at minimum, four properties:

  • identifier, a unique string identifying the task
  • state, the task state, by default Unplanned
  • title, a few word overview to aid readers
  • definition of done, the definition of what must be done to complete the task

Tasks may additionally possess the following properties:

  • dependencies, a set of identifiers of the tasks on which this task depends
  • supersedes, a set of identifiers of tasks which this task supersedes
  • customer, a team
  • performer, a team
  • deadline, a date by which the performer has agreed to complete the task
  • estimated, the duration of work estimated by the performer
  • started, a date when work was begun by the performer
  • actual, the duration of work actually required by the performer
  • completed, a date when work was completed by the performer
  • confirmed, a date when work was confirmed complete by the customer
  • tags, a set of arbitrary strings which can be used for topical organization
  • comments, a map of comment objects, where each key is an identifier and each value is a comment object containing the fields:
    • author, a team
    • date, a timestamp
    • body, a Markdown document

Durations are specified in terms of whole-number hours, days, weeks, or months. Mixed precisions are not allowed on purpose - we don't want to imply more precision than accuracy.

Tasks in the state Planned (or later) must possess at least the properties:

  • dependencies
  • customer
  • performer
  • deadline
  • estimated

Tasks in the state In Progress (or later) must additionally possess:

  • started

Tasks in the state In Review (or later) must additionally possess:

  • actual
  • completed

Tasks in the state Done must additionally possess:

  • confirmed

Next, see Accountability.

Accountability

In this conceptual structure, after planning, the performer makes a promise to the customer, with a well-defined scope, duration, and deliverable results of work. The performer is responsible for keeping this promise (for which they may rely in turn on promises made to them). It should be clear to both the customer and performer whether or not this promise has been kept. If the performer does not keep this promise, and especially if they do not keep similar promises repeatedly, the customer may decide not to ask them to do this work again, to change the composition of the team, etc.

A promise not being kept is not assumed to be a personal failing — it could be the result of sub-optimal matching, communications problems, sub-promises not being kept, etc. — but from the perspective of coordination, promises not being kept indicates that some kind of restructuring must take place in order to restore functionality.

Next, see Operational structure.

Operational structure

Operationally, this system consists of the following basic actions:

Creation

Creation of a task requires only a definition of done and a title.

A definition of done means necessary and sufficient criteria which must be met in order for the task to be completed.

A title is simply a short string to inform a reader roughly what the task is about.

Optionally, tasks may be created with an initial customer. If many tasks are created without initial customers, someone must have a periodic meta-task to scan through created but unplanned tasks (the "backlog") and assign them customers.

Tasks may also optionally be created with:

  • an initial set of dependencies
  • a set of tasks which this task supersedes. A task supersedes another task if and only if the definition of done for this task is a superset of the definition of done for the task superseded.

Created tasks start with a state of Unplanned.

Next, see planning.

Planning

Planning always happens in relation to a particular period, a particular task, and a particular team. Planning is initiated and led by the customer of the task in question, who must already have an idea of the task and a target deadline in mind. The customer in question, by conducting the planning process, can be understood as asking:

"Can this task be accomplished in this period with this team, and if so, how?"

The goal of the planning process is to answer this question.

Planning - parts of which are typically done synchronously by the customer and performer(s) - proceeds as follows:

  1. The customer decides to start planning the task, at which point they immediately mark it In Planning.

  2. Review the last planning conducted for this task, if applicable, and agree on any retrospective reflections / conclusions.

  3. If the customer and performer agree that the task is sufficiently well-defined and that the deadline is achievable:

    1. The task is marked as Planned, with the performer and estimated date of completion added.
    2. Planning terminates.

  4. If the customer and performer agree that the task is sufficiently well-defined, but the performer thinks that the deadline is not achievable, planning fails (and can be restarted with a different task and/or different deadline).

  5. Otherwise, the customer leads threefold decomposition, with the help of the performer as necessary:

    1. Decomposition of the task in question into sub-tasks.
    2. Decomposition of the team in question into sub-teams.
    3. Decomposition of the period in question into sub-periods.

    The task, team, and period do not always need to be simultaneously decomposed; often it will make sense to first decompose the task, for example.

  6. Planning then recurs for each of these sub-tasks, sub-teams, and sub-periods. This can result in two outcomes:

    1. Success, in which case the sub-task dependencies, appropriate performer, and estimate are added to the original task, and planning terminates.
    2. Failure, in which case the customer can choose whether to give up (planning fails) or try with a different decomposition (back to step 4).

Planning, in general, proceeds "right-to-left" on a task DAG, starting with a higher-level task and building up the dependency graph which must be completed in order to complete it.

Next, see starting.

Starting

When a performer starts work on a task, the started property should be set to the current date, and the task state should be set to In Progress.

Next, see completing.

Completing

When they think a task is complete, a performer marks it as In Review, which notifies the customer. If the performer is an individual and the task had an hour estimate, they should also mark how many hours it actually took in the actual property (this will help us improve our estimates).

Next, see confirming.

Confirming

Completing a task requires confirmation of the customer. When a task is marked completed by the performer, the customer reviews the task and delivered artefacts and either:

  • If they think the task is complete, marks it as Done.
  • Otherwise, the task goes back to In Planning and the customer and performer re-plan.

Completion, in general, proceeds "left-to-right" on a task DAG - as smaller tasks are completed, larger tasks upon which they depend may be as well - but all tasks must be explicitly marked complete and explicitly confirmed.

Next, see renegotiating.

Renegotiating

Renegotiating happens when a performer discovers in the process of executing a task that the requirements were not in fact clearly specified or that the deadline is no longer achievable. In order to enter renegotiation, a performer must notify the customer, after which they both re-enter planning for the task in question.

If a performer no longer expects to complete a task by the deadline, or is no longer sure what completion means, they MUST enter renegotiation - this is what keeps the system in sync with reality.

Next, see viewing.

Viewing

Viewing tasks can be accomplished in whatever way is most straightforward given the database system - perhaps filtering by customer/performer, sorting by deadline, etc.

Usage guide

What makes a good task?

A good task includes:

  • A necessary and sufficient definition of what needs to be done (the "definition of done"). How detailed this needs to be is subject to the negotiation between the customer and the performer - the performer should only agree if the task is sufficiently clearly defined that they know how to decompose it into sub-tasks themselves, and if they are confident that they can complete all required sub-tasks before the agreed-upon deadline.
  • Links to all relevant resources (always prefer linking to copying data - DRY).

Planning cadences

Used consistently, this system should be less dependent on fixed planning cadences than our current cycle system because (a) tasks always exist that can be picked up and (b) renegotiation explicitly triggers re-planning. Still, specific repeated cadences will probably be helpful - I propose a "strategic planning cadence" every 6 weeks and a "tactical planning cadence" every 2 weeks.

Strategic planning

Every 6 weeks, the chief customer (project lead) and relevant parties meet to define and plan top-level tasks for the next 6 week strategic cycle. This should result in at least 6 weeks of planned work (and possibly more unplanned to-dos for the future).

Strategic planning proceeds "right-to-left" on the task DAG:

  1. First, the chief customer defines the top-level task(s). (these may also relate to planning cycles longer than 6 weeks).
  2. Second, the chief customer and relevant parties plan those tasks following the procedure above, until the period, the team, and the task(s) have been decomposed into:
    1. Three sub-periods of two weeks each
    2. Sub-teams
    3. Sub-tasks, each of which is assigned to one of the sub-teams as performer, and whose deadlines should generally fall on the sub-period boundaries. This may involve sub-planning within the sub-teams. At the end, when all customers and performers consent, this task graph becomes the work plan for the next 6-week period.

Tactical planning

Every 2 weeks, the chief customer (project lead) and relevant parties meet to check in on progress relative to the strategic planning cycle top-level tasks and plan / re-plan tasks for the next 2 week tactical cycle. Typically, these tasks should have already been planned, and this can just be a quick check-in - but it's also a good opportunity to check that progress is on track w.r.t. the strategic goals, and reconsider / re-plan if other factors have changed.

Tactical planning proceeds both left-to-right and right-to-left. Considering what tasks have been completed, the chief customer and sub-team leads may decide to re-plan, rearrange, or re-scope remaining tasks within the 6-week period (but should generally not change high level tasks agreed upon during the last strategic planning cycle).

Synchrony & asynchrony

Roughly, the organization operates in two modes:

  • Synchronous - e.g. when you're on a video/audio call or meeting in person, and can receive immediate feedback
  • Asynchronous - otherwise, when you can't receive immediate feedback

Any promises made that will not be completed while both the customer and performer are in a synchronous session should be tracked by this system. For example:

  • If you are asking a teammate to pair review your code on a call, and you will finish the review on the call, this does not need to be tracked.
  • If you are asking a teammate to review your code, and you give them an intro on the call but expect them to finish later, this does need to be tracked.

In general, anything that you agree to do is a task. If there isn't a task, don't agree to it.

Granularity of time tracking

The goal of this system is to provide high estimation accuracy for planning across the organisation. In order to do this, we need estimated time vs actual time taken to be tracked when relevant. This is most important with larger tasks that take on the order of days, it's not so important with small stuff - if a 20 minute task takes 40 minutes, that's not a big risk to organisational prediction accuracy, but if a 2 week task takes 6 weeks, that is. As a reasonable rule of thumb, say:

  • Tasks that you expect to take 1 day or more should come with a time estimate, and
  • When you complete a task with a time estimate, you should note how much time it actually took

Self-reference

This system can reference itself, e.g. "Plan task XYZ" is also a task.

FAQ

Intra-team and inter-team priority conflicts

Q: Imagine a situation when an outside-of-team task was proposed, and you, as a potential performer, perceive it as having higher importance than your current team-task. In the situations when confirming with the lead (I assume that would be a natural thing to do) is not possible (e.g. there is a hard deadline happening too soon - “can you do this in the next two hours?”), what is the best thing to do? On the one hand, taking this task (or in the edge case, multiple tasks) will affect your performance of your planned tasks (instead of working on planned X, I had to spend the day working on Y because it seemed like an emergency) and it might not be aligned with the view of the team lead that you couldn’t have learned in time (e.g., because of the timezones). On the other hand, blindly declining all such tasks doesn’t work well in case of emergencies, and even though emergencies in our context don’t happen that often it feels like a good idea to have a plan for when it happens.

A: It’s hard to give a universally applicable rule for this situation - it’s up to your judgement and what you’ve agreed with the team lead. It also has a lot to do with how frequently this happens - if this happens once a month or so, doesn’t seem like too big a deal to handle case-by-case (e.g., if the new task seems to be very important, just do it), but if this is happening multiple times a week or such it’s a clear indication that the division of teams & tasks is probably wrong, and you should raise this to your team lead (or the project lead).

Deadline incentive concerns

Q: Another imaginary situation: a customer sets a hard deadline that cannot be achieved (for simplicity, for reasons that are not related to the immediate performer). One potential performer is aware of that and communicates it to the customer, the other is not and accepts the task. Repeated multiple times (not necessarily too many), it might create a situation when performers are incentivised to agree on unrealistic deadlines just to, well, have any tasks to perform (performer #2 might not complete tasks in time, but performer #1 doesn’t take them, which might be perceived as a worse thing). How to get out of such loop?

A: The customer is also responsible for delivering, they are most likely performer for a higher-level task - so it’s in their interest to find performers who make realistic time estimates and keep them. This system does rely on customers being reasonable and consistent, but if they aren’t no system will fix that.

Project lead customership

Q: Does the project lead have to be the customer of all tasks? For example, if we have a sub-team Y within a team X, does sub-team Y also have a team lead or will this be the same lead as team X? And who will be the customer? Put differently, do all tasks completed by a team need to be approved by the team lead?

A: No, the project lead will only be the customer for top-level tasks, generally (though project lead is a role more than a person, the person could also play other roles). Teams can determine sub-team compositions and sub-team leadership within themselves freely - the team lead should be the customer for all top-level team tasks (so sub-team-leads would perhaps be the performer for mid-level team tasks in some category or such) - so, effectively, the team lead does need to be the ultimate customer for all tasks within the team, but they can delegate arbitrarily large sub-tasks of those to sub-team leads if they want. Does that make sense (and answer your question)?

Here is a diagram for clarity:

example-diagram

Usage with Github

Task representation

Tasks are represented by GitHub issues in a 1:1 correspondence.

This overall format is chosen to strike a reasonable balance of parser friendliness and human-readability.

Native properties

  • identifier is represented by the global GraphQL node ID (not the issue number, which is not unique across repositories - see e.g. the GitHub GraphQL docs for details).
  • state is represented by the Status field in the Github project board (for which automation may be set up to e.g. change the status when someone closes the issue).
  • title is represented by the issue title.
  • confirmed is represented by the closedAt field in the issue.
  • tags are represented by issue labels.

Other properties

Other properties and the definition of done are represented in the issue body, which must be formatted as follows (for example):

customer: @cwgoes
performer: @degregat
deadline: 2023-10-10
estimated: 4 hours
started: 2023-10-08
actual: 3 hours
completed: 2023-10-09
confirmed: null
dependencies:
- [ ] <task 1>
- [ ] <task 2>
- [ ] <...>
supersedes:
- <task 20>
---

< definition of done >

Properties are written at the top, in simple YAML syntax, and the definition of done is written in arbitrary text (Markdown formatted) at the bottom of the body. The property section and definition of done MUST be separated by '---' (triple dash). Properties which are not set MUST be set to null. All properties MUST be included.

Dependencies MUST be added with GitHub task syntax, e.g. - [ ] (issue link), such that they are annotated with dependency relationships in GitHub's database.

All date properties (deadline, started, completed) MUST be formatted as 'YYYY-MM-DD' (ISO 8601).

Duration properties (estimated and actual) MUST be specified in hours, days, weeks, or months, with a number prepended, e.g.:

  • 4 hours
  • 2 days
  • 1 week
  • 3 months

Durations MUST use a single level of precision, e.g 2 days, 4 hours is NOT a valid duration. This limitation is intentional, as we do not want to spend time negotiating time tracking minutea.

We permit a few slight deviations from normal YAML syntax:

  • Customer and performer may be specified using '@username' ('@' is not usually allowed by YAML parsers without quoting), e.g. '@cwgoes'.
  • '[ ]' and URLs are allowed in the list of dependencies (not usually allowed by YAML parsers without quoting).

Derived GitHub fields

The assignees field of GitHub issues MUST be set to the union of all customers and performers of the associated task.

Comments

Comments on the issues are synchronized with comments tracked in the task. The bot does not presently track edit history (just the current version).

Task actions

Creating

Tasks can be created by:

  • creating an issue following the issue templates
  • adding the issue to the canonical project board

Planning

Task planning is conducted manually by the customer and performer.

As soon as you start planning, set the state (project board status) to In Planning.

At the end of planning, mandatory properties must be included as described in the task properties section.

When you are done planning, set the state (project board status) to Planned.

Starting

To start a task, comment on the issue with:

@promisegraph start

[comment]

The comment is optional and can be arbitrary Markdown.

Upon receiving this command, the bot will:

  • set the property started to the current date
  • set the state (project board status) to In Progress

Completing

To complete a task, comment on the issue with:

@promisegraph complete [actual-time]

[comment]

The comment is optional and can be arbitrary Markdown.

The [actual-time] parameter is mandatory if the performer is an individual, and optional otherwise.

Upon receiving this command, the bot will:

  • set the property completed to the current date
  • set the property actual to the [actual-time] parameter
  • set the state (project board status) to In Review

Confirming

To confirm a task which has in fact been completed, comment on the issue with:

@promisegraph confirm

[review]

The review is optional and can be arbitrary Markdown.

Upon receiving this command, the bot will:

  • set the property confirmed to the current date
  • set the state (project board status) to Done
  • close the issue as completed

Rejecting

To reject a task which has not in fact been completed, comment on the issue with:

@promisegraph reject

[reason]

The reason is mandatory and can be arbitrary Markdown.

Upon receiving this command, the bot will:

  • set the state (project board status) to In Planning

The task must then be replanned by the customer and performer.

Cancelling

To cancel a task, comment on the issue with:

@promisegraph cancel

[reason]

The reason is mandatory and can be arbitrary Markdown.

Upon receiving this command, the bot will:

  • set the state (project board status) to Cancelled
  • close the issue as not planned

Renegotiating

To renegotiate a task, comment on the issue with:

@promisegraph renegotiate

[reason]

The reason is mandatory and can be arbitrary Markdown.

Upon receiving this command, the bot will:

  • set the state (project board status) to In Planning

The task must then be replanned by the customer and performer.

Project boards & repositories

There is one canonical project board: Anoma.

The following repositories are tracked:

In general, issues can live in any repository. Tasks that do not fit in an existing repository MUST be created as issues on the canonical meta repository.

The promise graph bot pulls all issues from:

  • the canonical project board
  • the tracked repositories
  • dependencies of the above, recursively

All issues are automatically added to the canonical project board.

The following fields on the project board are automatically synchronized:

  • Status (synchronized with task state)
  • Cycle (synchronized with task deadline)

Issues inaccessible to the crawler are treated as external dependencies as follows:

  • issues which the crawler can read but not write are parsed as much as possible
  • issues which the crawler can neither read nor write are treated as opaque links

Issue templates

The canonical issue template is:

---
name: Task
about: Template for Promise Graph tasks
title:
labels:
assignees:
---
customer:
performer:
deadline:
estimated:
started:
actual:
completed:
confirmed:
---

<definition of done>

In order to activate this template for your repository, add this Markdown as a file at:

.github/ISSUE_TEMPLATE/issue_template.md

(with respect to the repository root)