Add files via upload

AUTHORS.md

@@ -0,0 +1,19 @@
+# Authors
+
+Inching's development is coordinated by a group of *principal developers*,
+who are also its main software contributors and who can be contacted in case of
+questions about Inching. In addition, there are *contributors* who have
+provided substantial additions or modifications to the software or to the 
+manuscript.
+
+`XXXXXX`
+
+## Principal Developers
+
+* Jordy Homing Lam, University of Southern California (Lead Contact)
+
+## Contributors 
+
+* Jordy Homing Lam, University of Southern California
+* Aiichiro Nakano, University of Southern California
+* Vsevolod Katritch, University of Southern California

CODE_OF_CONDUCT.md

@@ -0,0 +1,127 @@
+# Contributor Covenant Code of Conduct
+
+## 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, phone number, lineage, under any circumstances.
+* 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 Jordy Homing Lam.
+All complaints will be reviewed and investigated promptly and fairly.
+
+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 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.

CONTRIBUTING.md

@@ -0,0 +1,53 @@
+# Contributing
+
+Inching is an open-source project and we are very happy to accept contributions
+from the community. Please feel free to open issues or submit patches (preferably
+as pull requests) any time. For planned larger contributions, it is often
+beneficial to get in contact with one of the principal developer, Jordy Homing Lam first.
+
+Inching and its contributions are licensed under the MIT license (see
+[LICENSE.md](LICENSE.md)). As a contributor, you certify that all your
+contributions are in conformance with the *Developer Certificate of Origin
+(Version 1.1)*, which is reproduced below.
+
+## Developer Certificate of Origin (Version 1.1)
+The following text was taken from
+[https://developercertificate.org](https://developercertificate.org):
+
+    Developer Certificate of Origin
+    Version 1.1
+
+    Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+    1 Letterman Drive
+    Suite D4700
+    San Francisco, CA, 94129
+
+    Everyone is permitted to copy and distribute verbatim copies of this
+    license document, but changing it is not allowed.
+
+
+    Developer's Certificate of Origin 1.1
+
+    By making a contribution to this project, I certify that:
+
+    (a) The contribution was created in whole or in part by me and I
+        have the right to submit it under the open source license
+        indicated in the file; or
+
+    (b) The contribution is based upon previous work that, to the best
+        of my knowledge, is covered under an appropriate open source
+        license and I have the right under that license to submit that
+        work with modifications, whether created in whole or in part
+        by me, under the same open source license (unless I am
+        permitted to submit under a different license), as indicated
+        in the file; or
+
+    (c) The contribution was provided directly to me by some other
+        person who certified (a), (b) or (c) and I have not modified
+        it.
+
+    (d) I understand and agree that this project and the contribution
+        are public and that a record of the contribution (including all
+        personal information I submit with it, including my sign-off) is
+        maintained indefinitely and may be redistributed consistent with
+        this project or the open source license(s) involved.

GOVERNANCE.md

@@ -0,0 +1,190 @@
+# Inching Project Governance Document
+
+Welcome to the Inching community. Inching is an open, community-driven project for
+machine learning model serving.
+
+Inching takes a meritocratic, consensus-based approach to its governance structure.
+Anyone with an interest in the project can join the community, contribute to the project
+and participate in the decision making process. And this is a living document aiming to
+outline how that participation takes place.
+
+* Contribution guidelines: https://github.com/jhmlam/Inching/blob/main/CONTRIBUTING.md
+* Code of Conduct: https://github.com/jhmlam/Inching/blob/main/CODE_OF_CONDUCT.md
+* Development guidelines: https://github.com/jhmlam/Inching/blob/main/DEVELOPMENT.md
+
+
+
+## Roles And Responsibilities
+
+#### Contributors
+
+Contributors are community members who contribute in concrete ways to the project.
+Anyone can become a contributor, and contributions can take many forms, as detailed in
+the [Inching Contribution Guidelines](https://github.com/jhmlam/Inching/blob/main/CONTRIBUTING.md).
+There is no expectation of commitment to the project, no specific skill requirements and
+no selection process.
+
+As a contributor, you may find yourself doing one or more of the following:
+
+* Support new users by answering questions on the
+    [github issue tracker](https://github.com/jhmlam/Inching/issues)
+* Report issues you're facing and "Thumbs up" on issues and feature requests that are
+    relevant to you in Inching's [issue tracker](https://github.com/jhmlam/Inching/issues).
+* Investigate bugs and reviewing other developer's pull requests.
+* Contribute code or documentation to the project by submitting a Github pull request.
+* Create new example projects and contribute it to [Inching/examples](https://github.com/jhmlam/Inching/tree/main/examples).
+
+
+Contributors engage with the project through the issue tracker and mailing list. They
+submit code or documentation changes to the project via github pull request, which will
+be reviewed by the Core Team members (see next section).
+
+The [issue tracker](https://github.com/jhmlam/Inching/issues)
+is the most appropriate place to ask for help or get feedback when making contributions.
+
+As contributors gain experience and familiarity with the project, their profile within,
+and commitment to, the community will increase. At some stage, they may find themselves
+being nominated for the Inching Core Team.
+
+
+#### Core Team
+
+The Inching Core Team consist of contributors who have produced contributions that are
+substantial in quality and quantity. The core team members has additional
+responsibilities over those of a contributor. These responsibilities ensure the smooth
+running of the project:
+
+* Managing the Inching code and documentation
+* Managing QA and new releases
+* Maintaining a high-level technical direction and roadmap
+* Project governance decisions and changes
+* Coordination of core team, contributors and users
+* Managing the membership of the core team
+* Make final decisions when regular community discussion doesn’t produce consensus on
+    an issue in a reasonable time frame.
+
+
+Members of the Core Team do not have significant authority over other members of the
+community, although it is the Core Team that votes on new Core Team members. It also
+makes decisions when community consensus cannot be reached.
+
+A contributor who shows an above-average level of contribution to the project,
+particularly with respect to its strategic direction and long-term health, may be
+nominated to become a member of the Core Team, by existing Core Team members. A
+nomination will result in discussion and then a vote by the existing Core Team members.
+Core Team membership votes are subject to consensus approval of the current Core Team
+members.
+
+
+#### Benevolent dictator (project lead)
+
+The Project will have a BDFL (Benevolent Dictator for Life), who is permanently Jordy Homing Lam. 
+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 Core Team. It is expected that
+the BDFL will only rarely assert his/her final authority. Because it is 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 Core
+Team or if the Core Team asks the BDFL to make a decision on a specific matter. To
+ensure the benevolence of the BDFL, The Project encourages others to fork The Project if
+they disagree with the overall direction the BDFL is taking. The BDFL is chair of the
+Core Team and may delegate his/her authority on a particular decision or set of
+decisions to any other Core Team Member at his/her discretion.
+
+The BDFL can appoint his/her successor, but it is expected that the Core Team would be
+consulted on this decision. If the BDFL is unable to appoint a successor (e.g. due to
+death or illness), the Core Team will choose a successor by voting with at least 2/3 of
+the Core Team members voting in favor of the chosen successor. At least 80% of the Core
+Team must participate in the vote.
+
+
+#### Conflict of interest
+
+It is expected that the BDFL and Core Team Members will be employed at a wide range of
+companies, universities and non-profit organizations. Because of this, it is possible
+that Members will have conflicts of interest. Such conflicts of interest 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. All
+members of the Core Team, BDFL included, shall disclose to the rest of the Core Team any
+conflict of interest they may have. Members with a conflict of interest in a particular
+issue may participate in Core Team discussions on that issue, but must recuse themselves
+from voting on the issue. If the BDFL has recused his/herself for a particular decision,
+they will appoint a substitute BDFL for that decision.
+
+
+#### Current Core Team Members
+
+* Jordy Homing Lam (BDFL) - [@jhmlam](https://github.com/jhmlam)
+* TBD
+* TBD
+
+
+## Contribution Process
+
+Anyone can contribute to the project, regardless of their skills, as there are many ways
+to contribute. For instance, a contributor might be active on the project mailing list
+and issue tracker, or might supply patches. The various ways of contributing are
+described in more detail in the [Contribution Guidelines](https://github.com/jhmlam/Inching/blob/main/CONTRIBUTING.md).
+
+The [Inching contributor mailing list](https://groups.google.com/forum/#!forum/Inching)
+is the most appropriate place to ask for help or get feedback when making contributions.
+
+
+## Decision Making Process
+
+Decisions about the future of the project are made through discussion with all members
+of the community, from the newest user to the most experienced PMC member. All
+non-sensitive project management discussion takes place on the
+[Inching contributors mailing list](https://groups.google.com/forum/#!forum/Inching).
+
+In order to ensure that the project is not bogged down by endless discussion and
+continual voting, the project operates a policy of lazy consensus. This allows the
+majority of decisions to be made without resorting to a formal vote.
+
+
+#### Lazy consensus
+
+Decision making typically involves the following steps:
+
+* Proposal
+* Discussion
+* Vote (if consensus is not reached through discussion)
+* Decision
+
+Any community member can make a proposal for consideration by the community. In order to
+initiate a discussion about a new idea, they should send an email to the Inching
+contributors’ list or create a github issue describing the idea. This will prompt a
+review and, if necessary, a discussion of the idea. The goal of this review and
+discussion is to gain approval for the contribution. Since most people in the project
+community have a shared vision, there is often little need for discussion in order to
+reach consensus.
+
+In general, as long as nobody explicitly opposes a proposal or patch, it is recognised
+as having the support of the community. This is called lazy consensus - that is, those
+who have not stated their opinion explicitly have implicitly agreed to the
+implementation of the proposal.
+
+Lazy consensus is a very important concept within the project. It is this process that
+allows a large group of people to efficiently reach consensus, as someone with no
+objections to a proposal need not spend time stating their position, and others need
+not spend time reading such mails.
+
+For lazy consensus to be effective, it is necessary to allow at least 72 hours before
+assuming that there are no objections to the proposal. This requirement ensures that
+everyone is given enough time to read, digest and respond to the proposal. This time
+period is chosen so as to be as inclusive as possible of all participants, regardless
+of their location and time commitments.
+
+
+#### Voting
+
+Not all decisions can be made using lazy consensus. Issues such as those affecting the
+strategic direction or legal standing of the project must gain explicit approval from
+the Core Team, which will adopt the
+[Apache Foundation voting process](https://www.apache.org/foundation/voting.html).
+Every member of the community is encouraged to express their opinions in
+all discussion and all votes. However, only Core Team members have binding votes for the
+purposes of decision making.