| 2 May 2024 |
 infinisil | In reply to @zimbatm:numtide.com
Is it possible to make streams read-only by default, but invite people for read-write? Not sure why we'd want that? But I think it only works based on roles. E.g. giving only moderators write access | 19:37:22 |
 @zimbatm:numtide.com | Otherwise we can do GitHub Auth to read-only. And then promote people manually to the discussion | 19:37:39 |
| @zimbatm:numtide.com | Different angle | 19:38:03 |
| infinisil | I think the manual invite process should work out just fine really | 19:38:27 |
| infinisil | Tasks:
- Get https://github.com/NixOS/foundation/pull/144 merged
- Link these documents everywhere
- Open participation for everybody, and maybe create some streams for different topics
- Invite everybody
| 19:39:53 |
| infinisil | * Tasks (in this order)
- Get https://github.com/NixOS/foundation/pull/144 merged
- Link these documents everywhere
- Open participation for everybody, and maybe create some streams for different topics
- Invite everybody
| 19:40:01 |
 edef | 
Download image.png | 19:40:06 |
| edef | this could be the welcome intro, and people can sub to the other streams after they've read the message | 19:40:29 |
| edef | just join people to one read-only thing by default, basically | 19:40:45 |
| edef | (not trying to hammer on this, and not insistent on this particular approach, just making sure my earlier suggestion is conveyed effectively) | 19:41:23 |
| edef | anyway, that's my proposed colour for the bikeshed, onwards | 19:41:33 |
 7c6f434c | Technical post about the welcome message: has there been enough changing things around to start the welcome message with «Attention: this CoC is not the same as Nixpkgs main CoC, and not the same as some earlier versions mistakenly posted (before the invitations were sent).»? | 19:41:51 |
| 7c6f434c | * Technical question about the welcome message: has there been enough changing things around to start the welcome message with «Attention: this CoC is not the same as Nixpkgs main CoC, and not the same as some earlier versions mistakenly posted (before the invitations were sent).»? | 19:41:58 |
| edef | yeah | 19:42:14 |
| edef | that seems fair | 19:42:17 |
| 7c6f434c | Hopefully this will do some click-baiting… | 19:43:00 |
| edef | oh, yeah, it'd help the actually-reading-it funnel | 19:43:32 |
| edef | looks like we have some suggestions on the CoC PR | 19:43:52 |
| edef | i feel like i understand where shlevy is coming from but i'm not sure how to accommodate his concerns | 19:44:59 |
 joepie91 🏳️🌈 | if you are referring to the thread I commented on, I do not think it can be accommodated without violating the spirit of the document - it is a fundamental mismatch in thinking about harms | 19:47:01 |
| edef | mm, okay | 19:47:18 |
 danielle | Constructive collaboration involves assuming the injured party was genuinely hurt, and assuming good intent on both sides means you apologize and avoid doing the same thing (knowingly hurting someone) | 19:48:40 |
| joepie91 🏳️🌈 | this is an issue I run into very frequently when discussing conduct discussions; a lot of people, especially from "apolitical" tech background, have an interpretation of "misconduct" that centers entirely around intent and understanding... where a complaint is only deemed valid if the person being complained about fully understands and agrees with the accusation. this is a frequent source of persistent harassment of marginalized folks, because this is where the whole marginalized vs. privilege perspective comes into play. so if you want effective moderation, you just cannot have "the person understands and agrees with it being wrong" as a prerequisite | 19:49:26 |
| edef | In reply to @danielle:fairydust.space
Constructive collaboration involves assuming the injured party was genuinely hurt, and assuming good intent on both sides means you apologize and avoid doing the same thing (knowingly hurting someone) what i understand shlevy's worry as, is that people might weaponise feigned injury to steer conversations or coerce others | 19:49:29 |
| danielle | That would be disruptive behavior | 19:49:38 |
| danielle | and is already not in the spirit of the document | 19:49:46 |
| joepie91 🏳️🌈 | In reply to @edef1c:matrix.org
what i understand shlevy's worry as, is that people might weaponise feigned injury to steer conversations or coerce others (I mentioned resolution by a moderator for this reason) | 19:49:55 |
| joepie91 🏳️🌈 | In reply to @edef1c:matrix.org
what i understand shlevy's worry as, is that people might weaponise feigned injury to steer conversations or coerce others * (I mentioned resolution by a moderator for this reason, but it did not seem to assauge the concerns) | 19:50:04 |
| infinisil | I'll step away for a bit, but let's try to make https://github.com/NixOS/foundation/pull/144 work, you can also send PRs against my branch with suggestions. After that we should be Zulip-unblocked | 19:50:14 |
| danielle | i left comments on Valentin's suggestions, i'm a mix of soft +1s and hard "do not reword this" | 19:50:57 |
