Skip to content
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

Merged
merged 7 commits into from
Feb 12, 2016
Merged

Conversation

sigmavirus24
Copy link
Member

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:

  • Code of Conduct for projects:
    • Should they be mandatory or optional
    • Which should we recommend or should we only recommend one
  • Do we want a couple people responsible for maintaining the organization or should all "Owners" be responsible/capable of that?
  • Should we have some guidelines over adding new projects/Owners?

@sigmavirus24
Copy link
Member Author

My own thoughts on this:

  • We should have at least strong recommendation for projects to have a CoC and we should have one or two for projects to pick from.
  • I've been generally maintaining the organization and helping new projects into it. I've also been setting up mirrors to/from GitHub/GitLab. I'm also managing pycqa.org. I would certainly appreciate help with this, but none of you are obligated to help.
  • I'm not sure what guidelines we might want to have, but for example, if we choose to require a CoC for member projects, we might want them to adopt that prior to joining the organization.

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.

@kennethlove
Copy link

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.

@groteworld
Copy link

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 'what is strict?'.

As for the PR, the addition of Organization Managers or something similar, should be added. Sure it's only @sigmavirus24 for now, but it allows others to know that any org issues can be brought to them, as well as sets a place for other brave souls to join him.

P.S. Thanks for organizing all of this!

@sigmavirus24
Copy link
Member Author

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)?

We're not affiliated with the PSF though. That said, the Python CoC absolutely applies to code-quality@python.org but I think we shouldn't limit ourselves to the Python CoC for choices. My one major concern with using the Python CoC is that it provides no way for people to report bad behaviour. It relies on, ostensibly, a person calling out another member publicly or privately which is not the best recourse for someone violating the CoC.

I don't see why they'd have to have one before joining, though.

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.


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?

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).

@The-Compiler
Copy link
Member

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.

That sounds reasonable to me, FWIW.


- Creator: Ian Cordasco

- Pep8 Administrator: Ian Lee
Copy link
Member

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

Copy link
Member Author

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. :)

Copy link
Member

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).

@IanLee1521
Copy link
Member

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?

@sigmavirus24
Copy link
Member Author

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?

@Nurdok
Copy link
Member

Nurdok commented Jan 31, 2016 via email

@sigmavirus24
Copy link
Member Author

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).

Pydocstyle doesn't currently have a CoC

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 :)

@sigmavirus24 sigmavirus24 force-pushed the add-management branch 2 times, most recently from b85f6a1 to a671e48 Compare February 1, 2016 04:30
@sigmavirus24
Copy link
Member Author

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.

@sthenault
Copy link

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!

@sigmavirus24
Copy link
Member Author

What are we trying to solve with a code of conduct?

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.

Is there some examples in some community where having a CoC (or not having it) has actually played some role?

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.

That being said, I would go for not enforcing anything for project under the PyCQA umbrella but encouraging support of the Python's CoC.

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?

@sigmavirus24
Copy link
Member Author

unrelated PS: I would appreciate being listed in the pylint admnistrator. Thx!

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
Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. Thanks!

@sthenault
Copy link

@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.

@sigmavirus24
Copy link
Member Author

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

@groteworld
Copy link

CODE_OF_CONDUCT.rst should be updated to 1.4 as well.

@sigmavirus24
Copy link
Member Author

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).

@IanLee1521
Copy link
Member

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

@sigmavirus24
Copy link
Member Author

@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. 🍰

@IanLee1521
Copy link
Member

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.

@sigmavirus24
Copy link
Member Author

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.

@IanLee1521
Copy link
Member

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.

@sigmavirus24
Copy link
Member Author

I also think the projects should be encouraged, though potentially not forced, to establish a CoC policy.

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?

In the case of pycodestyle, it is my intention at this point to simply use the organizational one added in this PR.

I have the same intentions for:

  • Flake8
  • Mccabe
  • mccabe-console-script
  • flake8-docstrings
  • pep8-naming (which I guess needs to be renamed)

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.

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.

@IanLee1521
Copy link
Member

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 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.

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 like this idea. 👍

@sigmavirus24
Copy link
Member Author

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.

@sigmavirus24
Copy link
Member Author

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,
Ian

@Nurdok
Copy link
Member

Nurdok commented Feb 8, 2016

👍

sigmavirus24 added a commit that referenced this pull request Feb 12, 2016
Start writing management documentation
@sigmavirus24 sigmavirus24 merged commit ef95152 into master Feb 12, 2016
@sigmavirus24 sigmavirus24 deleted the add-management branch February 12, 2016 13:48
@sigmavirus24
Copy link
Member Author

It seems no objects to this so I've merged this like I said I would. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants