> minimise the learning curve

Minimise the learning curve is quite easy when you have a unique referer, to begin just copy its main traits (functions, labeling, etc) and add value inspired by the Nostr possibilities (decentralisation, but not only this).

When you have a minimal critical mass, a 100% working product and enough feedback, you can start to impose some new concepts or adapt/migrate the existing ones.

> the term 'proposal'. Most users find this confusing.

I would say, just use "PR".

What can Nostr PRs offer compared to Github PR?

Let's highlight that in the workflow and show an enhanced pull request version.

Reply to this note

Please Login to reply.

Discussion

That's a great advice. I have been reluctant to do that to date. It was probably the right decision when designing the architecture but now focus is shifting to creating user experiences it would be foolish to ignore tool and flow that has dominated the market.

I think trying to create a tool that would satisfies the expectations of git-over-email users and github users is a recipe for creating confusing experiences.

The great thing about nostr is that it is normal to have multiple clients to cater for different needs and preferences.

I think in all Nostr projects we have to strike a good balance between the "just works" experience and highlighting the underlying technology. This is strongly related to the users target, of course; this is a quite technical tool, so we need to surface a lot of details, but in an clean and productive way. A sort of progressive disclosure pattern.

I am going to test ngit asap, shoot me a DM if you want to reason about some topics.

Thanks. what do you mean by 'reason about some topics'?

We can identify the most critical areas, and I can propose a design to improve them

Sure! Send me a DM

Damn, I just saw a DM of yours from a few days ago, it was stuck somewhere!

I will get back to you asap