please provide feedback

this is an example issue on the gitworkshop.dev repository to demonstrate gitworkshop.dev.

please provide feedback in reply to this issue or by creating a new issue.

Reply to this note

Please Login to reply.

Discussion

Reply test from Amethyst.

Looks good

Testing a kind 1 reply in the git repo from Amethyst.

I really like your up arrow to fold replies.

I feel like I should not be able to change the status of the issue haha

I also get that feeling. should I really be able to be naughty and someone's issue on a project I don't maintain? I have considered restricting it to just 1) user who raised the issue and 2) repo maintainers (OPTION 1).

then I thought that complexity shouldn't be added to the protocol to solve potential problems that haven't manifested. this has to be traded-off against the adding to the protocol when other have started to implement it. This thread illustrates how this annoys developers and leads to partially implemented NIPs: nostr:nevent1qvzqqqqqqypzpms35h0lgrqe542lg8ly9dy0qrnp3jgjy43z4cmmds4mv7mkcnjfqyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgwwaehxw309ahx7uewd3hkctcqyrnw36q5thdufr0d5mqjp2cren2azqgs2hsrqhrfqdqrzcpftgxkcgwdc6x

So what is the problem with being able to change a status on an issue or proposal I didn't create on a repository I don't maintain? I think it is:

1) malicious actors who change statuses to create chaos (SPAM status events) - couldn't this be dealt with like other SPAM?

2) users who, operating in good faith, close or reopen an issue / proposal but don't understand the maintainers approach, or wider context around why this sort of issue / proposal should remain closed. perhaps there could be the option to add a 'locked' hashtag which means future status events from non-maintainers should be ignored (OPTION 2)?