What area do you would like to improve?
Its a nip34 git issue. It should display in Amethyst, Corcale and a few others.
We are building nostr git clients! https://gitworkshop.dev is a web client and cli called ngit.
I'd love some design help.
Discussion
That's a good question. nip34 and the clients we work on have needs at various levels.
All of the design goals fall out of the project goal: to provide an attractive decentralised alternative for code collaboration for FOSS projects.
From helping to understand what the high level design goals even are, to UX flows, to identity and branding, to creating a favico.
What type of design work / consultation does the #nostrdesign community participate in?
The #nostrdesign group can offer help in a variety of areas, from general UI consulting to improve communication and UX, to designing a new structure, to creating illustrations/logos. Sometimes we can dive in more tech/development matters.
Lets start with a high level design goal:
A primary design goal is to minimise the learning curve for maintainers and contributors of existing projects, many of whom, the github flow is all they know.
Context:
There are many projects that use github and have a desire to switch because:
1) their contributors are getting banned
2) their project may get removed without no notice and a reactive move would be much more disruptive and may result in loss of important context for history changes
They see the benefits of decentralisation but are may see adapting their 'flow' as a switching cost more than a benefit of using an alternative.
One of the areas that we are failing is in the use of the term 'proposal'. Most users find this confusing. In most ways they can be treat in the same way as a 'PR' or 'Pull Request' in the github flow. But they differ in important ways and it is difficult to get that across.
So we need some help with the name and how the concept is communicated to users.
How do they differ from PRs?
Sorry for the long answer. I clearly need help in finding a clearer way of explaing how it works.
In the github flow a contributor needs to:
1) clone the source repository
2) make changes as one or more commits on any branch
3) host a fork of the repository
4) push their local branch with changes
5) create a PR - a request that the maintainers 'pulls' the changes from that branch into a named branch within the source repository
If during the discussion they want to make changes they typically
6) push additional commits to their fork implementing feedback
When the maintainer is ready to accept the changes they press the big green 'Merge' button and github creates a merge commit in the source repository or squashes the change into a single commit and adds it to the source repoistory.
In the patches over email flow a contributor needs to:
1) clone the source repository
2) make changes as one or more commits on any branch
3) get setup with an email client that can deal with patches over email
4) signup to the mailing list for the repository, or area of the repository they are interested in
5) send the changes a patch (or a patch set)
6) any requirements to improve the changes before they are accepted are done by issuing a new patch set 'revision'. The existing commits are modified to incorporate changes and the whole patch set is sent again. its never the case that only the required updates are sent as additional patches.
The maintainer 'applies' the patch(set) to the latest master branch, dealing with any merge conflicts at the point of review, and either chooses to push these changes to the source repo or reset their local branch and send feedback via email.
more info at https://git-send-email.io
nip34 tries to support both flows. In nip34 patches (or patchsets) are wrapped in a nostr events along with some extra data so the change can be created fully as a local branch. This way they can act as patches (although some might not like that updates can be tacked-on as extra commits) and PRs (although there is no fork).
1) clone the source repository
2) make changes as one or more commits on any branch
3) install ngit and create / sign in with nostr keys
4) send the proposal
5) any requirement to improve can be done by adding additional commits with `nigt push` or update the entire proposal with by updateding existing commits and running `ngit push --force` (issuing a new revision) or `ngit send --in-reply-to
Maybe the details just aren't important.
With nostr you don't need a fork. Just clone a repository listed on nostr and send a PR right from your local git repository with`ngit send`.
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?
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.
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.
> 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.
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
nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk would you still be interested in discussing this?