Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion LICENSE
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
MIT License

Copyright (c) 2020 Fairlearn
Copyright (c) Fairlearn contributors.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
Expand Down
31 changes: 31 additions & 0 deletions MEMBERS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Membership

This document lists the Steering Committee of the Organization (the "SC"), the Advisory Board of the Organization (the "AB"), and the Projects of the Organization. Members of any of the lists may be added once approved by the SC as described in the [Organization Governance](./ORG-GOVERNANCE.md) document. By adding your name to any of these lists you are agreeing to abide by all Organization polices, including
[Organization Governance](./ORG-GOVERNANCE.md),
[Code of Conduct](./code-of-conduct.md),
[Trademark Policy](./trademarks.md), and
[Antitrust Policy](./antitrust-policy.md). If you are serving on the SC or the AB on behalf of another organization (designated below), you represent that you have permission to bind that organization to these policies.

## Steering Committee (SC)

| **NAME** | **Organization** |
| --- | --- |
| Miroslav Dudik | Microsoft |
| Adrin Jalali | . |
| Roman Lutz | Microsoft |
| Hilde Weerts | . |

## Advisory Board (AB)

| **NAME** | **Organization** |
| --- | --- |
| Alexandra Chouldechova | CMU |
| Ken Holstein | CMU |
| Mehrnoosh Sameki | Microsoft |
| Hanna Wallach | Microsoft |

## Projects

| **PROJECT** | **Maintainers** | **Governance** |
| --- | --- | --- |
| [Fairlearn](https://fairlearn.github.io/) | [MAINTAINERS.md](https://github.com/fairlearn/fairlearn/blob/master/MAINTAINERS.md) | [PROJECT-GOVERNANCE.md](./PROJECT-GOVERNANCE.md) |
57 changes: 57 additions & 0 deletions ORG-GOVERNANCE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
# Charter for the Fairlearn Organization

This is the organizational charter for the Fairlearn Organization (the "Organization").
By adding their name or the name of their Project to the [MEMBERS.md](./MEMBERS.md) file, the
SC members, the AB members and the Project Maintainers agree as follows.

## 1. Mission

Provide a set of open source resources to assess and improve fairness of AI systems.

## 2. Membership

The Organization is composed of:

**2.1 Projects**. Projects consist of one or more repositories. The Projects are represented and activities in each Project are organized by its Maintainers as set forth in the Project Governance Policy.

**2.2 Steering Committee**. The Steering Committee (the "SC") is responsible for project selection, project oversight, policy oversight, and trademark management for the Organization.

**2.3 Advisory Board**. The Advisory Board (the "AB") consists of experts that advise Projects and the SC. The members of the Advisory Board can be added or removed by the SC.

## 3. Steering Committee

**3.1 Composition**. The SC voting members are listed in the [MEMBERS.md](./MEMBERS.md) file in the repository.
Voting members may be added or removed by 3/4 affirmative vote of the SC.
The SC will appoint a Chair responsible for organizing SC activity.

**3.2 Decision Making**. The SC will strive for all decisions to be made by consensus. If consensus cannot be reached, the Steering Committee will make the decision by a vote.

**3.3 Voting**. The SC Chair will call a vote with reasonable notice to the SC, setting out a discussion period and a separate voting period. Any discussion may be conducted in person or electronically by text, voice, or video. The discussion will be open to the public. In any vote, each voting representative will have one vote. Except as specifically noted elsewhere in this Charter, decisions by vote require a simple majority vote of all voting members.

**3.4 Termination of Membership**. The membership of a SC member will terminate if any of the following occur:

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

Choose a reason for hiding this comment

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

Simple majority vote?

Copy link
Member Author

@MiroDudik MiroDudik Jan 14, 2021

Choose a reason for hiding this comment

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

happy to add, but I think it's redundant (since we have the "voting" section above).

Copy link
Member Author

Choose a reason for hiding this comment

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

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

Choose a reason for hiding this comment

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

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?

Copy link
Member Author

Choose a reason for hiding this comment

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

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


## 4. Trademarks

Any names, trademarks, logos, or goodwill developed by and associated with the Organization or any of Organization's projects, however owned, may be only used in accordance with the Organization's [Trademark Policy](./trademarks.md). Member's obligations under this section survive termination of Membership.

## 5. Antitrust Policy

The SC and all of the Organization's project participants are bound by the Organization's [Antitrust Policy](./antitrust-policy.md).

## 6. No Confidentiality

Information disclosed in connection with any of the Organization's activities, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary.

## 7. Project Criteria

In order to be eligible to be an Organization project, a project must:

* Be approved by the SC.
* Be under the MIT license unless otherwise approved.
* Include and adhere to the Organization's policies.
41 changes: 41 additions & 0 deletions PROJECT-GOVERNANCE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Governance Policy

This document provides the minimum governance policy for Projects the Fairlearn Organization (the "Organization"). Maintainers agree to this policy and to abide by all of the Organization's polices, including
[Code of Conduct](./code-of-conduct.md),
[Trademark Policy](./trademarks.md), and
[Antitrust Policy](./antitrust-policy.md)
by adding their name to the Project's `MAINTAINERS.md` file.

## 1. Roles.

Each Project may include the following roles. Additional roles may be adopted and documented by the Project.

**1.1. Maintainers**. "Maintainers" are responsible for organizing activities around developing, maintaining, and updating the Project. Maintainers are also responsible for determining consensus. Each Project will designate one or more Maintainer. A Project may add or remove Maintainers with the approval of the current Maintainers (absent the maintainer being removed) or oversight of the Organization's Steering Committee ("SC").

**1.2. Contributors**. "Contributors" are those that have made Contributions to the Project.

## 2. Decisions.

**2.1. Consensus-Based Decision Making**. Projects make decisions through consensus of the Maintainers. While explicit agreement of all Maintainers is preferred, it is not required for consensus. Rather, the Maintainers will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Contributors and nature of support and objections. The Maintainers will document evidence of consensus in accordance with these requirements.

**2.2. Appeal Process**. Decisions may be appealed by opening an issue and that appeal will be considered by the Maintainers in good faith, who will respond in writing within a reasonable time. If the Maintainers deny the appeal, the appeal may be brought before the SC, who will also respond in writing in a reasonable time.

## 3. How We Work.

**3.1. Openness**. Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation.

**3.2. Balance.** The development process should have a balance of interests. Contributors from diverse interest categories shall be sought with the objective of achieving balance.

**3.3. Coordination and Harmonization.** Good faith efforts shall be made to resolve potential conflicts or incompatibility between releases in this Project.

**3.4. Consideration of Views and Objections.** Prompt consideration shall be given to the written views and objections of all Contributors.

**3.5. Written procedures.** This governance document and other materials documenting this project's development process shall be available to any interested person.

## 4. No Confidentiality.

Information disclosed in connection with any Project activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary.

## 5. Trademarks.

Any names, trademarks, logos, or goodwill arising out of the Project, however owned, may be only used in accordance with the Organization's [Trademark Policy](./trademarks.md). Maintainer's obligations under this section survive their affiliation with the Project.
3 changes: 3 additions & 0 deletions antitrust-policy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# Antitrust Policy

Participants acknowledge that they may compete with other participants in various lines of business and that it is therefore imperative that they and their respective representatives act in a manner that does not violate any applicable antitrust laws and regulations. This Policy does not restrict any participant from engaging in similar specification development projects. Each participant may design, develop, manufacture, acquire or market competitive deliverables, products, and services, and conduct its business, in whatever way it chooses. No Participants are obligated to announce or market any products or services. Without limiting the generality of the foregoing, participants agree not to have any discussion relating to any product pricing, methods or channels of product distribution, division of markets, allocation of customers or any other topic that should not be discussed among competitors.
84 changes: 84 additions & 0 deletions code-of-conduct.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
# Contributor 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.

should we just go with psf's CoC instead of writing one?

Copy link
Member Author

Choose a reason for hiding this comment

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

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?

Copy link
Member

Choose a reason for hiding this comment

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

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)

Copy link
Member Author

@MiroDudik MiroDudik Apr 1, 2021

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

If we prefer something shorter, we could possibly use Contributor Covenant 1.4.


## Our Pledge

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

## Our Standards

Examples of behavior that contributes to a positive environment for our community include:

* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

* The use of sexualized language or imagery, and sexual attention or
advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email
address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting

## Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

## Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

## 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.
Copy link
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

the CoC team can, and IMO should be different from the SC

Copy link
Member

Choose a reason for hiding this comment

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

I agree in principle. Not sure we have that many people right now...

Copy link
Member Author

@MiroDudik MiroDudik Mar 5, 2021

Choose a reason for hiding this comment

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

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

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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


All community leaders are obligated to respect the privacy and security of the reporter of any incident.

## Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

### 1. Correction

**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

### 2. Warning

**Community Impact**: A violation through a single incident or series of actions.

**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

### 3. Temporary Ban

**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.

**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

### 4. Permanent Ban

**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

**Consequence**: A permanent ban from any sort of public interaction within the project community.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0,
available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.

Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).

[homepage]: https://www.contributor-covenant.org

For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
46 changes: 46 additions & 0 deletions trademarks.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Trademark Policy

## Introduction

This is the Organization's policy for the use of our trademarks. While our work is available under free and open source software licenses, those licenses do not include a license to use our trademarks.

This policy describes how you may use our trademarks. Our goal is to strike a balance between: 1) our need to ensure that our trademarks remain reliable indicators of the quality software we release; and 2) our community members' desire to be full participants in our Organization.

## Our trademarks

This policy covers the name of the Organization and each of the Organization's projects (the "Projects"), as well as any associated logos, trade dress, goodwill, or designs (our "Marks").

## In general

Whenever you use our Marks, you must always do so in a way that does not mislead anyone about exactly who is the source of the software. For example, you cannot say you are distributing the "Mark" software when you're distributing a modified version of it because people would think they would be getting the same software that they can get directly from us when they aren't. You also cannot use our Marks on your website in a way that suggests that your website is an official Organization website or that we endorse your website. But, if true, you can say you like the "Mark" software, that you participate in the "Mark" community, that you are providing an unmodified version of the "Mark" software, or that you wrote a book describing how to use the "Mark" software.

This fundamental requirement, that it is always clear to people what they are getting and from whom, is reflected throughout this policy. It should also serve as your guide if you are not sure about how you are using the Marks.

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

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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?


## Distribution of unmodified source code or unmodified executable code we have compiled

When you redistribute an unmodified copy of our software, you are not changing the quality or nature of it. Therefore, you may retain the Marks we have placed on the software to identify your redistribution. This kind of use only applies if you are redistributing an official Project distribution that has not been changed in any way.

## Distribution of executable code that you have compiled, or modified code

You may use any word Marks, but not any Organization logos, to truthfully describe the origin of the software that you are providing, that is, that the code you are distributing is a modification of our software. You may say, for example, that "this software is derived from the source code for 'Mark' software."

Of course, you can place your own trademarks or logos on versions of the software to which you have made substantive modifications, because by modifying the software, you have become the origin of that exact version. In that case, you should not use our Marks.

However, you may use our Marks for the distribution of code (source or executable) on the condition that any executable is built from an official Project source code and that any modifications are limited to switching on or off features already included in the software, translations into other languages, and incorporating minor bug-fix patches. Use of our Marks on any further modification is not permitted.

## Statements about your software's relation to our software

You may use the word Marks, but not the Organization's logos, to truthfully describe the relationship between your software and ours. Our Mark should be used after a verb or preposition that describes the relationship between your software and ours. So you may say, for example, "Bob's software for the 'Mark' platform" but may not say "Bob's 'Mark' software." Some other examples that may work for you are:

* [Your software] uses "Mark" software
* [Your software] is powered by "Mark" software
* [Your software] runs on "Mark" software
* [Your software] for use with "Mark" software
* [Your software] for "Mark" software

These guidelines are based on the [Model Trademark Guidelines](http://www.modeltrademarkguidelines.org), used under a [Creative Commons Attribution 3.0 Unported license](https://creativecommons.org/licenses/by/3.0/deed.en_US).