Kind 31971
| RFC 2119 | Description | Spec or Example |
|---|---|---|
| MUST | Identifier | ["d", <random 256bit hex>] |
| MUST | One sentence describing the problem, used as the title in clients | ["tldr", <up to 140 character description of the problem>] |
| SHOULD | One paragraph describing the problem | ["para", <up to 560 charactars summarizing the problem>] |
| OPTIONAL | One page describing the problem, MAY include markdown | ["page", <extended description of the problem>] |
| SHOULD | The parent(s) of this problem | ["a", 31971:<pubkey>:<256bit hex>, "parent"] |
| OPTIONAL | Rockets that this applies to | ["a", 31108:<pubkey>:<rocket name>] |
| SHOULD | Lifecycle status | ["status", "<draft | rfm | big | children | open | claimed | patched | closed">] |
| OPTIONAL | Claim data | ["claim", <pubkey claiming it>:<bitcoin height when claimed>] |
| SHOULD | Child status upon creation | ["child_status", <rfm | open >] |
| OPTIONAL | repository | ["repo", 30617:<pubkey>:<d-tag>] |
| OPTIONAL | required skill, language, etc | ["skill", "golang"] ["skill", "docker"] |
| OPTIONAL | references to other problems | ["a", 31971:<pubkey>:<256bit hex>, "mention"] |
| SHOULD | Pubkeys of maintainers, add a new tag for each, clients SHOULD copy the parent's list to begin with | ["maintainer", <pubkey>] |
| SHOULD | Current block when publishing, mostly for convenience. | [ "bitcoin", "<current bitcoin height>:<hash>" ] |
Events published by maintainers and using the same d tag are considered as replacements (by the client, not relays) if they are newer.
Clients get maintainer lists from the event itself, if none are specified then they use the parent event list, the tagged rocket(s), tagged NIP34 repo, etc.
Problems are intended to go through a specific lifecycle.
Problems begin as open. Problems that can be solved in something like 6 hours of work or less can be claimed and solved. To claim a problem, a participant MUST publish a kind 1 event in reply to the problem, with the tag ["claim"]. Maintainers SHOULD then update the status of the problem to claimed and include the claim tag indicating which pubkey claimed it and when.
Maintainers themselves can claim a problem by simply updating the claim tag without publishing an extra events (but maybe they should anyway as a courtesy).
The reason problems should be claimed before working on them is to prevent duplicate work.
If the person who claimed a problem does not send a pull request or some other solution and is not responsive for a period of greater than 144 blocks, maintainers should revert the problem back to the open status so that it can be claimed by someone else.
When the person who claimed a problem has created a patch or other solution they should reply to the event with a kind 1 note explaining the solution or linking to a pull request etc, and include the tag patched.
If a problem looks to be bigger or more complicated than something that can be solved in less than 6 hours of working time, maintainers should set the status to big needs children because it's too big.
If a problem has open children maintainers should set the status to children.
| Status | Valid Next States | Notes |
|---|---|---|
open |
children claimed patched closed |
|
children |
open |
Only once all children are closed |
big |
children |
|
claimed |
open patched closed |
|
patched |
open claimed closed |
|
closed |
open |
re-opening a closed problem |