Initial version [DEPRECATED] #1
Conversation
Signed-off-by: MiroDudik <[email protected]>
Signed-off-by: MiroDudik <[email protected]>
Signed-off-by: MiroDudik <[email protected]>
Signed-off-by: MiroDudik <[email protected]>
Signed-off-by: MiroDudik <[email protected]>
Signed-off-by: MiroDudik <[email protected]>
MiroDudik
requested review from
achould,
adrinjalali and
romanlutz
and removed request for
achould and
adrinjalali
|
Tagging for review: @adrinjalali @achould @hannawallach @hildeweerts @d19fe8 @riedgar-ms @romanlutz @mesameki @mmadaio |
|
|
||
| **3.4.1 Resignation**. Written notice of resignation to the SC. | ||
|
|
||
| **3.4.2 Unreachable Member**. If a member is unresponsive at their listed handle for more than one month the SC may vote to remove the member. |
There was a problem hiding this comment.
happy to add, but I think it's redundant (since we have the "voting" section above).
There was a problem hiding this comment.
Actually, I think I'm going to update here, because as written it's somewhat ambiguous. I believe it should be 3/4 since it concerns adding / removing a member.
|
|
||
| **3.4.2 Unreachable Member**. If a member is unresponsive at their listed handle for more than one month the SC may vote to remove the member. | ||
|
|
||
| **3.4.3 Violation of Policies or Duties of Membership**. If the SC by 3/4 affirmative vote finds that member—after member has had notice and opportunity to be heard on the issue—has violated any material provision of this Charter or other Organization policies or procedures. |
There was a problem hiding this comment.
Not sure what you mean by 'affirmative vote' here. Does "3/4" refer to the membership of the committee, or the membership of the committee who vote?
There was a problem hiding this comment.
"Affirmative" just means "voting yes". The question about 3/4 of "whom" stands though. I believe it should be at least 3/4 of all members excluding the one voted on (so not just the "members present").
| In addition: | ||
| * You may not use or register, in whole or in part, the Marks as part of your own trademark, service mark, domain name, company name, trade name, product name or service name. | ||
| * Trademark law does not allow your use of names or trademarks that are too similar to ours. You therefore may not use an obvious variation of any of our Marks or any phonetic equivalent, foreign language equivalent, takeoff, or abbreviation for a similar or compatible product or service. | ||
| * You agree that you will not acquire any rights in the Marks and that any goodwill generated by your use of the Marks and participation in our community inures solely to our benefit. |
There was a problem hiding this comment.
"inures solely to our benefit" is a bit of a change of writing style. Firstly, I had to double-check the meaning of 'inure' and secondly, 'solely to our benefit' should probably be 'to the benefit of the Organization' or something like that.
There was a problem hiding this comment.
Re. "inures": I agree that it sounds a bit too lawyerly, but I'm in favor of keeping it for now--it is based on a standard text: http://modeltrademarkguidelines.org/index.php/Model_Trademark_Guidelines . Apache or GNU license are quite lawyerly too, I view this one similarly. Are we okay keeping that as is?
Re. "our benefit": I think that it is actually more consistent with the text so far to stick to "our benefit" similar to "our work" and "our software" and "our Marks", which we use extensively earlier. Also the standard text on which this is based is just using "our benefit". Can we keep as is?
|
|
||
| ## Enforcement | ||
|
|
||
| Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement `[at ... | as set forth in the repository's ... file | ... ]`. All complaints will be reviewed and investigated promptly and fairly. |
There was a problem hiding this comment.
We need to decide how to report violations of code of conduct. I'm considering three options:
- Set up a specific e-mail address at gmail.com, which would be forwarded to somebody on the SC.
- Say that anybody on the SC could be e-mailed (in which case SC needs to be reachable?).
- Take advantage of GitHub functionality, which however seems to only be open to "contributors and collaborators" (we should test what exactly that means in practical terms).
There was a problem hiding this comment.
the CoC team can, and IMO should be different from the SC
There was a problem hiding this comment.
I agree in principle. Not sure we have that many people right now...
There was a problem hiding this comment.
I completely agree that CoC violations team could be different than the SC, but if so, who should be on it? I guess we as the SC should make a decision on this.
@adrinjalali , @romanlutz , @hildeweerts : I'm personally leaning towards just starting off with the SC, but if you'd rather this be separate from the SC, we could try to ask some community members (around two?) to be responsible for this. Thoughts?
If there is no strong sentiment either way, I'd just default to:
Instances ... may be reported to any of the Steering Committee members by e-mail.
The person who's reporting a violation has a choice to pick among the SC members, which will compensate a bit for possible conflicts of interests. It says "by e-mail," although we do not officially list our e-mails anywhere...
There was a problem hiding this comment.
I like the idea to be able to report to individuals rather than the entire COC/SC/maintainer team, so people can report to whoever they feel most comfortable with. Possibly include all maintainers instead of just the SC?
If it also includes reinforcement, I honestly don’t really know what that would/should look like, so I find this a bit difficult to form an opinion on.
There was a problem hiding this comment.
Being on the CoC team is really hard when a report comes in. It also takes a significant amount of cognitive and emotional load. I'm happy for anybody who wants to be on the CoC team, to be on it, but I don't think it's reasonable to expect everybody on the SC team, or the maintainer team, to be on it. I don't mind it if the CoC team is initially the same as the SC team. I'd suggest naming those people instead of saying the SC team (asking them beforehand if they want to be on it of course), and have users/contributors/folks report to any individual on that team as they wish. The team then takes care of it.
There was a problem hiding this comment.
Looking at most other projects, the standard mechanism is to just e-mail a dedicated to code-of-conduct e-mail address. Shall we use something like fairlearn-conduct at gmail (or some other e-mail provider?). I'm not sure how many e-mails at python.org we can ask to own :-)
Signed-off-by: MiroDudik <[email protected]>
| @@ -0,0 +1,84 @@ | |||
| # Contributor Covenant Code of Conduct | |||
There was a problem hiding this comment.
should we just go with psf's CoC instead of writing one?
There was a problem hiding this comment.
This one is actually taken from:
https://www.contributor-covenant.org/version/2/0/code_of_conduct/ (the license details are at the bottom)
I wasn't familiar with it, but I like it, because of how concise and clear it is.
By PSF's CoC, did you mean this one: https://www.python.org/psf/conduct/
I just glanced at it, and I think it would take some time to rewrite it (because it invokes some very PSF-specific venues / events etc.). I don't see a large substantive difference between "Our Standards" sections of the two CoCs. The largest difference is in how they go about "Enforcement". The Contributor Covenant version (the one here) is I think clearer in describing consequences of CoC violations whereas PSF's CoC does a good job at outlining the procedure of an investigation.
My proposal is to stick to the Contributor Covenant version, but if there are investigations we could draw inspiration from the PSF's procedure.
Thoughts?
There was a problem hiding this comment.
I guess my point is not to write our own CoC at all. CoCs evolve, and I think it's not something we necessarily want to maintain ourselves. We're also in the Python/PyData ecosystem, so having those same CoCs kinda makes sense.
In terms of venues and events, PSF can set the standards for the events and venues they sponsor and own, but it doesn't mean other non-PSF projects can't abide by the same rules of play.
So my suggestion would be to have a very short CoC section, which says we want people to feel safe, and now harassment is tolerated, and that we follow PSF's CoC, for details refer to that CoC.
It shortens the document substantially. I'm still not happy about how long the whole thing is (including the trademark and antitrust parts)
There was a problem hiding this comment.
I dug around a little bit and then remembered that early on we had asked a colleague who has studied GitHub communities for feedback re. our repository, and they suggested that we should adopt our own projects-specific code of conduct, and also suggested contributor covenant. (They in fact commented that project-specific CoC is better than just linking to GitHub community guidelines, as we do in our docs currently.)
That also seemed a recommended practice here.
So I'm starting to lean towards our own CoC. There are also some additional pragmatic reasons--we should be aware of any changes in CoC.
There was a problem hiding this comment.
If we prefer something shorter, we could possibly use Contributor Covenant 1.4.
|
|
||
| ## Enforcement | ||
|
|
||
| Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement `[at ... | as set forth in the repository's ... file | ... ]`. All complaints will be reviewed and investigated promptly and fairly. |
There was a problem hiding this comment.
the CoC team can, and IMO should be different from the SC
Signed-off-by: MiroDudik <[email protected]>
|
Please look at the new pull request #2 for the updated version. I'm not quite sure why, but my forked repository somehow got disconnected, so I wasn't able to update this pull request. |
MiroDudik
changed the title
MiroDudik
changed the title
MiroDudik
changed the title
|
@MiroDudik shall we close this PR? |
Please look at the new pull request #2. I'm just keeping this PR here for the time being to retain the discussion.
The goal of this PR is to set up the governance along the following lines:
Fairlearn organization may consist of multiple projects, but it will start off with just a single project “Fairlearn”.
Roles: Project Maintainers, Steering Committee, Advisory Board
Project Maintainers:
Steering Committee = subset of Maintainers with the "executive function":
Advisory Board = domain experts that set aside some time to help with Fairlearn.
Initial Maintainers: Roman, Richard, Michael, Miro, Adrin, Hilde
Initial Advisory Board: Hanna, Mehrnoosh, Alex, Ken
Initial Steering Committee: Miro, Hilde, Adrin, Roman