From ad2da19b84a6b99eb28c503ef75cfa97d1941994 Mon Sep 17 00:00:00 2001 From: uzalu Date: Fri, 19 Dec 2025 02:58:04 +0000 Subject: [PATCH] notes file probably shouldn't be public --- .gitignore | 1 + src/Notes.md | 64 ---------------------------------------------------- 2 files changed, 1 insertion(+), 64 deletions(-) delete mode 100644 src/Notes.md diff --git a/.gitignore b/.gitignore index 927295f..213b4c1 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,4 @@ /book deploy_dev.sh deploy.sh +/src/Notes.md \ No newline at end of file diff --git a/src/Notes.md b/src/Notes.md deleted file mode 100644 index 3748317..0000000 --- a/src/Notes.md +++ /dev/null @@ -1,64 +0,0 @@ -- Leaking as its own section, or part of Sedition? -- mischannelling removed as a rule, but included as a note since it's per-channel? -- rule against false reports: Sedition? -- Regarding spoilers - reduce the rule to only cover relevant events areas while the relevant story is being consumed, or soon-to-be consumed - - possibly this should not be a server-rule, but like mischannelling, it should be region-specific. A person's right to post in a channel might be removed if they post spoilers there. - - there is a question of what to do if they ping relevant people/groups with spoilers from a different channel, while the story is being consumed -- If Sedition is going to contain so many disparate subsections, perhaps they should be listed on the main rules page under the Sedition header? -- combine the notions of Sedition and enemy combatants - neither traitors nor enemy combatants need to have broken a rule to be reprimanded, but Sedition is the means by which a citizen becomes a traitor. -- Some rules, like impersonation, don't need to be rules per se, (since marking a user will be sufficient to defeat the impersonation itself), but such actions should be incompatible with a user being Respected. Perhaps a separate class of rules, or just high-standards is required. Same for Moderators too? -- Consider not using categories for rules at all, keeping a single layer, and combining a few which are very similar (such as the types of illicit sexual material), and keep their headers concise. - - It is not at all clear that any scheme of categorisation is helpful, and where there are commonalities between rules, they are either in fact the same rule, or those commonalities should be tags, or explained on the relevant pages or a separate commentary page. -- consider structuring the rules pages to first give a definition (sans "is prohibited"), then describe what consequences should befall violators. Perhaps have a page for 'standard response' to reduce the copied information. -- perhaps something to handle users who deliberately do not report obvious rule violations? -- the rule defining advertising as spam has been removed. I should write a better definition. Existing users advertising things they like is fine - good, even; but new users who just post a prepared advert isn't. It may be impossible to determine an exact line between the ok kind and the bad ones. -- for Mischannelling, perhaps it needs an additional rule attribute, something like "regional", which means it usually only applies to the specific area of the server in which the violation happened. -- The current Watchmen Guide is [here](https://docs.google.com/document/d/1npy4WpKRvBnygYCOZyV54LIgEjd592Dbe617C_OkPrE). -- the rules for moderators and rules for domain owners should be their own sections alongside rules, which each become active when a user has the relevant role. These are a concrete codification of the responsibilities mentioned for the moderator role. Domain owner (or something briefer) should be added to the rules page. -- unperson (or a generic name) should be added to the roles page. -- put something in the seniority rules page about whities (sub-level-1) -- consider switching the layout of the roles sections to include proposal and role details in the same page, one page per role. The enrolment page will just list the valid proposals but shouldn't list anything relevant to the requirements of that role, and should link to the promotion section in the role's page. - - having tried this, there are some problems with it. This is like a three-body-problem, no matter how we organise it, something is either split, copied, or contextless. -- change the "info-hazard" tag to be "POTENTIALLY-violating material" - - also consider changing the name, since it refers to a few things which don't exactly match 'info-hazard', though they're close. -- Include something in enrolment about restoring existing roles for users on new accounts, or who left and rejoined -- include something about lingering server-mutes -- some guidance on how to use enrolment in discord specifically, notably how to set a veto, and to make sure all discussions is in threads. -- consider combining moderator rules and liberties (possibly also provisions) into one category, perhaps a general set of constraints on official power. -- include a Guarantee which requires that any Guarantee must be worded as a negative right rather than a positive right whenever possible. - - consider making it impossible to implement the worst kinds of positive rights. - - for removing guarantees, make it much easier for positive-rights guarantees than others. -- devise a better definition of "leeching", and a more comprehensive understanding of why it's bad and why I care. - - the rule against "Treason" should probably be recast towards a more enemy-combatant-like interpretation, OR it should specifically refer to actions by members of Cabal who are already well-integrated. -- policies for Alt Accounts: risk of leaving it with roles if the main violates rules, always mark as alt, etc. -- include credible threats in serious crimes? -- process for changing guarantees -- a section for channels, including clear definitions for public square channels. -- rules may be treated as terminal when dealing with a clearly malicious user who has no trust/integration/standing (roles) within the community. Do users with roles therefore gain rights which whitenames don't have? - - this may also apply to "public interest" from the doxing rule, and maybe even "whistleblower" from the leaking rule. -- [X] for doxing, the definition is founded in the assumption that the target of the dox is IN the server, but has no coverage of users who aren't. -- [x] for doxing, there is no means of accounting for doxed info which has become so public, even against the wishes of the subject, that trying to prevent its spread is futile. -- [ ] for doxing, possibly include the notion of "requires research" in "trivially-inferred". -- for notification spam, perhaps the rule should be lighter than it is - what we mostly care about is using @-mentions specifically and only for their ability to annoy, for example in blatant spam, but we don't care about cases where the message is actually directed at the mentioned user, or where they are being referred to. -- for spam, change the definition to "incoherent" particularly for audio, and possibly find other ways to prevent simply talking over someone from resulting in official consequences. -- Moved Rules list: - 1. Non-consenting Sexual Exploitation - 2. Serious Crimes - 3. Malicious Links - 4. Illustrated Underage Sexualisation - 5. Spam - 6. Doxing - 7. Mischannelling - 8. Notification Abuse - 9. Impersonation - 10. Spoilers - 11. Leaking - 12. Evasion - 13. Perjury - 14. Treason - -# 2025-12-19 -sharing information which could be used for serious crimes, or other dangerous acts, should probably be its own rule. - especially information about abusing children or animals - this is similar to an AI guardrail -