COMMUNITY_GUIDELINES.md: Create from Gentoo #120
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "gitlab-mr-iid-2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is to discuss a bit on having community guidelines, as started into
#pleroma-devon 2022-02-27.I think it should be directed to a specific repo and/or something like
#pleroma-staffon IRC.This line will need to be reworked a lot, as we usually do have a bit of idle chatter and can accept bugs reports on pleroma-dev.
Same thing regarding how to direct reports/complains.
do we have a mailing list?
I'd like to see CoC mention the scope where it applies, i.e. development discussion in MRs and IRC and such, public annoucments/speaking (publicly) from position of power.
Far too many community guidelines nowadays overextend to other social/private life, i.e. you supposed to follow Twitch's rules even when you're on Fedi/Twitter/Reddit/4chan/whatever, not following the rules CAN get you banned on Twitch and it's bullshit (IMO).
Nah, it's just that gentoo does, among a bunch of other things.
Might be a good idea to have something like a mailing-list later on though so it's not just gitlab or IRC.
"misinformation" should probably be re-worded because of current day meaning having changed a lot since 2013.
As ademan mentioned in IRC it should also have "assumption of good faith" aka presumption of innocence https://en.wikipedia.org/wiki/Presumption_of_innocence
Alternatively from FreeBSD Community Code of Conduct, not sure what kind of license it's in, it's a FreeBSD original rule.
Parts from Django Code of Conduct and Speak Up! are under CC-BY-3.0.
Parts from LLVM Community Code of Conduct are also under an unknown license.
Mostly meh, I feel like the only one which fits there is the Gitlab part.
Tried to add it, like via amending on "
**Admit the possibility of fault and respect different point of views.**" or adding another point but I didn't find a way to make it work nicely, got some suggestions?I put Maintainers for now but I think it would still be better to have a more or less different group of people so there is a way to get different people involved if needed.
Could be just a footnote/TODO as I think we might be too small in project members (~regular contributors).
Related to #120/diffs
What means could we have to appeal for disciplinary measures? I guess we could have an email address like
appeals@pleroma.socialand then that could then forward the appeals to whoever handles that disciplinary action. But IDK. What do others think?I concur.
I feel like the best candidates for such a group would be folks who can objectively look at situations without a strong bias for or against certain developers, contributors, maintainers, etc.
Seeing the nature of the software (a federated social network platform), not all communication happens on Pleroma Project Infrastructure. E.g. If I talk on fedi about some Pleroma feature/bug, or about some development work I'm doing, or talk to other devs (maybe from other AP-projects) about things, or..., then I'm as much a representative of the Pleroma community as I am on the GL issue tracker for example.
Also the "responsibility" part has a bit of a negative connotation.
I added the 2.5.0 Milestone.
In chat it was decided that we want to have the guidelines agreed between us before, or at least not after, the release. The announcement should be done on the blog part so they're not lost into some release.
We may already do an announcement on donations and mention we're working on this, an extra blog post when we finished can be released in a subsequent announce to that one.
Adding the milestone may not be 100% technically correct since it's separate from the code, but it does show a commitment and makes it clear to us that this was decided.
Yeah but that's pretty much a case-by-case basis kind of thing where I think the ones involved should point to one or more person that can act as an objective third-party.
I'm still not sure why this should be separated from the release announcement. I believe it is important enough that it should be included in the release announcement blogpost, particularly after previous events affecting Pleroma since the last major release.
So it wouldn't be lost in the other release announcements. As far as I'm concerned, it could still be mentioned in the release blog post as well (and link/reference to the other article).
also add a space in beginning
.**->. **otherwise it breaks formattingLooks good to me, although I think the whole Proctors thing should be pretty much just put onto maintainer's responsibility and/or community vote right now, as we really don't have nearly enough people to properly enforce things.
Point of contact should be decided. I think it should be reasonably private but not via personal addresses / point of contact, for example via an issue on Pleroma's Gitlab.
issue in pleroma-meta should be fine, if not we can add another similar repo just for complaints about community
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.