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

That’s true, it will only show content which has been federated to lemm.ee, so indeed if you want to search for more content than is available on your instance, you would need some additional tools for that.

I’m a simple man:

“What day is it?” asked Pooh.

“It’s today,” squeaked Piglet.

“My favorite day,” said Pooh.

Should work just fine for posts and comments as well, for example, here’s a search result containing your comment

The built-in search feature is actually quite decent I find, is it not working well for you?

For context I use all of these daily: Linux (servers + handheld gaming), Windows (gaming), Mac OS (work & general purpose). I used one of the first iPhones around 2008, then exclusively Android for 10 years, and then back to iPhones.

Iphone users of Lemmy, people say not to trust you on tech insights.

IMO, these “people” with such takes are the only ones who shouldn’t be trusted on tech insights here :P

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.

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 am not really interested in discussing this with you, as you already have an opinion about lemm.ee and seem intent on spreading false rumors about us. I’ve learned several months ago that no matter how much you give to people for free, there will always be users demanding more, so I don’t think there is any chance of you being interested in what I have to say. I am just responding here, so other users who may end up reading this thread don’t come away with the impression that what you are saying is true.

First of all, no user has ever been banned from lemm.ee for criticizing the admin team. Our admins have banned nearly a thousand users in the past ~7 months (just think about that for a second - that is a massive amount of bullshit our volunteer admins have had to wade through in the span of less than a year), and indeed the mod log is public, so you can easily check the ban reasons, which are consistently related to violations of our basic instance rules.

If any moderation team on any of our communities does not follow our instance rules, then such communities are closed. We have in fact had to do this several times before with some conservative-type communities, mainly because they wanted to push the ideas that some people, based on their identities, are less valuable as humans that others. The current conservative community on the other hand is consistently moderating based on our instance rules, and they have incorporated the no bigotry rule into their community rules as well. If this ever changes, then we will take action, just as we have done previously.

Regarding the allegations against one of the mods, I’m not sure if you’ve seen the event they were referencing, but I think it’s safe to say that this event was extremely misrepresented by the accuser. In any real cases of CSAM, lemm.ee has taken drastic actions. We have purged, banned, defederated, reported to authorities, we have implemented some technical safeguards, and we will continue to take action like this in the future as well.

Let me just finish off by saying that we are a volunteer team giving up our time for free. I realize that users want admins to be perfect and moderate exactly in line with their preferences, but we are humans, we miss things, we make mistakes, and we can not possibly be available 24/7 or read every single piece of content posted by other lemm.ee users.

lemm ee: The owners don’t really moderate and its users reflect this fact. Universally unpleasant userbase.

This is categorically untrue. You can find our administration policy here, and we frequently ban users for breaking our instance rules. At most you could make the claim that we are lenient when it comes to things like heated arguments, as we often give warnings or temporary bans to users in such cases, but on the other hand, our “no bigotry” rule is very strict, and violations have consistently resulted in permanent bans.

We of course don’t screen all posts and comments which our users write, so we can only respond to reports, but I assure you that our admin team is constantly going over and responding to the report queue (which is a big effort, and clearly a thankless job).

By the way, I just want to point out that we have ~3000 active monthly users on lemm.ee, I find it very unlikely that you can make an accurate universal judgement about such a huge group of people.

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.

https://matrix.to/#/#lemmy:matrix.org

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!