Add CONTRIBUTING.md and CODE_OF_CONDUCT.md

CODE_OF_CONDUCT.md

@@ -0,0 +1,62 @@
+# Code of Conduct
+
+This code of conduct outlines our expectations for all those who
+participate in the project development.
+
+We invite all those who participate in the development to help us to
+create safe, inclusive and positive experiences.
+
+## Our Standards
+
+The main concern of `zbg` developers is friendliness and inclusion.
+As such, we are committed to providing a friendly, safe and welcoming environment for all.
+So, we are using the following standards in our organization.
+
+### Be inclusive.
+
+We welcome and support people of all backgrounds and identities. This includes,
+but is not limited to members of any sexual orientation, gender identity and expression,
+race, ethnicity, culture, national origin, social and economic class, educational level,
+colour, immigration status, sex, age, size, family status, political belief, religion,
+and mental and physical ability.
+
+### Be respectful.
+
+We won't all agree all the time but disagreement is no excuse for disrespectful behaviour.
+We will all experience frustration from time to time, but we cannot allow that frustration
+to become personal attacks. An environment where people feel uncomfortable or threatened
+is not a productive or creative one.
+
+### Choose your words carefully.
+
+Always conduct yourself professionally. Be kind to others. Do not insult or put down others.
+Harassment and exclusionary behaviour aren't acceptable. This includes, but is not limited to:
+
+  * Threats of violence.
+  * Discriminatory language.
+  * Personal insults, especially those using racist or sexist terms.
+  * Advocating for, or encouraging, any of the above behaviours.
+
+### Don't harass.
+
+In general, if someone asks you to stop something, then stop. When we disagree, try to understand why.
+Differences of opinion and disagreements are mostly unavoidable. What is important is that we resolve
+disagreements and differing views constructively.
+
+### Make differences into strengths.
+
+Different people have different perspectives on issues,
+and that can be valuable for solving problems or generating new ideas. Being unable to understand why
+someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that we all make mistakes,
+and blaming each other doesn’t get us anywhere.
+
+Instead, focus on resolving issues and learning from mistakes.
+
+##  Reporting Guidelines
+
+If you are subject to or witness unacceptable behaviour, or have any other concerns,
+please notify Dmitrii Kovainikov (the current admin of ZBG) as soon as possible.
+
+You can reach them via the following email address:
+
+ * kovanikov@gmail.com

CONTRIBUTING.md

@@ -0,0 +1,70 @@
+# Contributing
+
+This document describes contributing guidelines for the ZBG project.
+
+You're encouraged to read this document before your first contribution.
+Spending your time familiarising yourself with these
+guidelines is much appreciated because following this guide ensures
+the most positive outcome for contributors and maintainers! 💖
+
+## How to contribute
+
+Everyone is welcome to contribute as long as they follow our
+[rules for polite and respectful communication](https://github.com/chshersh/zbg/blob/main/CODE_OF_CONDUCT.md)!
+
+And you can contribute to `zbg` in multiple ways:
+
+1. Share your success stories or confusion moments when using `zbg` under
+   [Discussions](https://github.com/chshersh/zbg/discussions).
+2. Open [Issues](https://github.com/chshersh/zbg/issues) with bug
+   reports or feature suggestions.
+3. Open [Pull Requests (PRs)](https://github.com/chshersh/zbg/pulls)
+   with documentation improvements, changes to the code or even
+   implementation of desired changes!
+
+If you would like to open a PR, **create the issue first** if it
+doesn't exist. Discussing implementation details or various
+architecture decisions avoids spending time inefficiently.
+
+> You may argue that sometimes it's easier to share your vision with
+> exact code changes via a PR. Still, it's better to start a
+> Discussion or an Issue first by mentioning that you'll open a PR
+> later with your thoughts laid out in code.
+
+If you want to take an existing issue, please, share your intention to
+work on something in the comment section under the corresponding
+issue. This avoids the situation when multiple people are working on
+the same problem concurrently.
+
+## Pull Requests requirements
+
+Generally, the process of submitting, reviewing and accepting PRs
+should be as lightweight as possible if you've discussed the
+implementation beforehand. However, there're still a few requirements:
+
+1. Be polite and respectful in communications. Follow our
+   [Code of Conduct](https://github.com/chshersh/zbg/blob/main/CODE_OF_CONDUCT.md).
+2. The code should be formatted with `ocamlformat`
+   using the [project-specific configuration][ocamlformat-config].
+   Your changes will be rejected if they don't follow the formatting
+   requirements.
+3. Add an entry to `CHANGELOG.md` describing your changes in the format similar
+   to other changes.
+
+[ocamlformat-config]: https://github.com/chshersh/zbg/blob/main/.ocamlformat
+
+That's all so far!
+
+> ℹ️ **NOTE:** PRs are merged to the `main` branch using the
+> "Squash and merge" button. You can produce granular commit history
+> to make the review easier or if it's your preferred workflow. But
+> all commits will be squashed when merged to `main`.
+
+## Write access to the repository
+
+If you want to gain write access to the repository, open a
+[discussion with the Commit Bits category](https://github.com/chshersh/zbg/discussions/categories/commit-bits)
+and mention your willingness to have it.
+
+I ([@chshersh](https://github.com/chshersh))
+grant write access to everyone who contributed to `zbg`.