Add governance and contributing docs

Summary: tsia

Test Plan: n/a

Reviewers: zasgar, vihang

Reviewed By: zasgar

Differential Revision: https://phab.corp.pixielabs.ai/D8257

GitOrigin-RevId: 3dadc88a3c8b17ae74006478509aea4d319a4374

CONTRIBUTING.md

+# Contributing Guidelines
+
+Pixie welcomes contributions from the community. This document outlines the conventions that should be followed when making a contribution.
+
+## Contact Us
+For any questions regarding Pixie or the contribution process, feel free to reach out to us:
+
+- Email: community@pixielabs.ai
+- Slack: [slackin.withpixie.ai](slackin.withpixie.ai)
+
+## Where to start?
+You can contribute to Pixie in many ways. This includes, but is not limited to:
+
+- Bug and feature reports
+- Documentation 
+- Development of features and bug fixes
+
+If you are interested in helping us shape our community, you can also [apply here](https://pixielabs.ai/community/) to be a Pixienaut.
+
+## Contribution Process
+### Reporting Bugs and Creating Issues
+Reporting bugs is one of the most helpful ways to contribute to Pixie. Bugs may be reported by filing a Github issue in the appropriate repository. For bugs regarding Pixie, file an issue in the `pixie` repo. For reporting inaccurate documentation, file an issue in the `pixie-docs` repo, etc. Please follow the template when filing an issue and provide as much information as possible.
+
+Before reporting a bug, we encourage you to search the existing Github issues to ensure that the bug has not already been filed. 
+
+### Code Contributions
+The project is still in its early stages, and we are a small team actively working on delivering our roadmap. For all changes, regardless of size, please create a Github issue that details the bug or feature being addressed before submitting a pull request. In the Github issue, contributors may discuss the viability of the solution, alternatives, and considerations. 
+
+#### Contribution Roadmap
+As we are still an early-stage open source project, more changes to the contribution guidelines will follow in the coming months. We are actively working on opening our JIRA for issue tracking.
+
+#### Contribution Flow
+1. Steps to making a code contribution to Pixie will generally look like the following:
+2. Fork the repository on Github.
+3. Create a new branch.
+4. Make your changes in organized commits.
+5. Push your branch to your fork.
+6. Submit a pull request to the original repository.
+7. Make any changes as requested by the maintainers.
+8. Once accepted by a maintainer, it will be merged into the original repository by a maintainer.
+
+#### Contribution Checklist
+When making a contribution to the repository, please ensure that the following is addressed.
+
+1. Code follows Pixie’s coding style guide.
+2. All existing tests must pass, and new tests must be added for the bug/feature in question.
+3. Contributor License agreement must be signed.
+
+#### Coding Style
+Please refer to the style guide directory for more details.
+
+#### Commit Messages
+Commit messages should provide enough information about what has changed and why. Please follow the templates for how this information should be detailed.
+
+#### CLA
+All code contributions require the [Contributor License Agreement](https://github.com/pixie-labs/pixie/blob/main/CLA.md). The CLA can be signed when creating your first PR.

GOVERNANCE.md

+# The Project
+Pixie (The Project) is an open source software project. The goal of The Project is to develop open source software and enable out-of-the-box visibility into developer’s Kubernetes applications. The Software developed by The Project is released under the Apache 2.0 license and is developed openly and hosted in public Github/Phabricator Repositories under the PixieLabs organization. Examples of Project Software include the Pixie core library, Pixie Python API, Pixie Go API, and Pixie documentation.
+
+The Project is developed by a distributed team of developers, called Contributors. Contributors are individuals who have contributed code, documentation, designs, user support, or other work to one or more Project repositories. Anyone can be a Contributor. Contributors can be affiliated with any legal entity or none. Contributors participate in the project by submitting, reviewing and discussing Code Contributions and Issues and participating in open and public Project discussions on GitHub, JIRA, Phabricator, Slack, and mailing lists. The foundations of Project participation are openness and transparency.
+
+[Here](https://github.com/pixie-labs/pixie/blob/main/AUTHORS) is a list of some code Contributors to the main Pixie repository.
+
+The Project Community consists of all Contributors and Users of the Project. Contributors work on behalf of and are responsible to the larger Project Community and we strive to keep the barrier between Contributors and Users as low as possible.
+
+# Governance
+This section describes the governance and leadership model of The Project.
+
+The foundations of Project governance are:
+
+- Openness & Transparency
+- Active Contribution
+- Institutional Neutrality
+
+The following structure will remain in place until May 2023, at which point at the sole discretion of the BDFL we will revisit the structure. The proposed future structure is a semi-democratic process for selecting project leadership.
+
+## BDFL
+The Project will have a BDFL (Benevolent Dictator for Life), who is currently Zain Asgar, and a Deputy BDFL, who is Michelle Nguyen. As Dictator, the BDFL has the authority to make all final decisions for The Project. As Benevolent, the BDFL, in practice chooses to defer that authority to the consensus of the community discussion channels and the Governance Board (see below). It is expected, and in the past has been the case, that the BDFL will only rarely assert their final authority. Because rarely used, we refer to BDFL’s final authority as a “special” or “overriding” vote. When it does occur, the BDFL override typically happens in situations where there is a deadlock in the Governance Board or if the Governance Board asks the BDFL to make a decision on a specific matter. The BDFL is chair of the Governance Board (see below) and may delegate their authority on a particular decision or set of decisions to any other Board member at their discretion.
+
+## Governance Board
+The project will have a governance board that consists of two project members, two community members, and two end-user community members. The overall role of the Board is to ensure, working with the BDFLs and taking input from the Community, a long-term well-being of the project, both technically and as a community. 
+
+The Governance Board and its Members play a special role in certain situations. In particular, the Board may:
+
+- Make decisions about the overall scope, vision and direction of the project.
+- Make decisions about strategic collaborations with other organizations or individuals.
+- Make decisions about specific technical issues, features, bugs and pull requests. They are the primary mechanism of guiding the code review process and merging pull requests.
+- Make decisions about the Services that are run by The Project and manage those Services for the benefit of the Project and Community.
+- Make decisions when regular community discussion doesn’t produce consensus on an issue in a reasonable time frame.
+
+### Board Membership
+All community and end-user community member positions are appointed for 12-months and are expected to rotate under the consensus and discretion of the BDFLs.
+
+To become eligible for a Community Member board position, an individual should meet some of the following criteria:
+
+- Be a Project Contributor who has produced contributions that are substantial in quality and quantity.
+- Sustain this development consistently over several months.
+- Support the community through various activities (some examples below):
+  - code review
+  - answering user questions
+  - triaging bug reports
+  - participating constructively in broader conversations
+  - contributing to documentation
+  - maintaining infrastructure
+- Demonstrate breadth by supporting the community outside of their particular work interests or sub-project
+- Be civil in public discourse
+
+We are currently looking to fill the position for two end-user community members! Please reach out to the Pixie project team to apply.
+
+## Conflict of interest
+It is expected that the Governance Board and BDFL will be employed at a wide range of companies, universities and non-profit organizations. Because of this, it is possible that Members will have conflict of interests. Such conflict of interests include, but are not limited to:
+
+- Financial interests, such as investments, employment, or contracting work, outside of The Project that may influence their work on The Project.
+- Access to proprietary information of their employer that could potentially leak into their work with the Project.
+- An issue where the person privately gains an advantage from The Project resources, but The Project has no gain or suffers a disadvantage.
+
+All members of the Governance Board, BDFL included, shall disclose to the rest of the Board any conflict of interest they may have. If the BDFL has recused themselves for a particular decision, they will appoint the deputy BDFL for that decision. If the deputy BDFL has also recused themselves for that decision, they will appoint a substitute BDFL.
+
+## Voting
+In general, the Board makes decisions by lazy consensus with a minimum of participation based on the importance of the decisions to be made. Conversations happen on public GitHub or JIRA issues for most cases, and through private e-mail for more sensitive issues.
+
+To make a decision the Board discusses the topic, a proposal is made, and a suitable wait time occurs for Board members to either agree or veto. By consensus we mean that any Board member can veto a decision with justification. By lazy we mean that not all Board members must participate, and that absence is interpreted as assent. By a minimum of participation we mean that we require the participation of a certain number of individuals based on the importance of the issue; for non-contentious issues a single Board member may move forward after a suitable time, while for contentious issues we will often require a few, often from different institutions.
+
+## Private communications of the Board
+Unless specifically required, all Board discussions and activities will be public and done in collaboration and discussion with the Project Contributors and Community. The Board will have a private mailing list that will be used sparingly and only when a specific matter requires privacy. When private communications and decisions are needed, the Board will do its best to summarize those to the Community after eliding personal/private/sensitive information that should not be posted to the public internet.
+
+# Changing the Governance Documents
+Changes to the governance documents are submitted via a GitHub/Phabricator pull request to The Project's governance document. The pull request is then refined in response to public comment and review, with the goal being consensus in the community. Since the BDFL holds ultimate authority in The Project, the BDFL has authority to act alone in accepting or rejecting changes.
+

STYLE_GUIDE/INCLUSIVE_STYLE_GUIDE.md

+# Inclusive Style Guide
+
+We write our code, documentation, review comments, and other assets with inclusivity and diversity in mind. This page is not an exhaustive reference but describes some general guidelines and examples that illustrate some best practices to follow. These are only suggestions. The author, reviewers, and project maintainers will make the final call.
+
+## Avoid ableist language
+When trying to achieve a friendly and conversational tone, problematic ableist language may slip in. This can come in the form of figures of speech and other turns of phrase. Be sensitive to your word choice, especially when aiming for an informal tone. Choose alternative words depending on the context.
+
+Things to avoid: 
+
+- Phrases referring to mental health: sanity / crazy / insane
+- Words related to physical or mental disabilities: blind / cripple / dummy
+
+How to fix ableist language:
+
+- Try replacing the word with a phrase that has no underlying negative connotations. Example: “crazy outliers” → “baffling outliers”, “dummy variable” → “placeholder variable”.
+ 
+## Use gender-neutral language
+Some points in our code, documentation and comments contain needless assumptions about the gender of a future reader, user, etc. Example: “When the user logs into his profile.”
+
+Things to avoid:
+
+- Gendered pronouns: he / she / him / her / his / hers, etc.
+- Instances of the phrases “he or she”, “his/hers”, “(s)he”, etc. All of these still exclude those who don't identify with either gender, and implicitly (slightly) favor one gender via listing it first.
+- “Guys” as a gender-neutral term, which has male associations. Usually in comments it implies anthropomorphism of inanimate objects and should be replaced with a more precise technical term. If it does refer to people, consider using “everyone”, “folks”, “people”, “peeps”, “y'all”, etc.
+- Other gendered words: “brother”, “mother”, “man”, etc.
+
+Cases that are likely fine to leave alone include:
+
+- References to a specific person (“Rachel is on leave; update this when she is back.”).
+- A name (“Guy” and “He” are both valid names).
+- A language code (“he” is the ISO 639-1 language code for Hebrew).
+- He as an abbreviation for “helium”.
+- The Spanish word “he”.
+- References to a specific fictional person (Alice, Bob, ...).
+- For new code/comments, consider using just ‘A’, ‘B’ as names.
+- Quotations and content of things like public-domain books.
+- Partner agreements and legal documents we can no longer edit.
+- Occurrences in randomly generated strings or base-64 encodings.
+- Content in a language other than English unless you are fluent in that language.
+
+How to fix gendered language:
+
+- Try rewording things to not involve a pronoun at all. In many cases this makes the documentation clearer. Example: “I tell him when I am all done.” → “I tell the owner when I am all done.” This saves the reader a tiny bit of mental pointer-dereferencing.
+- Try using singular they.
+- Try making hypothetical people plural. “When the user is done he'll probably...” → “When users complete this step, they probably...”.
+- When referring to a non-person, “it” or “one” may be good alternatives (wikipedia link).
+
+## Use racially-neutral language
+Some phrases have underlying racial connotations, or reinforce the notion that some races are better than others.
+
+Things to avoid:
+
+- Terms that reinforce the notion that one race is good or bad: blacklist, whitelist
+- Words rooted in historical events regarding race: slave, master
+
+How to fix racist language:
+
+- Replace the term with an alternative that does not change its meaning. Example: “whitelist” →  “allowlist”, “master” → “main”.
+
+# References:
+
+- https://developers.google.com/style/inclusive-documentation
+- https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md
+