-
Notifications
You must be signed in to change notification settings - Fork 497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add moderation rules #1202
Comments
I would still advocate to have moderation rules for the lightning communication channels, like what has been done recently on the bitcoin core side. There are many stakeholders involved in the development of the lightning protocol and its extensions, and especially some with opposite interests. More concerning, and more technically, there is still a lot of technical debt about this protocol, and if one (in his hobby time as it's all really free and open-source software is really made), is spending time to clean it bit, it’s good to have moderation rules, to avoid one stakeholder playing with the administration of the common communication channel, let's say in a non-constructive manner. |
I have, yet again, deleted unnecessary personal attacks from the above messages. I definitely agree we need to have some form of moderation rules to clearly lay out that personal attacks are not allowed within the lightning community. |
I agree we need some moderation rules within the lightning community. In the meantime I’ll work on a bash script to do an automatic open-timestamp of all the issues on the lightning github, to minimize the risks of admins equivocation with regards to application of said future moderation rules. |
Done. |
I think it would be good to add some moderation rules in this issue tracker, at the image of what has beeing done for the bitcoin core project, see https://github.com/bitcoin-core/meta/blob/main/MODERATION-GUIDELINES.md
Moderation rules is still more constructive than someone going into generalists or specialists medias to raise some questions about some stakeholders to this open-source project are behaving, and if some are not outstandingly driven by short-term commercial interests.
Beyond, I think it would contribute to build better conversation norms for the contributors with long-term preferences to focus on the design and development of the years-long consensus changes that are needed to improve on the technical debt of the protocol, as documented in the original lightning whitepaper (cf. “9.2 Forced Expiration Spam”).
The text was updated successfully, but these errors were encountered: