Subnostr

If the original maintainers are not interested in receiving patches/issues through nostr, the solution is for that someone to create their own fork and use the fork in the "ngit init" event.

Then they can receive patches on their fork and submit Github PRs from their fork to the original repo.

I see this the same way as if the maintiner does not want to package their software for platform X, so a motivated person Y maintains their downstream fork that supports platform X. Downstream forks are very common.

DanConwayDev 1y ago

I'm not sure how effective that would be. The costs of maintaining a fork are quite high.

Here is an idea which is lower cost and potentially friendlier to the maintainers:

what if they could create a repo event which highlights that they are not the maintainer (empowered to merge code on the repository / a repository that other people are using as an authoritative codebase)?

If those they see as maintainers are on nostr then they could add them, even if that maintainer hasn't created a repo event yet.

people who also want to see the repository use nostr could use this and accept that the number of other contributors / maintainers who see it might be lower.

to achieve this the nip34 spec would need to be tweaked so that it is not assumed that the author is a maintainer if the maintainers parameter is present.

Reply to this note

Please Login to reply.

Discussion

sommerfeld 1y ago

>The costs of maintaining a fork are quite high.

They don't have to maintain a fork, that is only 1 of the options. They can use their fork as a proxy to open PRs in github/gitlab/etc using the nostr submitted patches.

> what if they could create a repo event which highlights that they are not the maintainer

Why not just submit the repo event with an empty maintainers list? It's essentially the same thing, or not? 🤔

DanConwayDev 1y ago

no. nip34 wording:

> `["maintainers", "", ...]`

perhaps it should be:

> `["maintainers", "", ...]` // optional: if omitted, author is sole maintainer

I think this might break a number of existing repo events.