yes, embrace the anarchy! nostr:nevent1qqst8q2jn0f6lumdzndxewuw8gxu058rcj8kyqgqklh7ju3vgxwky6gpp4mhxue69uhkummn9ekx7mqzyzsq3hh327t0h2dq6matqn5064cgj2zanl2stkj6s0lg4t2h5dty626e07k maybe this should be more sensible and only allow the maintainers / author to change the status.
I actually found it really useful because I have a bunch of different npubs for testing and whatnot and it was convenient to be able to review and close issues from the one while logged in as the other. But then I wasn't sure if it was a clever feature or a bug, so I thought I'd ask. 😂
I could reopen the issue, edit it again, and see who had closed it (so that I could ask them why), so it seems like the possible damage is limited.
I think there needs to be some sort of enhanced notifications when someone other than the author or maintainers close an issue so it doesn't go unnoticed. Also spam controls would need to be integrated. Wouldn't it be annoying if a bot closed all your open issue / proposals and opened random closed ones? Whilst there is some merit to this approach it does seem to be fraught with problems. why deviate from the normal approach that users expect and has less problems?
Well, a bot could also just spam the repo full with nonsense proposals. I guess you'd need a repo whitelist/blacklist option, really, in ngit. Then each project could determine how to define that list. I wouldn't put it in the maintainers file, though. Trying to account for malicious actors in each feature is too complicated.
Yes. I'm kind of new to spam prevention so the thought of working features around this excites me. Users could opt in/out of the reports bans by the maintainers. Although maybe a maintainer would prefer to manage these separately.
I'm closing this issue because I'm thinking this is actually an ngit discussion. Moved it to a new issue here: nostr:nevent1qqsf7hg7slt4uaapkqnhe0cpl84n5a2v93anqedrzkvwv30n3hc9xjspp4mhxue69uhkummn9ekx7mqzyr7jprhgeregx7q2j4fgjmjgy0xfm34l63pqvwyf2acsd9q0mynuz36ecrx
test
Sorry. :-) Just checking to see if replies refresh. Had to refresh the entire page, after the last note, but I think it was just slow.
I think the whole site needs to be thoroughly debugged for reactivity issues like this. I'm in the middle of a refactor so it will be best to do this after that.