Merge contribution documents into the repository (#229)

* Merge contribution documents into the repository

* Add missing sentence

* Update changelog

CHANGELOG.md

@@ -14,6 +14,7 @@ Please, check out guidelines: https://keepachangelog.com/en/1.0.0/
 - Integration tests for `generate` command https://github.com/tuist/tuist/pull/208 by @marciniwanicki & @kwridan
 - Frequently asked questions to the documentation https://github.com/tuist/tuist/pull/223/ by @pepibumur.
 - Generate a scheme with all the project targets https://github.com/tuist/tuist/pull/226 by @pepibumur
+- Documentation for contributors https://github.com/tuist/tuist/pull/229 by @pepibumur
 
 ### Removed
 

docs/README.md

@@ -1,13 +1,21 @@
 # Documentation
 
-# For users
+## For users 👩‍💻
 
-- [Getting started](usage/getting-started.md)
+If Tuist caught your attention and you'd like to explore it further, the following resources will help you configure and get the most out of the tool:
-- [Dependencies](usage/dependencies.md)
-- [Up](usage/up.md)
-- [Managing versions](usage/managing-versions.md)
-- [Frequently asked questions](usage/faq.md)
 
-# For contributors/maintainers
+- [Getting started](usage/getting-started.md): Learn how to install the tool on your environment and generate your first project.
+- [Dependencies](usage/dependencies.md): Learn how to define dependencies between targets and with pre-compiled libraries and frameworks.
+- [Setup](usage/up.md): Learn about the `up` command which handles the configuration of the environment for your projects to run.
+- [Managing versions](usage/managing-versions.md): It dives into how Tuist ensures rep
+- [Frequently asked questions](usage/faq.md): Find answers for the most commonly asked questions.
 
-- [Getting started as a contributor](contribution/getting-started.md)
+## For contributors/maintainers 📚
+
+The following list contains all the documentation for people that are interested in contributed to the project. They get updated as the project evolves so even if you are already a contributor, we'd recommend you to revisit them once in a while:
+
+- [Getting started as a contributor](contribution/getting-started.md): Are you new to contributing to the project? You'll find some recommendations to start from.
+- [Code of conduct](contribution/code-of-conduct.md): Needless to say, you should be a nice developer, have a good conduct and reject any unacceptable behavior from you or any member of the project.
+- [Changelog guidelines](contribution/changelog-guidelines.md) - Changes to the project are reflected in the project `CHANGELOG.md` file. This document contains some guidelines the file adheres to.
+- [Core team](contribution/core-team.md): The Tuist Core team is a group of contributors that have demonstrated a lasting enthusiasm for the project and community. You can read more about their responsibilities and get to know the team.
+- [Zen principles](contribution/zen.md): A set of principles on which maintainers and contributors base their decisions.

docs/contribution/README.md

@@ -1,11 +0,0 @@
-# Contributing to Tuist
-
-As you might already know, Tuist is an open source project that encourages external contributions to help improve the project. Those contributions can come in different shapes: _issue reports, pull requests, participation in discussions, writing documentation, adding tests._
-
-Doing a contribution to a project you haven't been involved with before might seem intimidating. It's understandable and that's the reason why we'd like to provide you with all the resources and support to help you overcome the fear and be part of the project and the community.
-
-In this page and the following pages, you'll find useful resources that we recommend you to read through before start contributing to the project. Those resources are actively updated as the project and the community grows.
-
-## Slack
-
-Although most of the interactions around code happen on [GitHub](https://github.com), there are some discussions that are not related to code and where GitHub is not the most convenient channel to have them. For those discussions, Tuist has a Slack group that you can join to talk to other Tuist members. Joining the group is straightforward, you can access [this website](http://slack.tuist.io/) where you can introduce your email address to get an invitation.

docs/contribution/changelog-guidelines.md

@@ -0,0 +1,39 @@
+# Changelog Guidelines
+
+Here you can find the general guidelines for maintaining the Changelog (or adding new entry). We follow the guidelines from [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) with few additions.
+
+## Guiding Principles
+
+- Changelogs are for humans, not machines.
+- There should be an entry for every single version.
+- The same types of changes should be grouped.
+- Versions and sections should be linkable.
+- The latest version comes first.
+- The release date of each versions is displayed.
+- Mention whether you follow Semantic Versioning.
+- Keep an unreleased section at the top.
+- Add PR number and a GitHub tag at the end of each entry.
+- Each breaking change entry should have **Breaking Change** label at the beginning of this entry.
+- **Breaking Change** entries should be placed at the top of the section it's in.
+
+## Types of changes
+
+- **Added** for new features.
+- **Changed** for changes in existing functionality.
+- **Deprecated** for soon-to-be removed features.
+- **Removed** for now removed features.
+- **Fixed** for any bug fixes.
+- **Security** in case of vulnerabilities.
+
+## Example:
+
+## [9.0.0] - 2017-09-04
+
+### Added
+
+- Added tests for `Single<Response>` operators. [#1229](https://github.com/Moya/Moya/pull/1229) by [@freak4pc](http://github.com/freak4pc)
+
+### Changed
+
+- **Breaking Change** Changed the `TargetType` so it doesn't have `parameters` & `parameterEncoding`. Instead, `task` property offer similar functionalities. [#1147](https://github.com/Moya/Moya/pull/1147) by [@Dschee](http://github.com/Dschee)
+- Changed the `Endpoint` initializer so it doesn't have default `task` argument. [#1252](https://github.com/Moya/Moya/pull/1252) by [@SD10](http://github.com/SD10)

docs/contribution/code-of-conduct.md

@@ -0,0 +1,29 @@
+# Contributor Code of Conduct
+
+As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery
+- Personal attacks
+- Trolling or insulting/derogatory comments
+- Public or private harassment
+- Publishing other's private information, such as physical or electronic addresses, without explicit permission
+- Other unethical or unprofessional conduct
+
+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.
+
+By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
+
+This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a project maintainer at [pedro@ppinera.es](mailto:pedro@ppinera.es). All  
+complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. Maintainers are obligated to maintain confidentiality with regard to the reporter of an incident.
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.3.0, available at
+[http://contributor-covenant.org/version/1/3/0/][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/3/0/

docs/contribution/core-team.md

@@ -0,0 +1,25 @@
+# Core Team
+
+The Tuist Core Team is a group of Tuist contributors that have demonstrated a lasting enthusiasm for the project and community. The Core Team has GitHub admin privileges on all Tuist repositories.
+
+## Core Team Responsibilities
+
+The Tuist Core Team has the following responsibilities:
+
+- Being available to answer high-level questions about Tuist's vision and future.
+- Being available to review longstanding/forgotten pull requests.
+- Occasionally check Tuist issues, offer input, and categorize with GitHub issue labels.
+- Looking out for up-and-coming members of the Tuist community who might want to serve as Core Team members.
+
+Note that the Tuist Core Team – and all Tuist contributors – are open source _volunteers_; membership on the Core Team is expressly _not_ an obligation. The Core Team is distinguished as leaders in the community and while they are a good group to turn to when someone needs an answer to a question, they are still volunteering their time, and may not be available to help immediately.
+
+## Core Team Members
+
+- [@pepibumur](https://github.com/pepibumur)
+
+## Adding new Core Team Members
+
+The process for adding new Core Team members is as follows:
+
+- An existing Core Team member reaches out privately to see if the individual is interested. If they are, open a pull request adding them to the list.
+- Existing Core Team members review the pull request. The person merging the PR is responsible for adding them to the Core Team GitHub group.

docs/contribution/zen.md

@@ -0,0 +1,21 @@
+# Zen
+
+Like any other product, building Tuist is all about making the right decisions, coding features, and releasing them. Although making decisions is easy if there are only a few people contributing to the project, as Tuist grows, things will get more complicated. To facilitate the decision making process, it's important to have a framework, a list of principles that we can embrace. Steve Jobs liked to call this the **taste** of a company/project:
+
+> The only problem with Microsoft is they just have no taste. They have absolutely no taste. And I don’t mean that in a small way, I mean that in a big way, in the sense that they don’t think of original ideas, and they don’t bring much culture into their products. — Steve Jobs
+
+**What's the taste of Tuist?**
+
+The list below contains the taste or design principles of Tuist. The list has been curated based on the work which has already been done, and we'll actively update it based on ideas that will come up in the future. Here are the principles:
+
+- Convention over configuration
+- Design for failure
+- Simple is better than complex
+- Implementation details bring little value to users
+- Make feedback actionable
+- If it can't be reliable, you'd better not build it
+- Swift code that reads like Bash is not Swift code.
+
+When you need to make a decision for the project, whether it's about the code, or about the product, go trough the principles above and ask yourself questions. If you think there's no principle that helps answer your question, don't hesitate too make a proposal.
+
+> We stole this idea from GitHub, which exposes their principles through an [API Endpoint](https://api.github.com/zen).