feat!: Publish v1.0.0

CODE_OF_CONDUCT.md

@@ -0,0 +1,4 @@
+# Code of Conduct
+
+The Code of Conduct, which applies to this project, can be found at
+https://github.com/nodejs/admin/blob/HEAD/CODE_OF_CONDUCT.md

CONTRIBUTING.md

@@ -1,52 +1,34 @@
+# Contributing to orchestrion-js
 
-# Welcome
+## Code of Conduct
 
-Welcome! We are glad you are interested in contributing to Orchestrion-JS. This guide will help you understand the requirements and guidelines to improve your contributor experience.
+Please read the
+[Code of Conduct](https://github.com/nodejs/admin/blob/main/CODE_OF_CONDUCT.md)
+which explains the minimum behavior expectations for contributors.
 
-## Contributing to code
+<a id="developers-certificate-of-origin"></a>
+## Developer's Certificate of Origin 1.1
 
-### New features
+By making a contribution to this project, I certify that:
 
-If you want to contribute with a new feature, before start writing any code, you will need to get your proposal accepted by the maintainers. This is to avoid going through the effort of writing the code and getting it rejected because it is already being worked on in a different way, or it is outside the scope of the project.
+* (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
 
-Open a new issue with the title "[RFC] Title of your proposal". In the description explain carefully why you think this feature is needed, why it is useful, and how you plan to implement it.
+* (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
 
-The maintainers will label the issue as `type/feature` or `type/major_change` and `rfc/discussion` and will start a conversation with you to discuss it. If the proposal gets accepted it will be tagged as `rfc/approved`. Feel free to start coding at that point and propose a PR, linking it to the issue.
-
-During the RFC process, your change proposal, alongside with implementation approaches, will get discussed with the maintainers, ensuring that you don’t waste time with wrong approaches or features that are out of scope for the project.
-
-If, after the discussion, the proposal gets rejected, the team will give you an explanation, label the issue as `rfc/rejected` and close the issue.
-
-### Bug fixes
-
-If you have identified an issue that is already labeled as `type/bug` that hasn’t been assigned to anyone, feel free to claim it, and ask a maintainer to add you as assignee.
-Once you have some code ready, open a PR, [linking it to the issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#manually-linking-a-pull-request-to-an-issue-using-the-pull-request-sidebar). Take into account that if the changes to fix the bug are not trivial, you need to follow the RFC process as well to discuss the options with the maintainers.
-
-### Setting up your development environment
-
-```bash
-$ git clone git@github.com:nodejs/orchestrion-js.git
-$ cd orchestrion-js
-$ npm install
-```
-
-### Testing your changes
-
-```bash
-npm test
-```
-
-## Contributing to issues
-
-### Contributing to reporting bugs
-
-If you think you have found a bug in Orchestrion-JS feel free to report it. When creating issues, you will be presented with a template to fill. Please, fill as much as you can from that template, including steps to reproduce your issue, so we can address it quicker.
-
-### Contributing to triaging issues
-
-Triaging issues is a great way to contribute to an open source project. Some actions you can perform on an open by someone else issue that will help addressing it sooner:
-
-- Trying to reproduce the issue. If you can reproduce the issue following the steps the reporter provided, add a comment specifying that you could reproduce the issue.
-- Finding duplicates. If there is a bug, there might be a chance that it was already reported in a different issue. If you find an already reported issue that is the same one as the one you are triaging, add a comment with "Duplicate of" followed by the issue number of the original one.
-- Asking the reporter for more information if needed. Sometimes the reporter of an issue doesn’t include enough information to work on the fix, i.e. lack of steps to reproduce, not specifying the affected version, etc. If you find a bug that doesn’t have enough information, add a comment tagging the reporter asking for the missing information.
+* (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,28 @@
+# `orchestrion-js` Project Governance
+
+## Collaborators
+
+`orchestrion-js` core collaborators maintain the
+[nodejs/orchestrion-js](https://github.com/nodejs/orchestrion-js)
+GitHub repository.
+The GitHub team for `orchestrion-js` core collaborators is
+[@nodejs/orchestrion-js-maintainers](https://github.com/orgs/nodejs/teams/orchestrion-js-maintainers). 
+Collaborators have commit access to the
+[nodejs/orchestrion-js](https://github.com/nodejs/orchestrion-js)
+repository.
+
+Both collaborators and non-collaborators may propose changes to the `orchestrion-js`
+source code. The mechanism to propose such a change is a GitHub pull request.
+Collaborators review and merge (_land_) pull requests.
+
+## PR Approval
+
+Two collaborators must approve a pull request before the pull request can land.
+Approving a pull request indicates that the collaborator accepts responsibility
+for the change. Approval must be from collaborators who are not authors of the
+change and at least one approval must be from a collaborator outside the authors
+direct team. 
+
+If a collaborator opposes a proposed change, then the change cannot land. Often,
+discussions or further changes result in collaborators removing their
+opposition.