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.

To be honest, neither Hexbear nor Lemmygrad has caused any noticable issues for lemm.ee. I recently compiled some stats for lemm.ee rule breakers by home instance, and as you can see in this post (in the “Administration” section), neither of those instances even made the top 10.

In general, mods haven’t complained about those two instances either, and the stats for community bans by independent community mods are more or less very similar. If any users creates issues in a lemm.ee community, then the community mods are free to just ban those users, regardless of what instance their account is hosted on.

if fact I wouldn’t even be able to as my home instance is defederated from these instances and thus such posts would be invisible to me

Preventing such situations for lemm.ee mods is actually one of the many reasons we don’t want to use defederation as a moderation tool on lemm.ee - we rather use site bans etc. Too much collateral damage with defederation, especially when dealing with larger instances which probably have vastly more innocent users than problematic ones. We reserve defederation for more extreme cases, like spam instances & CSAM.

Hey, lemm.ee admin here - it’s actually hosted in Finland!

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

Sure

Hey, this post is quite old, actually you can find the latest info in the sidebar of our front page:

• Image uploads are enabled 4 weeks after account creation
• Image upload limit is 500kb per image

Hey! Thanks for the report.

I think the first issue is not something I can help with - probably the Connect app needs to fix something on their side.

For the second issue, see my comment here: https://lemm.ee/post/34118135/12479638

It’s a full new game that you need to purchase separately, but all the marketplace stuff you’ve bought for 2020 will also come with you to 2024

We finally have a release date for Microsoft Flight Simulator 2024!

I have identified two reasons for broken thumbnails right now:

1. For some, the source website is simply not allowing our server to download the image (mostly due to server issues on the remote side)
2. For others, it seems that some types of URLs are breaking thumbnail generation. I think I found the bug here and will try to submit a fix soon.

That’s definitely not intentional - it’s a custom error message which we have just for lemm.ee, not a standard Lemmy error, and it seems I need to tweak it a bit for it to work correctly in 0.19.4. Thanks for reporting this!

Yes, lemm.ee has all the standard Lemmy features. However, the format for this request has changed, and it seems the app has not been updated yet.

For technical context: your app is trying to use the singular post_id field when marking posts as read. This field was marked as deprecated several releases ago, as it was replaced by a post_ids array field, in order to enable marking multiple posts as read at the same time. The deprecated post_id field has been removed in Lemmy 0.19.4.

Regarding your question:

Lemmy federation basically works by copying stuff from their source instance to all other federated instances. So if I write a comment on lemm.ee, other federated instances will get their own copy of my comment. They will also all know that the “authority” for this comment is lemm.ee.

If an admin on another instance decides to delete their local copy of my comment on lemm.ee, then they are always free to do so (for example, some instances might want to moderate more strictly), but any actions they take like this are limited to their own instance - for the rest of Lemmy, lemm.ee remains the authority for this comment, so individual remote instance admins taking actions won’t have any effect on any other instances.

As for the original topic of modlog federation, basically it just boils down to this: just like with the comment example above, Lemmy instances also save a local copy of incoming federated mod logs. The Lemmy software does not yet have 100% coverage in terms of federating mod logs (for example, there are no federated logs yet for instance admins banning remote users), but this coverage has been increasing, and I expect this will eventually get to 100% (just needs more dev time really).

Also, if some instance admins try to tamper with their mod logs, then other instances can still see the real history, because there is no way for an instance admin to delete copies of their mod log from other instances.

Banning a local user from a local community does actually federate already

Most actions federate, any exceptions which aren’t federated yet are generally just there because the federation logic has not been implemented (but improvements are constantly being worked on).

Generally federating the modlog is mostly just there for informative purposes. As in, we can check what mod actions were taken on instance A through the modlog on instance B (and there is no mechanism in Lemmy for other instances to retroactively remove or hide federated modlog items, btw).

Sure, the lemm.ee federation policy is here. You can also always find a link to it in the sidebar on our front page.

Basically, yes!

For the backend: our traffic is load balanced between multiple servers, so I can just spin up a new server with the latest version of Lemmy, add it to the load balancer, and then start taking down the servers with older versions. That way, there is no disruption at all for users, because there is always a server available to handle incoming traffic. The only requirement for this is that the new version of Lemmy can’t have database migrations which break the old running servers.

For lemmy-ui: it’s a bit more complicated, because even with a load balancer, it’s still possible that one user making multiple sequential requests can end up getting responses from different servers. This is problematic, because during an upgrade, files from the new version are not available on the old servers, and vice versa. Fortunately, there are many ways to solve this problem, for lemm.ee, the solution I use is to just always serve lemmy-ui files from object storage, for all versions. In other words, after I upload lemmy-ui files for a new version, these will immediately also be available on old servers.

By the way, as a mini-present, I have sneakily updated our Lemmy to 0.19.4! It was possible to do this one without any downtime, so I just did it quietly in the background.

It’s the first option in the dropdown:

Big thanks to all maintainers and contributors!