-
Notifications
You must be signed in to change notification settings - Fork 23
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
Start writing management documentation #2
Conversation
My own thoughts on this:
Finally, I created this repository and am having this discussion here because I would like our project to be entirely open. I'd also like to note (in case this conversation is posted anywhere) that there's already a Code of Conduct for this project. Since the topic of CoCs can attract violent and abusive people, I'm going to exercise my ability to moderate the discussion towards a productive conclusion. |
Since this uses the Python name, and seems to be affiliated with the PSF, wouldn't the standard Python CoC apply (at least to PyCQA)? I'm firmly in the camp of every project abiding by a CoC, whether it's their own or an umbrella. I don't see why they'd have to have one before joining, though. It could very well be something they've never thought about, at least not outside of a conference/event. That would be an excellent opportunity for them to decide to just abide by the parent/umbrella CoC. |
If it is the case that they are encompassed by Python's CoC, what if it was just required to have a notice to that parent CoC? If projects then wanted to include their own CoC, they could in addition. Question being: the allowance of a child CoC that is less strict? I say no, but it is up to interpretation of As for the PR, the addition of P.S. Thanks for organizing all of this! |
We're not affiliated with the PSF though. That said, the Python CoC absolutely applies to
Right, so if we require that a CoC needs to be in place (for our projects) and provide options, then they should pick one. Doing so before joining is more of a understanding that they will need to pick one/have chosen one. Again, this depends on the outcome of this conversation. I'm not hard set on every project that joins the PyCQA having a CoC. I would like every project here to have one, I'm not going to strong arm anyone into it though.
This is actually what the PyPA did. Every project links to https://www.pypa.io/en/latest/code-of-conduct/ (note that's an older version of the Code of Conduct in place on this repository). |
That sounds reasonable to me, FWIW. |
|
||
- Creator: Ian Cordasco | ||
|
||
- Pep8 Administrator: Ian Lee |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth adding 'pycodestyle' here as well for as that transition takes place
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. Was wondering when you wanted to start that transition @IanLee1521. I am happy to be of service for whenever you want to schedule that. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks!. I'll continue that conversation over on the issue in the tracker (PyCQA/pycodestyle#466).
Sounds good to me too. So is the idea that there would be a CoC for the organization that repos could point to using? Probably maintained in this meta repo? Or just a reference to a list of the approved ones which might be PSF, or others? |
So if we all agree on using the same CoC, I would imagine having each repository point to it on this repository/on meta.pycqa.org would make perfect sense. If we all can't agree on a single CoC, we could have a list and have each repository reproduce which CoC they've chosen. Does that make sense? |
Pydocstyle doesn't currently have a CoC, but I don't mind using something
like the linked PyPA one. I never thought about having a CoC, but it seems
to me like they're all quite similar, so I think we should just have one
for the PyCQA and have projects point to it.
Are there big differences between CoCs out there, that they can't be
settled with just a central reasonable one?
|
There are differences between Codes of Conduct out there. Some just say the equivalent of "Be excellent to each other" while others explicitly try to let marginalized groups of people know that they're safety will be ensured. Some try to strike a middle ground between the two. The CoC in this repository (which is just a newer version of the CoC that the PyPA has adopted) tries to ensure that people who have traditionally been marginalized are explicitly protected while working on the project and in other spaces. There's also different quantities of "reasonable". There are some people who are violently (literally) against codes of conduct. It seems like all the projects around here are in favor of having one CoC for the organization. I'd like to let more of the @PyCQA/pylint-dev members chime in too (since 1/5 has already responded).
I don't think any of our projects do. I think now is as good a time as any for all of them to adopt a CoC :) |
b85f6a1
to
a671e48
Compare
I added the newest version of the Contributor Covenant (1.4) which is receiving positive comments from critics of earlier versions (which I hope will mean we'll have less friction from people who are violently anti-CoC). One thing I didn't fill in on this is which email address to use for contacting the project team. |
Hi there, it may sounds naive to some of you but I'll ask my question anyway: what are we trying to solve with a code of conduct? Is there some examples in some community where having a CoC (or not having it) has actually played some role? That being said, I would go for not enforcing anything for project under the PyCQA umbrella but encouraging support of the Python's CoC. unrelated PS: I would appreciate being listed in the pylint admnistrator. Thx! |
We're performing the community equivalent of defensive programming. We're defining the appropriate behaviours for participants in our projects. In short, it's something we shouldn't ever need to use, but should have in place regardless.
Having a CoC in place for PyCon (whose CoC is drastically different from the PSF's) for the last few years, has drastically improved the conference experience for attendees and speakers and also improved the quality of talks and speakers the conference hosts.
Have you read the CoC that I added to this pull request? Is there a reason you prefer the PSF CoC to the one in this pull request? |
Woops! I looked at who was an Owner on the org, not who was in the group. I'll fix that too :) |
@@ -0,0 +1,79 @@ | |||
====================================== | |||
Co ntributor Covenant Code of Conduct |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an extra space after Co
which doesn't belong here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops. Thanks!
Describe project and team management
08b8e76
to
0582b40
Compare
@sigmavirus24 thank you for your response. I'm still a bit dubious because it seems to me that a project's community and a conference (speakers + attendees) are not that much alike but nevermind about that ;) I've read the CoC you've added in this PR and it seems good to me. I was talking about the PSF CoC because I see PyCQA as a kind of "spin-off" the PSF and so it seemed logical to me that we share the same CoC. I've no strong opinion about that anyway. |
Yeah we're not really affiliated with the PSF. I guess I should make that very clear somewhere. We're merely following the footsteps of the PyPA and PyCA (and probably a few other groups) which made their organizations as a sort of tongue-in-cheek umbrella for related projects. Hopefully I've also addressed @IanLee1521 and your concerns about the wording I threw together quickly about project administrators, @sthenault |
CODE_OF_CONDUCT.rst should be updated to 1.4 as well. |
Yep. I just wanted to leave that in place until we finished this conversation @groteworld (that way there's no illusion of the rules changing out from under anyone's feet). |
So, I'm not sure if this your plan, but I almost feel like there should be either the CODE_OF_CONDUCT.rst or code-of-conduct.rst but not both (just more things to keep in sync). If I were to pick I would remove the top level CODE_OF_CONDUCT.rst and update the README to point to https://meta.pycqa.org/WHATEVER_THE_URL_IS_WHEN_THIS_MERGES |
@IanLee1521 that would work fine for me. Also thank you for recognizing that this branch is on the repo and that you can push directly to it for collaboration. That genuinely makes me happy. 🍰 |
So I'm not completely sure I captured the right wording, but I updated the branch with 8a40e50 to capture the idea of just using the code of conduct that will be hosted on pycqa.org. Note that until this branch is merged, the link I reference in the README will be broken, since this branch adds that file. |
So getting back to the conversation at hand, what's everyone's though on Codes of Conduct for PyCQA and per-project? I'd like to wrap up this portion of this document. I'll ping @PyCQA/pylint-dev again just to make sure any stragglers there have a chance to weigh in. I'm happy to answer as many questions as y'all would like. I want everyone to be happy, comfortable, and confident with whatever the final decision is. |
I agree that we should have a top level CoC (which we've added here). I also think the projects should be encouraged, though potentially not forced, to establish a CoC policy. In the case of pycodestyle, it is my intention at this point to simply use the organizational one added in this PR. I should also add that I am willing to be part of the contact list (maybe we need a new mailing list?) for those wishing to report violations / concerns. |
That's how I've presently worded the text around Codes of Conduct. Do we think it will be good to keep track of which projects presently have a Code of Conduct and which one they're presently using?
I have the same intentions for:
Yeah, we'll need to figure that out next. I suspect I could set up an address @pycqa.org that could just be an alias to whomever is on that contact list. That said, I also wonder if we shouldn't just use individual email addresses. That list should be capable of dealing with another member of that list without compromising the safety of the person reporting the behaviour. |
I don't think that's necessary, I think it'd be fine to have the pointer only in one direction. I might be wrong though.
I like this idea. 👍 |
My only reasoning for having the list is to make it easy for people checking out the organization to know which projects have a CoC and which CoC each project uses. |
Hey all, I think unless I hear some objections, I'll just merge this on Friday and then send other PRs for other aspects of the management documentation. Cheers, |
👍 |
Start writing management documentation
It seems no objects to this so I've merged this like I said I would. :) |
cc @PyCQA/pep8-core @PyCQA/pylint-dev @PyCQA/pydocstyle-dev
I haven't written much, but I want to get feedback from y'all while writing this. Some things I'd like us to agree upon: