From 8a157f24f95fd902af4fc71a2e2ba7876f88db81 Mon Sep 17 00:00:00 2001 From: Greg Nazario Date: Tue, 10 Oct 2023 15:21:09 -0700 Subject: [PATCH] [docs] Update license, codeowners, contribution guide --- CODEOWNERS | 7 +++ CONTRIBUTING.md | 120 ++++++++++++++++++++++++++++++++++++++++++++++++ LICENSE | 5 +- 3 files changed, 130 insertions(+), 2 deletions(-) create mode 100644 CODEOWNERS create mode 100644 CONTRIBUTING.md diff --git a/CODEOWNERS b/CODEOWNERS new file mode 100644 index 000000000..82ed3aaec --- /dev/null +++ b/CODEOWNERS @@ -0,0 +1,7 @@ +# **Please** keep this file ordered alphabetically by directory paths. + +# Owners for the `.github` directory and all its subdirectories. +/.github/ @aptos-labs/developer-platform @aptos-labs/security + +# Auto-reviewers for all code +* @aptos-labs/developer-platform diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000000000..8bc706b23 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,120 @@ +--- +id: contributing +title: Contributing to the Aptos TypeScript SDK +--- + +# Contributing + +Our goal is to make contributing to Aptos TypeScript SDK easy and transparent. See [Aptos Community](https://aptos.dev/community) +for full details. This page describes [our development process](#our-development-process). + +## Aptos SDK + +To contribute to the Aptos SDK implementation, first fork the [aptos-ts-sdk](https://github.com/aptos-labs/aptos-ts-sdk) +repository. For more information on how to fork see the [Github documentation](https://docs.github.com/en/get-started/quickstart/fork-a-repo). + +## Our Development Process +### Documentation + +Aptos's developer website is also open source (the code can be found in this +[repository](https://github.com/aptos-labs/aptos-core/tree/main/developers-docs-site/). It is built using +[Docusaurus](https://docusaurus.io/): + +If you know Markdown, you can already contribute! + +## Developer Workflow + +Changes to the project are proposed through pull requests. The general pull request workflow is as follows: + +* If you have added code that should be tested, add unit tests. +* If you have changed APIs, update the documentation. Make sure the documentation builds. +* Ensure all formatting applies with `pnpm fmt`. +* Ensure all tests and lints pass on each and every commit that is part of your pull request using `pnpm test && pnpm lint`. +* Submit your pull request. + +## Authoring Clean Commits + +### Logically Separate Commits + +Commits should be [atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) and broken down into +logically separate changes. Diffs should also be made easy for reviewers to read and review so formatting fixes or code +moves should not be included in commits with actual code changes. + +### Meaningful Commit Messages + +Commit messages are important and incredibly helpful for others when they dig through the commit history in order to +understand why a particular change was made and what problem it was intending to solve. For this reason commit messages +should be well written and conform with the following format: + +All commit messages should begin with a single short (50 character max) line summarizing the change and should skip the +full stop. This is the title of the commit. It is also preferred that this summary be prefixed with "[area]" where the +area is an identifier for the general area of the code being modified, e.g. + +``` +* [ci] enforce whitelist of nightly features +* [language] removing VerificationPass trait +``` + + +Following the commit title (unless it alone is self-explanatory), there should be a single blank line followed by the +commit body which includes more detailed, explanatory text as separate paragraph(s). It is recommended that the commit +body be wrapped at 72 characters so that Git has plenty of room to indent the text while still keeping everything under +80 characters overall. + +The commit body should provide a meaningful commit message, which: +* Explains the problem the change tries to solve, i.e. what is wrong with the current code without the change. +* Justifies the way the change solves the problem, i.e. why the result with the change is better. +* Alternative solutions considered but discarded, if any. + +### References in Commit Messages + +If you want to reference a previous commit in the history of the project, use the format "abbreviated sha1 (subject, +date)", with the subject enclosed in a pair of double-quotes, like this: + +```bash +Commit 895b53510 ("[consensus] remove slice_patterns feature", 2019-07-18) noticed that ... +``` + +This invocation of `git show` can be used to obtain this format: + +```bash +git show -s --date=short --pretty='format:%h ("%s", %ad)' +``` + +If a commit references an issue please add a reference to the body of your commit message, e.g. `issue #1234` or ` +fixes #456`. Using keywords like `fixes`, `resolves`, or `closes` will cause the corresponding issue to be closed when +the pull request is merged. + +Avoid adding any `@` mentions to commit messages, instead add them to the PR cover letter. + +## Responding to Reviewer Feedback + +During the review process a reviewer may ask you to make changes to your pull request. If a particular commit needs to +be changed, that commit should be amended directly. Changes in response to a review *should not* be made in separate +commits on top of your PR unless it logically makes sense to have separate, distinct commits for those changes. This +helps keep the commit history clean. + +If your pull request is out-of-date and needs to be updated because `main` has advanced, you should rebase your branch +on top of the latest main by doing the following: + +```bash +git fetch upstream +git checkout branch +git rebase -i upstream/main +``` + +You *should not* update your branch by merging the latest main into your branch. Merge commits included in PRs tend to +make it more difficult for the reviewer to understand the change being made, especially if the merge wasn't clean and +needed conflicts to be resolved. As such, PRs with merge commits will be rejected. + +## Bisect-able History + +It is important that the project history is bisect-able so that when regressions are identified we can easily use +`git bisect` to be able to pin-point the exact commit which introduced the regression. This requires that every commit +is able to be built and passes all lints and tests. So if your pull request includes multiple commits be sure that each +and every commit is able to be built and passes all checks performed by CI. + +## Issues + +The Aptos SDK uses [GitHub issues](https://github.com/aptos-labs/aptos-ts-sdk/issues) to track bugs. Please include +necessary information and instructions to reproduce your issue. diff --git a/LICENSE b/LICENSE index 261eeb9e9..f146f2b23 100644 --- a/LICENSE +++ b/LICENSE @@ -1,3 +1,6 @@ +Copyright © Aptos Foundation +SPDX-License-Identifier: Apache-2.0 + Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ @@ -186,8 +189,6 @@ same "printed page" as the copyright notice for easier identification within third-party archives. - Copyright [yyyy] [name of copyright owner] - Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at