It was a placeholder for labels added via NIP-32 so that they could be assigned by the author, maintainer(s) or potentially others after the issue has been created.

Reply to this note

Please Login to reply.

Discussion

It shouldn't take much to add the feature but its never made it to the top of the todo pile. PRs welcome but hopefully I'll get to it soon.

Thank you, I see. I just wanted to make sure to use the same standard as you and I thought self labelling was supported on your site.

What about the header/subject of an issue? Usually it's "subject", but what does gitworkshop use?

The first line of the content

There should be a solution to enable the author or repository maintainers to re title an issue or a PR. There also should be a standard to allow either an editable summary to be added or allow the content of the issue / PR cover letter to be edited. This could also enable the popular concept of a 'tracking issue'.

Perhaps a cover letter kind that includes the issue / PR id in the identifier tag could acts like a wiki article. git clients can elect to restrict versions displayed as they wish but just that of the author and maintainers would be sensible.

A other option would be to make either a breaking change or add an additional type of issue and root PR event.

I guess we need to not make it too complicated.

I'd be really interested I your thoughts and the thoughts of

nostr:nprofile1qqsdph4ln7cjmmup7s7hc62znwmcfqf2c8jd94f6yqkmd2k8af95vmqpz4mhxue69uhkummnw3ezummcw3ezuer9wchszythwden5te0dehhxarj9ekxzmny9uq3zamnwvaz7tmwdaehgu3wwa5kuef0e3c7n0 nostr:nprofile1qqsd6ejdteqpvse63ntf7qz6u9yqspp4z7ymt8094urzwm0x2ceaxxgprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qguwaehxw309a6xsetrd96xzer9dshxummnw3erztnrdakj7qgnwaehxw309ac82unsd3jhqct89ejhxtccyjmzy nostr:nprofile1qqs8qy3p9qnnhhq847d7wujl5hztcr7pg6rxhmpc63pkphztcmxp3wgpzemhxue69uhkwun9v4h8xmm4dsh8xurpvdjj7qgswaehxw309ahx7um5wghx6mmd9uq35amnwvaz7tmwdaehgu3ww35x2umpd4jkxct59e5k7tckquc5r nostr:nprofile1qqswqlnvzdg7qlyr0v07kmpkystnc6elz0jq6a0cun4ad8llquuur3cpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgjwaehxw309ac82unsd3jhqct89ejhxqgnwaehxw309aex2mrp09skymr99ehhyechnasg9 nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp and anyone else who wants to chime in.

Just a thought: maybe you could separate the metadata event from the human-readable descriptions and conversation.

The issue/cover letter event could reference other events needed to reconstruct an issue thread, including a PR description, references to code or commits, comments, etc.

This could use a model similar to the index events in nostr:nprofile1qqsdcnxssmxheed3sv4d7n7azggj3xyq6tr799dukrngfsq6emnhcpspzemhxue69uhkyetkduhxummnw3erztnrdakj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0uxxcg6's Nostr Knowledge Base spec.

Interesting. Where can I read about that spec?

Some of benefit of the current setup is the immutibility of code proposals for audit purposes, the simplicity and the minimal number of required events.

Take a look at Liminal's spec here: https://wikistr.com/nkbip-01*dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319

Perhaps things that should be immutable can stay in the proposal, while comments and other things that should be editable are referenced.

Thanks, I'll take a look tomorrow

Oo. What are you working on?

I just had another quick look at NIP-32 and I had thought of the github concept of 'labels' as hashtags (`t` tag) which can be added directly in the event or after the fact via NIP-32.