diff options
| -rw-r--r-- | 34.md | 3 |
1 files changed, 2 insertions, 1 deletions
| @@ -69,6 +69,8 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` | |||
| 69 | } | 69 | } |
| 70 | ``` | 70 | ``` |
| 71 | 71 | ||
| 72 | The first patch in a series MAY be a cover letter in the format produced by `git format-patch`. | ||
| 73 | |||
| 72 | ## Issues | 74 | ## Issues |
| 73 | 75 | ||
| 74 | Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. | 76 | Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. |
| @@ -108,5 +110,4 @@ Replies are also Markdown text. The difference is that they MUST be issued as re | |||
| 108 | 110 | ||
| 109 | - "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed) | 111 | - "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed) |
| 110 | - "branch merge" kind (specifying a URL from where to fetch the branch to be merged) | 112 | - "branch merge" kind (specifying a URL from where to fetch the branch to be merged) |
| 111 | - "cover letter" kind (to which multiple patches can refer and serve as a unifying layer to them) | ||
| 112 | - inline file comments kind (we probably need one for patches and a different one for merged files) | 113 | - inline file comments kind (we probably need one for patches and a different one for merged files) |