Nostr Web Client

I haven’t had to maintain an open-source project that people wanted to contribute to, but I imagine some of the issues can be mitigated (not completely) by always striving for complete test coverage, making it easy to validate and verify most of the behaviour in an automated way, and delegating code review responsibilities to others who you trust to follow the same verification process and rigor.

I believe #[2] may have mentioned something similar many months ago about spending a lot of his time managing pull requests on Damus. Not sure if it’s the same now.

nobody 2y ago

I think this is something common I've heard listening to several open-source developers I listen to and respect. Linus Torvalds has talked about it as well - there is a point in a project where it grows to a point that the founders are often spending more time doing administration than they are developing.

That's a real issue if the founders are developers at heart, and I could see how it would cause burnout. I think your point about delegation is essential there. Micromanagement would be the death of passion for that developer.

Reply to this note

Please Login to reply.

Discussion

jb55 2y ago

Once I have people I can trust to collect patches into trees I can just merge large subtrees of changes like linus does it. Its very scalable. People just need to learn how to do proper git commits that are logically distinct and can be cherry picked incrementally and independently. Developers don’t have this skill anymore because github doesn’t force you to think about it.

Once people learn how to do this I would feel more comfortable letting maintainers collect many changes into their own forks that I merge all at once. I kind of do this already with #[2]‘s translation PR but I still find myself formatting the branch and removing duplicate commits, etc.

It would save me a lot of time if contributors learned git and used it effectively so I don’t have to spend all day formatting patches, rebasing, squash merging, and fixing conflicts.

ben 2y ago

🔥 git illiteracy is wide spread among professional devs. it’s worth learning how to use git effectively and as a bonus makes you look like a ninja

nobody 2y ago

I contribute to this. Unfortunately, there is not an easy way to know that what you are reading or learning is any good, short of having a mentor.

ben 2y ago

I can empathize with that. here’s my opinionated guide to git. this pattern is common in large OSS projects as well as big tech:

- read up on and practice using “conventional commits”. this will help focus commits into isolated units of work

- read up on and practice using “feature branches”. this will allow you to group your tidy commits into an isolated branch. feature branches should introduce one feature/change/fix. eg “add login support” or “fix bug x”.

- submit a pull request for the feature branch

- after review is complete and changes are ready to merge, squash all the commits into a single commit, then merge. this keeps the main branch’s commit log clean and readable

this is the basic workflow I’ve followed and introduced to teams I work on. there are lots of variations at each of these steps, but it’s a good place to start.

ben 2y ago

the variation of “subtrees” #[3] talks about above is basically a long lived branch that contains many smaller (branch, pr, squash merge) units. once the subtree is complete it’s merged into the main tree. this additional layer allows development to effectively scale horizontally.

nobody 2y ago

This is something I'm working on myself at work. We have that one Git ninja, who makes sense of all our messes. The boss hates Git and refuses to learn it properly, while I'm just trying to not add grey hairs to our ninja.

Do you have any learning resources that you recommend? Not the basic "this is how you commit" type of stuff, but more the methodology of really working in a group with Git? This is where I have found most of the literature to be lacking. I learned more from a recent JetBrains blog then I did from the o'Reilly and Packt books I read on the topic.

jb55 2y ago

The git book is the gold standard. Git finally clicked for me when i read about its internals:

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

nobody 2y ago

Thank you much.

minh 2y ago

🤙

jb55 2y ago

I will try to lead by example and structure my PRs this way from now on. Here is what I would expect from PRs with many changes:

nostr:note18wjqv08ag69uw9wehxpmd27h20r23tj846k9my98326lt6w58yesy0wjry

nobody 2y ago

This is just a me thing, but I really like how you prefix the commit message with the function you are working on in the commit.

I will look this over in more detail, but that hit me right away as an idea I'm going to adopt at work. Much easier to find stuff that way, and I imagine it helps with searching.

klabo 2y ago

Looks good! Excited to try it out

eric 2y ago

me: 🦗

Will: 🥋

Vanessa 2y ago

When is Linus joining #nostr? 🤔 or is he here already?

nobody 2y ago

He needs to. This would be right up his alley.

jb55 2y ago

Would be awesome. I’m still trying to get rusty on here…