Programming

17437 readers

162 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

[email protected]

How do you contribute to OSS? (lemmy.world)

submitted 6 months ago* (last edited 6 months ago) by [email protected] to c/[email protected]

23 comments fedilink hide all child comments

So I've come to the point where I've wanted some to see some features on the software I regularly use and I feel confident enough that I can pull it off. However, once I start getting into it, it all becomes so overwhelming that it's hard to get anything done.

For instance, on more than one occasion I had trouble getting the projects to build on my machine (eg., unsupported OS, lack of documentation, etc.) and it left me unable to write a single line of code making the experience frustrating from all the time wasted that I had to move on.

Other times, I recognize some the patterns and get the general gist of some snippets, but the overall code seems so convoluted to me that I don't even know where to start to analyze a solution, even though if it'd probably take ten lines to implement.

For context, I've been more of a hobbyist programmer for the great majority of my life with a bit of schooling. I do have various finished apps under my belt so I'm definitely not new. But I have no reference for how long a feature should take to implement in someone else's code for the average Joe who does this for a living.

So I'm left wondering: What advice do you have that could make this all more accessible to someone like me? Do you have a general strategy to get started? How long does it take you from start to finish? And if you run into issues, where do you seek help without nagging the devs about their code who may take too long to respond to be of use?

Many thanks for the feedback in advance!

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 6 months ago (3 children)

Follow up question -- I'm not OP but I'm another not-really-new developer (5 years professional xp) that has 0 experience working with others:

I have trouble understanding where to go on the spectrum of "light touch" and "doing a really good job". (Tldr) How should a contributor gauge whether to make big changes to "do it right" or to do it a little hacky just to get the job done?

For example, I wanted to make a dark mode for a site i use, so i pulled the sites's repo down and got into it.

The CSS was a mess. I've done dark modes for a bunch of my own projects, and I basically just assign variables (--foreground-color, --background-color), and then swap their assignments by the presence or absence of a ".dark-mode" class in the body tag.

But the site had like 30 shades of every color, like, imperceptibly different shades of red or green. My guess was the person used a color picker and just eyeballed it.

If the site was mine, I would normalize them all but there was such a range -- some being more than 10-15% different from each other -- so i tried to strike a balance in my normalization. I felt unsure whether this was done by someone who just doesn't give a crap about color/CSS or if it was carefully considered color selection.

My PR wasn't accepted (though the devs had said in discord that i could/should submit a PR for it). I don't mind that it wasn't accepted, but i just don't know why. I don't want to accidentally step on toes or to violate dev culture norms.

[–] [email protected] 5 points 6 months ago (1 children)

I've done a lot of development professionally, but not submitted to an OSS project, so take this with whatever sized grain of salt you deem adequate.

How should a contributor gauge whether to make big changes to “do it right” or to do it a little hacky just to get the job done?

I'd start small at first - especially if you haven't contributed before. If you dump a huge PR on somebody then that takes a lot of effort to review, verify, test, etc. It might be easier to get acceptance by starting smaller so that it's easier for people to understand what you're changing and to get buy-in for the new direction. Linus Torvalds has historically been very critical of huge patches due to the amount of work it takes to verify them.

My PR wasn’t accepted (though the devs had said in discord that i could/should submit a PR for it). I don’t mind that it wasn’t accepted, but i just don’t know why. I don’t want to accidentally step on toes or to violate dev culture norms.

That's kinda crappy - they should at least tell you why they don't want your changes.

[–] [email protected] 1 points 6 months ago

I agree. Light touch until you have a bunch of changes landed.

I was a professional open source contributor for a while. Still have the same job, but the license changed. Culture still quite similar though.

[–] [email protected] 3 points 6 months ago

Different devs accept different things, and we are all burnt out to some degree.

I think you probably want to start small, i.e, normalise the colors first, and then do your dark mode change, but it really depends.

Did the dev not say why they rejected it? Seems very rude of them not to give a reason.

[–] [email protected] 3 points 6 months ago

How should a contributor gauge whether to make big changes to “do it right” or to do it a little hacky just to get the job done?

When you work in enough diverse codebases, with enough diverse contributors, you begin to understand there isn’t one objectively right way. There are many objectively wrong ways to do something. Picking a way to do a certain task is about picking from tradeoffs. A disturbingly common tradeoff is picking rapid development over long term maintainability, but that isn’t not the right way to do it in a competitive space.

Needs change over time and certain tradoffs may no longer apply. You’re likely to see better success making lots of little hacky fixes until it’s not a hack anymore because you’ve morphed it slowly over time.

Version control, git et al, allows you to make multiple commits in a single PR, so you could break the changes up to be more reviewable.