Sure, but it usually takes some time to get proficient in a language. I’ve been an enterprise Java engineer for a decade and things have changed pretty dramatically in that time. Picking up a language like Rust takes time, understanding the available frameworks and what they provide takes time, understanding why there isn’t published code coverage metrics takes time, understanding why commits get merged when the pipeline is broken (or the commit broke the build) takes time, etc.
It’s important, if one plans on creating a project that is maintainable by people other than yourself, to think things through and make sure the actual infrastructure exists and is stable and documented before opening it up to the world - and hold steadfast to those processes. When I read a PR that has the comment “the code works, now I just have to work on some tests”, I start to cringe knowing that testing is usually an afterthought with that developer rather than the place where the change should have started. As I look at the code in GitHub, the last commit to main didn’t even build. How was it even allowed to merge of it failed in the PR? Or do the pipelines just break randomly?
Maybe I’m just really picky because I take pride in the maintainability of my professional (and personal) projects. After seeing where we were 5-6 years ago - with commented out code and tests, tests that made no sense, lack of code or branch coverage, non-existent validation phases, etc - it’s a no brainer that I would never want to go back to that.
But that also illustrates why simply demanding that the existing devs should prioritize your personal needs over whatever it is they’re working on is kind of a non-starter. If it’s too hard for you to become a dev on the project but they’ve put in the effort to do so, they get to use that hard-won ability however they see fit.
Is there some sort of bug bounty or feature bounty program for Lemmy or kbin? That might be a way that a non-dev could get their own needs prioritized, perhaps.
Sure, but it usually takes some time to get proficient in a language. I’ve been an enterprise Java engineer for a decade and things have changed pretty dramatically in that time. Picking up a language like Rust takes time, understanding the available frameworks and what they provide takes time, understanding why there isn’t published code coverage metrics takes time, understanding why commits get merged when the pipeline is broken (or the commit broke the build) takes time, etc.
It’s important, if one plans on creating a project that is maintainable by people other than yourself, to think things through and make sure the actual infrastructure exists and is stable and documented before opening it up to the world - and hold steadfast to those processes. When I read a PR that has the comment “the code works, now I just have to work on some tests”, I start to cringe knowing that testing is usually an afterthought with that developer rather than the place where the change should have started. As I look at the code in GitHub, the last commit to main didn’t even build. How was it even allowed to merge of it failed in the PR? Or do the pipelines just break randomly?
Maybe I’m just really picky because I take pride in the maintainability of my professional (and personal) projects. After seeing where we were 5-6 years ago - with commented out code and tests, tests that made no sense, lack of code or branch coverage, non-existent validation phases, etc - it’s a no brainer that I would never want to go back to that.
As a dev myself, I fully agree.
But that also illustrates why simply demanding that the existing devs should prioritize your personal needs over whatever it is they’re working on is kind of a non-starter. If it’s too hard for you to become a dev on the project but they’ve put in the effort to do so, they get to use that hard-won ability however they see fit.
Is there some sort of bug bounty or feature bounty program for Lemmy or kbin? That might be a way that a non-dev could get their own needs prioritized, perhaps.