I think there are two separate things I want to address here:

First, agile isn’t a project management methodology, it’s just a set of 4 abstract priorities and 12 abstract principles. It’s very short, you can check it out here:

https://agilemanifesto.org/

Nothing here says that you’re not allowed to write documentation, write down requirements, etc. In fact, the principles encourage you yourself as a software team to create the exact processes and documentation that you need in order to meet your goals.

“Working software over comprehensive documentation” does not mean you aren’t allowed to have documentation, it just means that you should only write documentation if it helps you build working software, rather than writing documentation for the sake of bureaucracy.

“Individuals and interactions over processes and tools” does not mean that you should have no processes, it just means that the individuals in your team should be empowered to collaboratively create whatever processes you need to deliver good software.

Secondly, in terms of practical advice:

1. Talk about this problem with your team. Is it hard for others to figure out where requirements came from? Maybe they already have a good method and can share it with you. If it’s hard for everybody, then propose improvements to your process, for example, propose some type of design document process as part of building any new features
2. There are no perfect answers to the question of “how do I safely make non-trivial changes to systems”, but the general approach is to ensure that:

a. You have metrics about how your system is used.

b. You have automated tests covering any requirements, so that you can feel confident when making changes to one part of the system that it isn’t violating any unrelated requirements.

c. You actually document any confusing parts in the code itself using comments. The most important thing to cover in comments is “why is this logic necessary?” - whenever something is confusing, you need to answer this question with a comment. Otherwise, the system becomes very annoying to change later on.

If you are missing any of the above, then propose to your team that you start doing it ASAP

3. At the end of the day, somebody is responsible for making product decisions. Is it your team? Or maybe some separate product owner? Sometimes, you just need to communicate with whoever is responsible to figure out if any requirements are still relevant, or if they are now safe to change.

It’s not really a bug, it’s just a case where app developers need to update their code to support a small change in the Lemmy API. More details here: https://lemm.ee/post/34259050/12479585

Just a hunch, but is it possible you missed the --recursive flag when cloning the repo?

If I have several backends that more or less depend on each other anyway (for example: Lemmy + pict-rs), then I will create separate databases for them within a single postgres - reason being, if something bad happens to the database for one of them, then it affects the other one as well anyway, so there isn’t much to gain from isolating the databases.

Conversely, for completely unrelated services, I will always set up separate postgres instances, for full isolation.

Interesting project! Can you explain the vision a bit more - I understand that every instance can have their own version of an article, but how would a user know which version of an article is most relevant to them to read (and maybe even contribute to)?

Sorry if you were just making a joke, my sarcasm detector is not really working anymore (/s at the end would help). But if not, this comment really perfectly captures the entitlement in open source.

Now imagine you spend months (or even years) of your free time to build something for people to use freely, and the result is that you get endless comments from random strangers, telling you that you work for them and that you need to respect and be grateful to them. I honestly am impressed that open source still exists at all at this point.

I just want to add a counter-point to the argument that Lemmy devs are somehow opposed to contributions. In my experience, there has been no resistance to contributing any type of change (I have personally added niche features for running Lemmy in a distributed manner, optimizations, bug fixes, etc). In fact I would claim the complete opposite - I have received plenty of support and good code reviews from maintainers whenever I have wanted to contribute anything.

I think there is truth to the claim that Lemmy maintainers don’t have a lot of patience for people making demands and snarky comments, but that is very different from being opposed to contributions. Also, after running a big instance for a while now, I completely understand this lack of patience - when some of your users just keep being rude to you, it wears down your patience. It’s easy to patiently and kindly respond to the first 100 rude users, but at some point after that, it just becomes gradually more mentally exhausting, to the point where it’s basically impossible.

Even the example provided in the blog post: I don’t think snowe had bad intentions, but I do think they had clearly misinterpreted the situation with that issue, and their comments were needlessly condescending.

They specifically called it “child abuse content”, not “child abuse”. This seems perfectly valid, no?

By the way, just because these are digital renderings does not mean that there is no harm. Seeing such content can still be harmful to past victims. Just try to put yourself in this situation: imagine just playing some video game online, and suddenly being exposed to people recreating traumatic experiences from your past. Not only that - you also discover that the creators of the video game are involved & actively enabling such content. Seems completely messed up to me.

I think separate report inboxes are needed for the report reasons approach as well. This RFC doesn’t prevent having report reasons, rather I think it brings us closer to that goal.

Thanks for the thoughts!

Why not take this approach to simplify it then?

Yeah, the wording can be changed, I’m adding a note about it to the RFC

But I should be able to mark a report complete if I have dealt with it. Otherwise I’m just going to go to the post and sort it out anyway, so its just adding complexity. Barriers/extra steps to administration is not the way forward here.

I think in this particular case, some barriers are crucial. At the very least, I think we need to have warnings/extra confirmations when an admin wants to resolve a mod report.

I mean, if an admin handles it to the point where mods can’t take any further actions anyway (ban + content removal), then the report is automatically resolved already, so there is no need to manually resolve. OTOH, if an admin handles it in a way that a mod might still want to take additional action (for example, the admin just removes a comment), a mod might still want to take further action (for example, ban the offending user from their community), but if the admin marks the mod report as resolved, the mod will most likely end up never seeing it.

I am legally on the hook for content on my instance, not the moderators, and proposing changes that make it harder to be an admin is a touch annoying.

Btw, I don’t think any admin actions should be made harder, I am only talking about adding barriers to resolving reports which are in mod inboxes, and when I say “resolving reports”, I am literally just talking about marking the report as resolved (this shouldn’t really be a common action for admins - it’s akin to marking DMs as read for other users IMO). I don’t want to limit admins in any way from banning/removing content/anything like that.

No. This is a step backwards in transparency and moderation efforts. Granularity and more options is not always a good thing. If you’ve ever had the misfortune of using Meta’s report functionality you’ll know how overly complex and frustrating their report system is to use with all their “granularity”.

Agreed, I think that’s in line with why I proposed not going that path in the RFC as well.

To add: I would suggest thinking about expanding this to notify the user a report has been dealt with/resolved, optionally including rationale, because that feedback element can sometimes be lacking.

I think that would a good additional feature, but orthogonal to this particular RFC (I mean, neither feature depends on each other)

Thanks for the comment! I think I generally agree with your points, will try to incorporate them into the RFC soon.

While I don’t think admins should be removing things that were reported to the community, they should be able to remove things outside of reports (even without being a mod). Sometimes spam might get reported to the mods, but the admins need to take action. Could the ‘read only’ view add a little warning before action is taken?

To be clear, admins are always able to do that anyway, I’m not proposing any changes to this. I am only proposing to limit the actual “mark as resolved” action, in order to prevent admins from accidentally hiding reports from mods. But I think it makes sense to even not limit this completely, and rather just show a warning when an admin does it - I have updated the RFC.

Btw, for this one:

Sometimes spam might get reported to the mods, but the admins need to take action.

I think it will mostly be OK as long as we allow mods to escalate reports to admins. But still, maybe it is indeed necessary to allow admins to directly resolve mod reports (with an extra UI confirmation step) as well.

Or do you mean reports on content now go to the user’s home instance as well?

Yes, exactly.

Also, there’s no way to report a user to their home instance so long as they don’t post anything in a community on their home instance.

This has been fixed in 0.19 thankfully. But for instances running older versions, what you said is still true.

I think the OP is talking about Lemmy having both a content preview and a text area for link posts.

Some users tend to write their own summary in the text area, so when opening up a post, the result will be:

• Large title written by the OP
• Automatic preview of the page, generated by Lemmy
• Text summary of the page, written by the OP

I agree that this is a bit clunky in terms of UX

What exactly is the issue with our admins? If you feel you’ve received some unjustified moderation, feel free to contact me and I can have a look.

I’m not sure what the exact circumstances are here, but something to note is that upgrading to 0.19 will mostly just help with outgoing federation (0.19.2 is much more reliable and robust when delivering activities to other instances compared to 0.18). We will start seeing the full benefits of this as more of the network upgrades.

Honestly… it’s not great. I would not recommend it unless you’re playing with somebody who is not put off by constant bugs and general jank.

In terms of bugs, I’ve had several occasions where one player can no longer open the map - it just starts opening the quest log instead of the map. I’ve also had a few occasions of the screen just going completely white. Also, I’ve had a player just become locked in a dialogue with no way of exiting.

For an example of jankiness, one key aspect of the whole game, dialogues, is just completely awful:

1. Both players can begin separate dialogues at the same time, one just gets muted
2. It’s impossible to automatically begin a dialogue with two players, one player has to start it, and the other has to “listen” to it as an additional step
3. It’s impossible to switch control of dialogues during a dialogue. This is constantly an issue, because sometimes, dialogues are triggered when you walk past some invisible checkpoint. Basically you’re forced to always have your high charisma player to walk in front and hope they end up triggering all the dialogues.
4. It’s impossible to contribute to dialogues in any way as the “listening” player. Even if you have some aspect to your character that might provide an interesting line, you are just locked out.
5. If both players speak to a character in succession, the exact same dialogue gets repeated. It’s jarring and completely breaks immersion.

There’s more, but I’m kind of getting more and more annoyed at the game as I write this, so I think I will just stop here, you probably get the picture 😅

I think the co-op is a complete afterthought in this game, and I will probably be replaying it in single player for a hopefully better experience at some point.

FYI to all admins: with the next release of pict-rs, it should be much easier to detect orphaned images, as the pict-rs database will be moved to postgresql. I am planning to build a hashtable of “in-use” images by iterating through all posts and comments by lemm.ee users (+ avatars and banners of course), and then I will iterate through all images in the pict-rs database, and if they are not in the “in-use” hash table, I will purge them.

Of course, Lemmy can be improved to handle this case better as well!

As a test, I ran this on a very early backup of lemm.ee images from when we had very little federation and very little uploads, and unfortunately it is finding a whole bunch of false positives. Just some examples it flagged as CSAM:

• Calvin and Hobbes comic
• The default Lemmy logo
• Some random user’s avatar, which is just a digital drawing of a person’s face
• a Pikachu image

Do you think the parameters of the script should be tuned? I’m happy to test it further on my backup, as I am reasonably certain that it doesn’t contain any actual CSAM

Any thoughts about using this as a middleware between nginx and Lemmy for all image uploads?

Edit: I guess that wouldn’t work for external images - unless it also ran for all outgoing requests from pict-rs… I think the easiest way to integrate this with pict-rs would be through some upstream changes that would allow pict-rs itself to call this code on every image.