I don’t believe there is any type of auto moderator, though that’s possibly being supplemented by external bots.
I forget where I read it, but I believe the biggest issue is with the implementation of current mod tools and how they don’t properly propagate through the fediverse.
Actually I have built an AutoMod myself, just a few days ago.
The configuration is a bit clunky, unfortunately, mostly because of lack of UI support. I plan on making some changes to my instance’s UI to make this a bit more feasible, and of course those will be open sourced just like the bot, but it will take me time.
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.
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.
You can just use a bounty hunting site, I like rysolv (open source and under the AGPL)
What kind of moderation tools could help with this?
I don’t believe there is any type of auto moderator, though that’s possibly being supplemented by external bots.
I forget where I read it, but I believe the biggest issue is with the implementation of current mod tools and how they don’t properly propagate through the fediverse.
But again, I don’t recall the details.
Actually I have built an AutoMod myself, just a few days ago.
The configuration is a bit clunky, unfortunately, mostly because of lack of UI support. I plan on making some changes to my instance’s UI to make this a bit more feasible, and of course those will be open sourced just like the bot, but it will take me time.
Here’s a laundry list from one of the Beehaw people, and apparently the devs don’t have any of this as a priority
Wrong link.
Anyone can be a dev, it’s open source.
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.
You can just use a bounty hunting site, I like rysolv (open source and under the AGPL)