as users who have used ngit to create proposals / repo events and interact with them on gitworkshop.dev, what level of information would have helped you grok what you need to grok?

nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z nostr:npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg nostr:npub1896p07z8xngpct5ma00mdrad4gqfnwfwdqcl706wrm25ajynahhs27x5ge

Would calling proposals PRs help? How can we communicate the enduring need for a source git repo but not forks?

Reply to this note

Please Login to reply.

Discussion

Thanks for that explanation Dan.

I noticed in all flows you referred to them as pull requests, despite the differences. What about using this familiar terminology and not changing it, but when the user first interacts with a PR, we explain to them how it's different from Github, in as few words as possible.

Maybe "Fast PR", let's add the value to the name.

Or also simply "Nostr PR", this add promote the brand and the underlying tech, keeping the original function labeling.

PR is familiar terminology for GitHub users but I'd just call them patches, that's what they are after all. Patch is a well understood technical term in code collaboration.

Make sense, I like this

PPs , Patch Proposals. easy to type .

PRs make sense for github as a centralize model (top-down) with git hub as single reference ( relative to central ), ngit is like git ( bottom - up ) and have local repository as reference, but is expose as patch ( relative to local ).

if this is done in ngit the term is patch, I think, but in gitworkshop is just a proposal until merged, the term is also PR ( PP ) ( github is centralized, patch is PR, allready deployed )

Don't think renaming proposals would help. It's a different workflow and a different mindset.