Well, that one arrived. Should it not?

I'm sorry, I can't ignore. Who is on stage?

I feel like most current issue labels are meaningless beyond the Bug label we use to prioritize issues during the RC period.

So it wouldn’t do any harm to add another one, but it won’t help with any existing workflow either.

Why aren't you call this by the update.php in a preupdate function?

You could use the preupdate functionality and check for the lock and remove it.

When I started working on the 2FA feature, I got the idea of grouping all the related classes in the same subfolder instead of having them grouped by type. After all, when you're working on any given task, you're more likely to need to access the classes of different types relating to the same feature than to need to access the classes of the same type for different features.

However, modules are completely different from the Entity/Collection/Depository/Factory paradigm, mostly because they depend on the global context and as such they are the only ones that should make use of the DI shorthands. They also are depending on the routes file, and it is nicer to see all the available routes in the same folder.

I kept this trend with notifications, and I chose "Navigation" because notifications are meant to redirect users to the relevant content.

I think ProfileField classes should go under "Profile" like you suggested and PermissionSet may go under "Privacy" since I feel like "Item" feels too broad and we don't use permission sets just for item (post and replies).