It's common to find yourself engrossed in activities like watching multiple episodes of your favorite series each week. However, what if those hour...
For further actions, you may consider blocking this person and/or reporting abuse
While I am with you on the overall idea, my experience is mostly negative with trying to help open source projects. Most of the time, the self-acclaimed Gods of the respective project go to extremes to avoid any input from outsiders. Hostility, arrogance and neglect: that's what you have to deal with aside from the actual issues those Gods implemented.
I do believe that forking projects just to fix an issue is idiotic - but it's still becoming a norm.
Personally, I stepped away from cooperation on projects and switched to paid gigs instead, both ways: writing invoices for things I do and paying for things others do for me.
Coop with today's open source Gods... Not much fun in that.
Yes this is also true for the project as well.
Not every issue / feature request will get implemented. Even if you have PRs for this. I have seen in many projects, some good working PRs which add in some features never gets merged.
First of all, never do things hoping for attention. Do them, cuz you felt the struggle because it ain't was present there. It's not the gods we are trying to please, it's 'peasants' like us we tryna help.
I stopped "doing things for attention" a few decades ago. I am too old for that.
Unfortunately, I don't understand your terminology "tryna" (or "cuz"), not sure what you are telling me there.
As for "help": When I try to help developers fixing issues with their projects, I am trying to help them first helping others second helping many third and helping me :-) It's a give-and-take.
Unfortunately, in my experience the world has changed over the last ... maybe 5-10 years? I don't see much coop in open source development any more. It's usually mostly about showing off how good you are at coding (today, at using chatGPT or something) or copying code from stackoverflow. It USED to be about creating tools that were useful to many.
Again, let me reiterate: I am in line with the gist of the article. I am merely saying, out of experience, that it has become very, very frustrating trying to join in with existing projects. The huge amount of forks (most forgotten and unmaintained) we have seen growing is, from my point of view, mostly because of the attitude too many "open source developers" have developed (see what I did there!) in the last few years. It has become so hard by now that many of my generation tend away from open source towards well maintained, supported and professionally run projects.
Sad, but - again! - experience based.
Also, maybe you can focus on smaller projects and connect with the author/owner of the repo before you can get started with the contribution.
True if you are starting out or if you are trying to get into the game!
However, when you are trying to fix an issue with a somewhat larger project (I can think of really painful examples here) this isn't that helpful. (deleted some examples here since I don't want to diss actually good projects just because of current maintainers)
You are correct, however for learning and bug fixing I found larger projects really helpful as they simulate actual corporate experience. Where you are supposed to get used to a larger code base and start contributing.
The only difference I found is that:
All in all, it's a good time to learn, YMMV.
But Marc, you are correct as well.
I doubt you can make a meaningful change in 15min, that's just spamming.
I made a PR in a codebase I'm familiar with yesterday and it took me 2-3h, all included. Given most of it spent on writing test and getting linter, formatter to check, but that's also part of the work
You're correct. My main goal is to get people started and break the barrier. And they'll learn from the experience as well.
Yeah, may be. It happens at times with me too. But, have you never ever got any projects where you initially allocated multiple hours but 'magically'(or being in the right environment and mindset) got them done way early too??
Also, if something takes 2-3 hours, take some proper break between, most times, it actually end up saving time than delaying further. Just talking from my life.
The fact that Kubernetes was designed to simplify container management and it took needs another project to simplify that is funny. If this project grows and becomes another standard that is listed on resumes/CVs, it too will need a project to manage it, this is how Java became the mess it is today, this is abstraction on abstraction on abstraction...
Yeah, kinda reminds of LangChain as well.
This commend remains me of JavaScript 😅
Great list!
Thanks
Thanks @fast for this greate article that encourages me to ask for feedback for my first open-source (VizBlend) project. If it got your interest, kindy star it ⭐
Check out this post on dev community.
Sure!
Sometimes a 30 lines of code can be written in few lines, i mean that is what we should target while trying to contribute for an open source projects.
Basically code optimization is also very important as well.
Yeah, good point!
WHO'S GONNA CARRY THE LOGS?! 🪵 🛶 💪
YES!!
Happy New Year!
Happy New Year to you as well mate!
Thanks for share!
You're welcome!
Nice write up
Thanks :)
Lol the title.
: )
I will give a try, thanks for sharing!
Thanks for the awesome insight and advice!
Nice article. Thank you!
Kudos for this!
Good lists