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!

  • atzanteolEnglish
    5·
    7 months ago

    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.

    • nik9000@programming.dev
      1·
      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.