├── _config.yml ├── mentoring ├── README.md └── mentored-contributor.md ├── CODEOWNERS ├── communication └── README.md ├── contributions ├── coding-conventions.md ├── expectations.md ├── non-code-contributions.md ├── github-workflow.md └── README.md ├── resources └── golang.md ├── README.md ├── code-of-conduct.md └── LICENSE /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-minimal -------------------------------------------------------------------------------- /mentoring/README.md: -------------------------------------------------------------------------------- 1 | # Mentoring 2 | 3 | Mailchain embraces new developers and considers mentoring an important way to foster a strong healthy community that promotes learning and collaboration. 4 | 5 | The [Mentored Contributor Program][mentored_contributor_program] is a self-paced, semi-structured learning program over the course of three months. Please see the program page for further details. 6 | 7 | [mentored_contributor_program]: 8 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Lines starting with '#' are comments. 2 | # Each line is a file pattern followed by one or more owners. 3 | 4 | # These owners will be the default owners for everything in the repo. 5 | * @robdefeo 6 | * @tboeckmann 7 | 8 | # Order is important. The last matching pattern has the most precedence. 9 | # So if a pull request only touches javascript files, only these owners 10 | # will be requested to review. 11 | *.js @octocat @github/js 12 | 13 | # You can also use email addresses if you prefer. 14 | #docs/* docs@example.com -------------------------------------------------------------------------------- /communication/README.md: -------------------------------------------------------------------------------- 1 | # Communication 2 | 3 | The Mailchain community abides by the Mailchain [code of conduct][code_of_conduct]. 4 | 5 | ## Social Media 6 | 7 | * [@mailchain_xyz on Twitter][twitter] 8 | * [Mailchain's blog][blog] 9 | 10 | ## Community Chat 11 | 12 | [Join Discord][join_discord] - sign up and join the conversation or have your questions answered by the team and the community. 13 | 14 | --- 15 | 16 | ## Feature Requests or Reporting A Bug 17 | 18 | ### Questions or Bugs 19 | 20 | If you have a question about Mailchain or have a problem using it, please start with the [troubleshooting guide][troubleshooting_guide]. 21 | 22 | If that doesn't answer your questions, or if you think you found a bug, please [file an issue][file_an_issue]. 23 | 24 | ### Features and Improvements 25 | 26 | Think a feature is missing? [Open a feature request][open_feature_request] to start a conversation to bring it to our attention. Your comments are appreciated. 27 | 28 | We may also turn it into a Mailchain Improvement Proposal if it requires further deep discussion. 29 | 30 | [blog]: 31 | [code_of_conduct]: 32 | [file_an_issue]: 33 | [github_office_hours]: 34 | [open_feature_request]: 35 | [join_discord]: 36 | [troubleshooting_guide]: 37 | [twitter]: 38 | -------------------------------------------------------------------------------- /contributions/coding-conventions.md: -------------------------------------------------------------------------------- 1 | # Code Conventions 2 | 3 | ## Go 4 | 5 | * [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments) 6 | * [Effective Go](https://golang.org/doc/effective_go.html) 7 | * Know and avoid [Go landmines](https://gist.github.com/lavalamp/4bd23295a9f32706a48f) 8 | 9 | * Comment your code. 10 | * [Go's commenting conventions](http://blog.golang.org/godoc-documenting-go-code) 11 | * If reviewers ask questions about why the code is the way it is, that's a sign that comments might be helpful. 12 | * Command-line flags should use dashes, not underscores 13 | 14 | * Naming 15 | * Please consider package name when selecting an interface name, and avoid redundancy. e.g.: `storage.Interface` is better than `storage.StorageInterface`. 16 | * These articles will explain how to organize your Go packages: 17 | * 18 | * 19 | * 20 | * [Design philosophy for packages](https://www.goinggo.net/2017/02/design-philosophy-on-packaging.html) 21 | * Do not use uppercase characters, underscores, or dashes in package names. 22 | * Please consider parent directory name when choosing a package name. 23 | * protocols/ethereum/foo.go should say `package ethereum` not `package protocolsethereum`. 24 | * Unless there's a good reason, the `package ethereum` line should match the name of the directory in which the .go file exists. 25 | * Importers can use a different name if they need to disambiguate. 26 | * Properties or functions that return an objects type should use the word `kind` or `Kind`. 27 | 28 | * Locks 29 | * Locks should be called `lock` and should never be embedded (always `lock sync.Mutex`). 30 | * When multiple locks are present, give each lock a distinct name following Go conventions - `stateLock`, `mapLock` etc. 31 | -------------------------------------------------------------------------------- /resources/golang.md: -------------------------------------------------------------------------------- 1 | # GoLang resources 2 | 3 | ## Newbie 4 | 5 | First you should take the language tour: 6 | Then, you should visit: 7 | 8 | * to learn how to organize your Go workspace. 9 | * be more effective at writing Go. 10 | * learn more about the language itself. 11 | * a lot more reading material. 12 | 13 | There are some awesome websites as well: 14 | 15 | * great resources for Gophers in general. 16 | * awesome weekly podcast of Go awesomeness. 17 | * examples of how to do things in Go. 18 | * tips on how to write more idiomatic Go code. 19 | * will help you avoid gotchas in Go. 20 | * tutorials to help you get started in Go. 21 | 22 | There's also an exhaustive list of videos related to Go from various authors. 23 | If you prefer books, you can try these: 24 | 25 | * 26 | * 27 | * 28 | 29 | If you want to learn how to organize your Go project, make sure to read: . 30 | Once you are accustomed to the language and syntax, you can read this series of articles for a walkthrough the various standard library packages: . 31 | If you would like to try practising some exercises, you should vist . 32 | 33 | will give a list of even more resources to learn Go. 34 | Finally, join the Gophers slack channel . 35 | 36 | ## Package layout 37 | 38 | Read the [design philosophy](https://www.goinggo.net/2017/02/design-philosophy-on-packaging.html) for packages. 39 | 40 | These articles will explain how to organize your Go packages: 41 | 42 | * 43 | * 44 | * 45 | 46 | ## General 47 | 48 | * 49 | -------------------------------------------------------------------------------- /contributions/expectations.md: -------------------------------------------------------------------------------- 1 | # Community Expectations 2 | 3 | The foremost goal of the Mailchain community is to develop blockchain-based, simple, secure, decentralized messaging technology. 4 | 5 | We also have an equally important goal: to create a community that fosters easy, agile development of such systems. 6 | 7 | We therefore describe the expectations for members of the Mailchain community and encourage everyone to read the [code of conduct][code_of_conduct]. All particiants in the community should go above and beyond the code of conduct to promote a collaborative, respectful Mailchain community. 8 | 9 | ## Code Review 10 | 11 | As a community we believe in the value of code review for all contributions. Code review increases the quality and readability of our code base, which helps produce high quality software. 12 | 13 | See the [Github Workflow][github_workflow] for more information on code review. 14 | 15 | The community expects that all active participants in the community will also be active reviewers. Please expect reviewers to request that you avoid [common go style mistakes](https://github.com/golang/go/wiki/CodeReviewComments) in your PRs. 16 | 17 | ### Expectations of reviewers: Review comments 18 | 19 | Because reviewers are often the first points of contact between new members of the community and can significantly impact the first impression of the Mailchain community, reviewers are especially important in shaping the Mailchain community. 20 | 21 | ### Expectations of reviewers: Review latency 22 | 23 | We expect reviewers to respond in a timely fashion to pull requests assigned to them. We expect reviewers to respond to an *active* pull request with reasonable latency, and if reviewers do not respond, we may assign those pull requests to other reviewers. 24 | 25 | If reviewers are unavailable to review for some time, they should set their [user status](https://help.github.com/en/articles/personalizing-your-profile#setting-a-status) to "busy" to avoid being assigned reviews. If they are unavailable for a longer time period, we expecte them to remove themselves from the CODEOWNERS file and potentially nominate someone else. 26 | 27 | ## Thanks 28 | 29 | Many thanks in advance to everyone who contributes their time and effort to making Mailchain both a successful product and a successful community. 30 | 31 | The strength of our software is a reflection of the strengths of each individual community member. 32 | 33 | [code_of_conduct]: 34 | [github_workflow]: <./github-workflow.md> -------------------------------------------------------------------------------- /contributions/non-code-contributions.md: -------------------------------------------------------------------------------- 1 | # Non-Code Contributions 2 | 3 | *All contributors are welcome, new and old!* 4 | 5 | *If you are interested in helping define and structure this work, you can find us [on Discord][communication_discord].* 6 | 7 | ## Non-Code Contributor Guidelines 8 | 9 | We want to encourage participants to make non-code contributions to areas of the Mailchain project where their expertise can be best utilized. 10 | 11 | This list below is meant to help new contributors looking for a good entrance into the project, and current contributors who would like to do something different. 12 | 13 | Are you interested in any of the roles below? Come chat with us [on Discord][communication_discord]! 14 | 15 | ### General Project Roles 16 | 17 | These are roles that either span the project as a whole, or span several areas of the project. Most of the roles below can be considered "good-first-roles". 18 | 19 | * Community education 20 | * Answering questions on [issues](https://github.com/mailchain/mailchain/issues), [on Discord][communication_discord], etc. 21 | * Onboarding new contributors 22 | * Capturing the experiences of "Fresh Eyes" in the project 23 | * Mentoring new contributors 24 | * Documentation 25 | * [Contribute to Mailchain docs](https://docs.mailchain.xyz) 26 | * Maintaining [troubleshooting](https://docs.mailchain.xyz/troubleshooting/troubleshooting) page 27 | * Documenting new features 28 | * Press releases for new features 29 | * Translation & localization 30 | * Github management (Tags, repos, etc.) 31 | * Evangelize Mailchain 32 | * Doing demos 33 | * Finding new contributors 34 | * UX/UI Design 35 | * Outbound community work 36 | * Visual Communication 37 | * Diagrams and visual explanations of concepts 38 | * Infographic design 39 | * Icon design 40 | * Various artistic contributions to strengthen the Mailchain brand, evangelize the project, and develop community 41 | * Non-Documentation writing 42 | * Blogging about early experiences 43 | * Operational manuals 44 | * Walkthroughs 45 | * How-tos about integration experiences, tools, etc. 46 | * Maintaining this community documentation 47 | * Volunteer management 48 | * Finding/Funneling contributors 49 | * Recognition of those who contribute a lot 50 | * Recognition of projects and growth efforts 51 | * Issue Triage 52 | * Project management 53 | * Confirming ownership of tasks, issues, objects, etc. 54 | * Rectifying “owned by everyone, so owned by no-one” 55 | * Pull requests 56 | * PR triage & labeling 57 | * Editing PR text: release note, statement 58 | 59 | [communication_discord]: 60 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Mailchain Community 2 | 3 | Welcome to the Mailchain community! :wave: 4 | 5 | This is the starting point for joining the Mailchain community and contributing to the project. 6 | 7 | We welcome all kinds of activity, including improving docs, telling us what's broken, improving code, writing blogs, sharing ideas, or just about anything else that improves the quality of Mailchain. 8 | 9 | We especially :heart: pull requests! 10 | 11 | --- 12 | 13 | ## Navigating Community Pages 14 | 15 | These pages are laid out so they can be read in a sensible order or you can go directly to the section you need to reference. 16 | 17 | ### Community Guidelines 18 | 19 | * Our [code of conduct][code_of_conduct]. 20 | * Guide to [communication][communication] with the rest of the Mailchain community (chat, social channels, Office Hours call, etc.). 21 | * Community [expectations][expectations] on us and you. 22 | 23 | ### Contributing Guidelines 24 | 25 | * The [contribution guide][contribution_guide]. 26 | * How to contribute in a [non-technical way][non_code_contributions]. 27 | * How to contribute in a technical way, including following [code conventions][code_conventions] and [github workflow][github_workflow]. 28 | * How to [report bugs][report_bugs] or make [feature requests][request_features]. 29 | 30 | ## Quickstart For Contributing 31 | 32 | If you've read the [contribution guide][contribution_guide] and want to dive straight in, these topics might be useful: 33 | 34 | 1. How to [file an issue][file_an_issue]. 35 | 1. How to [find something to work on][good_first_issue]. 36 | 1. How to [fork and keep your code in sync][github_workflow]. 37 | 1. How to [open a pull request][github_workflow_pr]. 38 | 1. How to [send a Mailchain message on a testnet][docs_mailchain_testnet]. 39 | 40 | Thank you for being part of the Mailchain community :hugs: 41 | 42 | [code_of_conduct]: 43 | [code_conventions]: 44 | [contribution_guide]: 45 | [communication]: 46 | [docs_mailchain_testnet]: 47 | [expectations]: 48 | [file_an_issue]: 49 | [github_workflow]: 50 | [github_workflow_fork]: 51 | [github_workflow_pr]: 52 | [good_first_issue]: 53 | [non_code_contributions]: 54 | [report_bugs]: 55 | [request_features]: 56 | -------------------------------------------------------------------------------- /code-of-conduct.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body, size, 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. 6 | 7 | ## Our Standards 8 | 9 | Examples of behavior that contributes to creating a positive environment include: 10 | 11 | * Using welcoming and inclusive language 12 | * Being respectful of differing viewpoints and experiences 13 | * Gracefully accepting constructive criticism 14 | * Focusing on what is best for the community 15 | * Showing empathy towards other community members 16 | 17 | Examples of unacceptable behavior by participants include: 18 | 19 | * The use of sexualized language or imagery and unwelcome sexual attention or advances 20 | * Trolling, insulting/derogatory comments, and personal or political attacks 21 | * Public or private harassment 22 | * Publishing others' private information, such as a physical or electronic address, without explicit permission 23 | * Other conduct which could reasonably be considered inappropriate in a professional setting 24 | 25 | ## Our Responsibilities 26 | 27 | Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. 28 | 29 | Project maintainers 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, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. 30 | 31 | ## Scope 32 | 33 | This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. 34 | 35 | Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. 36 | 37 | ## Enforcement 38 | 39 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. 40 | 41 | Further details of specific enforcement policies may be posted separately. 42 | 43 | Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. 44 | 45 | ## Attribution 46 | 47 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at 48 | 49 | For answers to common questions about this code of conduct, see 50 | 51 | [homepage]: -------------------------------------------------------------------------------- /mentoring/mentored-contributor.md: -------------------------------------------------------------------------------- 1 | # Mentored Contributor Program 2 | 3 | ## Welcome and Summary 4 | 5 | Welcome prospective mentee! 6 | 7 | This is the first cohort of the *Mailchain Mentored Contributor Program* (but not our first time mentoring developers). 8 | 9 | The Mentored Contributor Program (MCP) will guide you through a self-paced, semi-structured learning program over the course of three months. 10 | 11 | It's geared towards developers with ambition to learn. From diving deep into blockchain ecosystems, writing better in Go, or helping decide what's next on the Mailchain roadmap, the MCP will help you gain the knowledge you need, earning credibility along the way. 12 | 13 | During the three-month period, we will work with you identify specific areas of interest and growth to fit your goals. You'll also gain a full understanding of the Mailchain application and work on your programming skills (Go, blockchain, encryption, etc.) 14 | 15 | You'll get to interact with peer contributors who are on a similar journey and work directly with experienced Mailchain developers as mentors. 16 | 17 | We will match you with a mentor best suited to your experience and area of interest. They will guide you and help you to find answers to certain problems (but maybe not give you the solution immediately). 18 | 19 | You will receive feedback on issues/PRs and have your code reviewed so that at the end of the three-month period, you'll be able to demonstrate personal and professional growth. 20 | 21 | ## Expectation 22 | 23 | What you put in correlates to what you get out. We expect you to: 24 | 25 | * Commit at least 20 hours per month. 26 | * Remain in good standing throughout the program and uphold our [Code of Conduct][code_of_conduct]. 27 | * Expect respect from mentors and peers who are in the cohort with you. 28 | * Work at your own pace but leverage standups to openly discuss your wins and blockers. 29 | * Use the standups to cover topics related to skill growth, suggested activities, and suitable issues to work on. 30 | * Be helpful and share knowledge with your peers in the cohort. 31 | * Give back and become a mentor to future cohorts. 32 | 33 | ## Development Areas & Focussed Activities 34 | 35 | We will decide these topics during bi-weekly standup/workshops. A general understanding of the entire code base is important, but there will be a focus on your area of interest. We will try to tailor activities to maximise mentee’s learning, helping become owners of parts of the code base. 36 | 37 | Examples of areas of development include: 38 | 39 | * Blockchain protocols: 40 | * ethereum 41 | * substrate 42 | * bitcoin 43 | * other 44 | * Mailchain 45 | * specification 46 | * proposals 47 | * sender 48 | * receiver 49 | * api endpoints 50 | * public key finder 51 | * storage 52 | * programmable envelopes 53 | * Mailchain Web 54 | * Angular 55 | * Tools 56 | * relay 57 | * address index 58 | * sent store 59 | * name service 60 | * cryptography 61 | * secp256k1 62 | * ed25519 63 | * sr25519 64 | * nacl 65 | * aes256cbc 66 | * Golang 67 | * GoDoc 68 | * package layout 69 | * DevOps 70 | * Travis 71 | * golangci-lint 72 | * goreleaser 73 | * cgo 74 | * wasm 75 | 76 | ### How to apply to the program 77 | 78 | Anyone can apply to the program through this [application form][mcp_application_form]. 79 | 80 | We review applications periodically and will let you know if we're able to add you to the program. In the meantime, don't hesitate to dive right in to the code! 81 | 82 | ### Other Help Resources 83 | 84 | * [Mailchain Discord][discord_mailchain] 85 | * Mentored Contributor Standups 86 | * Developer docs: every repo has a `README.md` as a starting point 87 | * General documentation on [docs.mailchain.com][docs_mailchain] 88 | 89 | Thank you to both mentees and mentors for helping us continually improve the program. 90 | 91 | :heart: We love you! :heart: 92 | 93 | [code_of_conduct]: 94 | [docs_mailchain]: 95 | [github_office_hours]: 96 | [mcp_application_form]: 97 | [discord_mailchain]: 98 | [slack_office_hours]: 99 | -------------------------------------------------------------------------------- /contributions/github-workflow.md: -------------------------------------------------------------------------------- 1 | # Github Workflow 2 | 3 | ## 1. Fork in the cloud 4 | 5 | 1. Visit 6 | 2. Click `Fork` button (top right) to establish a cloud-based fork. 7 | 8 | ## 2. Clone fork to local storage 9 | 10 | Mailchain uses Go version 1.13 with [module](https://github.com/golang/go/wiki/Modules) support, meaning it can be cloned into your folder of preference. 11 | 12 | ```sh 13 | mkdir -p $working_dir 14 | cd $working_dir 15 | git clone https://github.com/$user/mailchain.git 16 | # or: git clone git@github.com:$user/mailchain.git 17 | 18 | cd $working_dir/mailchain 19 | git remote add upstream https://github.com/mailchain/mailchain.git 20 | # or: git remote add upstream git@github.com:mailchain/mailchain.git 21 | 22 | # Never push to upstream master 23 | git remote set-url --push upstream no_push 24 | 25 | # Confirm that your remotes make sense: 26 | git remote -v 27 | ``` 28 | 29 | ## 3. Branch 30 | 31 | Get your local master up to date: 32 | 33 | ```sh 34 | cd $working_dir/mailchain 35 | git fetch upstream 36 | git checkout master 37 | git rebase upstream/master 38 | ``` 39 | 40 | Branch from it: 41 | 42 | ```sh 43 | git checkout -b myfeature 44 | ``` 45 | 46 | Then edit code on the `myfeature` branch. 47 | 48 | ## 4. Keep your branch in sync 49 | 50 | ```sh 51 | # While on your myfeature branch 52 | git fetch upstream 53 | git rebase upstream/master 54 | ``` 55 | 56 | Please don't use `git pull` instead of the above `fetch` / `rebase`. `git pull` does a merge, which leaves merge commits. These make the commit history messy and violate the principle that commits ought to be individually understandable and useful (see below). 57 | 58 | You can also consider changing your `.git/config` file via `git config branch.autoSetupRebase always` to change the behavior of `git pull`. 59 | 60 | ## 5. Commit 61 | 62 | Commit your changes. 63 | 64 | ```sh 65 | git commit 66 | ``` 67 | 68 | Likely you go back and edit/build/test some more then `commit --amend` 69 | in a few cycles. 70 | 71 | ## 6. Push 72 | 73 | When ready to review (or just to establish an offsite backup of your work), 74 | push your branch to your fork on `github.com`: 75 | 76 | ```sh 77 | git push -f ${your_remote_name} myfeature 78 | ``` 79 | 80 | ## 7. Create a pull request 81 | 82 | 1. Visit your fork at `https://github.com/$user/mailchain` 83 | 2. Click the `Compare & Pull Request` button next to your `myfeature` branch. 84 | 3. [Open](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) the pull request. 85 | 86 | ## 8. Get a code review 87 | 88 | Once your pull request has been opened it will be assigned to one or more reviewers. Those reviewers will do a thorough code review, looking for correctness, bugs, opportunities for improvement, documentation and comments, and style. 89 | 90 | Commit changes made in response to review comments to the same branch on your fork. 91 | 92 | Very small PRs are easy to review. Very large PRs are very difficult to review. 93 | 94 | ## 9. Squash and Merge 95 | 96 | Upon merge (by either you or your reviewer), all commits left on the review branch should represent meaningful milestones or units of work. Use commits to add clarity to the development and review process. 97 | 98 | Before merging a PR, squash any _fix review feedback_, _typo_, _merged_, and _rebased_ sorts of commits. 99 | 100 | It is not imperative that every commit in a PR compile and pass tests independently, but it is worth striving for. 101 | 102 | In particular, if you happened to have used `git merge` and have merge commits, please squash those away: they do not meet the above standard. 103 | 104 | A nifty way to manage the commits in your PR is to do an [interactive rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), which will let you tell git what to do with every commit: 105 | 106 | ```sh 107 | git fetch upstream 108 | git rebase -i upstream/master 109 | ``` 110 | 111 | For mass automated fixups (e.g. automated doc formatting), use one or more commits for the changes to tooling and a final commit to apply the fixup en masse. This makes reviews easier. 112 | 113 | ## Reverting a commit 114 | 115 | In case you wish to revert a commit, use the following instructions. 116 | 117 | * Create a branch and sync it with upstream. 118 | 119 | ```sh 120 | # create a branch 121 | git checkout -b myrevert 122 | 123 | # sync the branch with upstream 124 | git fetch upstream 125 | git rebase upstream/master 126 | ``` 127 | 128 | * If the commit you wish to revert is a: 129 | * **merge commit:** 130 | 131 | ```sh 132 | # SHA is the hash of the merge commit you wish to revert 133 | git revert -m 1 SHA 134 | ``` 135 | 136 | * **single commit:** 137 | 138 | ```sh 139 | # SHA is the hash of the single commit you wish to revert 140 | git revert SHA 141 | ``` 142 | 143 | * This will create a new commit reverting the changes. Push this new commit to your remote. 144 | 145 | ```sh 146 | git push ${your_remote_name} myrevert 147 | ``` 148 | 149 | [Create a Pull Request](#7-create-a-pull-request) using this branch. 150 | -------------------------------------------------------------------------------- /contributions/README.md: -------------------------------------------------------------------------------- 1 | # Contribution Guide 2 | 3 | Welcome to Mailchain. This document is a guide for how to contribute to the code base. Please read and observe our [Code of Conduct][code_of_conduct]. 4 | 5 | Browse the [open issues][open_issues] and file new ones, all feedback welcome! 6 | 7 | ## Before you get started 8 | 9 | Follow the [getting started guide][getting_started] to install, setup, and send your first message. 10 | 11 | Or follow the instructions to [send a Mailchain message on a testnet][docs_mailchain_testnet] to get hands on experience using Mailchain. 12 | 13 | ## Community Expectations 14 | 15 | Mailchain is a community project. Please review the [Community Expectations](expectations.md) for an understanding of code and review expectations. 16 | 17 | ## Your First Contribution 18 | 19 | Have you ever wanted to contribute to the coolest blockchain messaging technology? 20 | 21 | We will help you understand the organization of the Mailchain project and direct you to the best places to get started. 22 | 23 | You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged. 24 | 25 | If you have questions about the development process, join our [Discord community][communication_discord]. The Mailchain team responds regularly and will usually answer quickly. 26 | 27 | ## Find Something to Work On 28 | 29 | Help is always welcome! For example, [documentation](https://docs.mailchain.xyz) can always use improvement. 30 | 31 | If you do not know what to start on, look at the [open issues](https://github.com/mailchain/mailchain/issues) or ask in our [Discord server][communication_discord] to see who is looking for help or what's being worked on. 32 | 33 | ### Non-Code Contributions 34 | 35 | Those interested in contributing without writing code may also find ideas in the [Non-Code Contributions Guide](non-code-contributions.md). 36 | 37 | ### Code Contributions 38 | 39 | There are always clarifications to code, or renaming of functions/variables. There's always a need for more test coverage. 40 | 41 | You get the idea * if you ever see something you fix or improve, own it. The community appreciates it. 42 | 43 | ### Find a Good First Topic 44 | 45 | There are [multiple repositories](https://github.com/mailchain/) in the Mailchain organization. 46 | 47 | Taking [mailchain/mailchain](https://github.com/mailchain/mailchain) as an example, you can head to the [help wanted](https://github.com/mailchain/mailchain/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) and [good first issue](https://github.com/mailchain/mailchain/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) labels for issues that should not need in-depth knowledge of the system. 48 | 49 | The `good first issue` label shows that members have committed to providing extra help for new contributors. 50 | 51 | Please note that while several of the repositories in the Mailchain community have `good first issue` labels already, they are still being applied throughout the community. 52 | 53 | Another good approach is to find a documentation improvement, such as a missing/broken link, which will give you exposure to the code submission/review process without the added complication of technical depth. 54 | 55 | Please see [Contributing](#contributing) for the workflow. When you take on an issue, you can assign it to yourself. 56 | 57 | ### It's Easy to File an Issue 58 | 59 | Not ready to contribute code, but see something that needs work? 60 | 61 | The community encourages everyone to contribute code, but we also appreciate when someone reports an issue (AKA a problem). 62 | 63 | Raise issues under the appropriate Mailchain sub-repository. For example: open a front-end issue in [mailchain/mailchain-web](https://github.com/mailchain/mailchain-web). 64 | 65 | Adhere to the prompted guidelines while opening an issue and fill out as much as you can. This will help the community fix it. 66 | 67 | ## Contributing 68 | 69 | Mailchain is an open source project, but many of the people working on it do so as their day job. To avoid forcing people to be "at work" effectively 24/7, we want to establish some semi-formal protocols around development. Hopefully, these guidelines make things go more smoothly. If you find that this is not the case, please complain loudly. 70 | 71 | As a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays. Please never hesitate to ask a question or send a pull request. 72 | 73 | Beginners can find focused information below in [Open a Pull Request](#open-a-pull-request) and [Code Review](#code-review). 74 | 75 | ## GitHub workflow 76 | 77 | To check out the code to work on, please refer to [the GitHub Workflow Guide](./github-workflow.md). 78 | 79 | ## Open a Pull Request 80 | 81 | Pull requests (PR) follow the standard [Github pull request](https://help.github.com/articles/about-pull-requests/) process. We need to build our integration tests there as several components that need building first. 82 | 83 | ## Code Review 84 | 85 | For a brief description of the importance of code review, please read [Code Review](/contributions/expectations.md#code-review). 86 | 87 | There are two aspects of code review: giving and receiving. 88 | To make it easier for your PR to receive reviews, consider the reviewers will need you to: 89 | 90 | * follow the project [coding conventions](./coding-conventions.md) 91 | * write [good commit messages](https://chris.beams.io/posts/git-commit/) 92 | * break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue 93 | 94 | Reviewers are highly encouraged the people giving the review to revisit the [Code of Conduct](/code-of-conduct.md) and [community expectations](./expectations.md) and must go above and beyond to promote a collaborative, respectful community. 95 | 96 | When reviewing a pull request from others [The Gentle Art of Patch Review](http://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) suggests an iterative series of focuses which leads new contributors to positive collaboration without inundating them initially with nuances: 97 | 98 | * Is the idea behind the contribution sound? 99 | * Is the contribution architected correctly? 100 | * Is the contribution polished? 101 | 102 | Note: if your pull request isn't getting enough attention, you can use the Developer channel in Discord to get help to find reviewers. (You need to [join Discord to access this][communication_discord]) 103 | 104 | ## Testing 105 | 106 | Testing is the responsibility of all contributors, run unit tests before opening a pull request, and an perform an end to end test run before requesting us to merge a pull request. 107 | 108 | ## Documentation 109 | 110 | If you pull request requires and changes to the documentation open a [pull request for the docs](https://github.com/mailchain/docs.mailchain.xyz/). 111 | 112 | ## Community 113 | 114 | If you haven't noticed by now, we are building a lively, and friendly open-source community. 115 | 116 | We depend on new people becoming members and regular code contributors, so we would like you to [come join us][communication_discord]]! 117 | 118 | [code_of_conduct]: 119 | [communication_discord]: 120 | [docs_mailchain_testnet]: 121 | [getting_started]: 122 | [open_issues]: 123 | [slack_join]: 124 | [pr-reviews-slack]: 125 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright 2022 Mailchain Ltd. 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | --------------------------------------------------------------------------------