docs(innersource): add contribution introduction section documentation (

#1625)

packages/docs/pages/guides/_meta.json

@@ -11,7 +11,7 @@
     "type": "separator",
     "title": "Contributing"
   },
-  "introduction": "Introduction",
+  "contributing-introduction": "Introduction",
   "processes": "Processes",
   "design-contribution": "Design Contribution",
   "engineering-contribution": "Engineering Contribution"

packages/docs/pages/guides/contributing-introduction.mdx

@@ -0,0 +1,117 @@
+# Introduction
+
+In this section you will learn how to contribute to Shoreline.
+
+We encourage everyone to contribute to the project, regardless of their experience level or discipline.
+We welcome everything from documentation improvements and bug fixes to new features and architectural changes.
+
+## How to get involved
+
+You can get involved in two ways:
+
+**Participation**
+
+Being proactive on the project discussions is a great way to start contributing and getting context about the project. You can do it in many ways:
+
+* Propose a solution in an open issue
+* Open an issue with a proposal
+* Report a bug and how to fix it
+* Open a discussion related to the project
+* Participate on discussions that weren't open by you
+
+Check out the [Processes section](/guides/processes) to understand how it works.
+
+**Hands-on**
+
+Although most of the contributions are made through Github, the changes can also be applied to our Figma library.
+It doesn't matter if you are a designer or a engineer, you can contribute in both paths.
+
+* Check out the [Engineering contribution section](/guides/engineering-contribution/development-guideline) if you want to make changes to the codebase.
+* Check out the [Design contribution section](/guides/design-contribution/handoff-requirements) if you want to make changes to the Figma library.
+
+## Contribution types
+
+The contributions are groupped into three categories:
+
+**Light**: A simple change to the project that doesn't require much effort
+
+* Report a bug
+* Open a discussion related to the project
+* Give feedbacks
+* Share your thoughts in discussions that weren't open by you.
+* Learn about the project
+* A small design or documentation tweak to an existing feature
+
+**Medium**: A bigger change to the project that requires more effort
+
+* Bug fixes
+* Improvements on documentation
+* Components styling changes
+* New features that don't involve complex changes
+
+**Heavy**: Involves complex changes to the project
+
+* Implement a new component API
+* Architectural changes
+* Implement a new feature that involves complex changes
+
+## Shoreline backlog
+
+We have a backlog with all the issues that are ready to be worked on. By ready, we mean that the issue was already discussed, it has a proposed solution and it approved by
+the maintainer. Thoses issues are tagged with the label `status: active`.
+
+Feel free to reach out to the maintainers through the Github issue if you want to work on a specific issue.
+
+Keep in mind that when taking a task from the backlog, you are responsible for it. Make sure to communicate with the maintainers if you have any questions or need help.
+
+[Link to the backlog](https://github.com/orgs/vtex/projects/61/views/1)
+
+## Personas
+
+Personas are a way to represent the different types of Shoreline users and define how they interact with the project.
+We divided them into two categories: **Maintainer** and **Contributor**.
+
+### Maintainer
+
+A maintainer is a user with a deep knowledge of the project. They are the ones who have the final word, and are
+responsible for guiding the discussions, making decisions, and ensuring the project is on the right track. Besides that,
+they will define the project's roadmap, and should be able to communicate the project's goals and vision to the community.
+
+Even though, it doesn't mean that the maintainers will be the only ones contributing to the project. They should encourage
+contributions from the community and help them to understand how they can contribute.
+
+In summary, those are maintainers responsibilities:
+
+1. Define the project's roadmap
+2. Communicate the project's goals and vision
+3. Guide the discussions
+4. Make decisions
+5. Ensure the project is on the right track
+6. Encourage contributions from the community
+7. Help the community to understand how they can contribute
+8. Review and merge pull requests
+9. Spread project knowledge with contributors
+
+### Contributor
+
+The contributor represents the project user that wants to contribute to the project. They can contribute in many ways, such as
+reporting bugs, proposing new features, fixing bugs, writing documentation, and more.
+
+In summary, those are contributors responsibilities:
+
+1. Report bugs
+2. Propose new features
+3. Fix bugs
+4. Write documentation
+5. Review pull requests
+6. Help other contributors
+7. Being active in the project discussions
+
+Are you willing to contribute? [You can check here how to start](/guides/contributing)
+
+## Ask for help
+
+If you have questions about how, what, or when to contribute, the Shoreline team is here to help.
+
+1. Use GitHub issues to propose solutions, discuss new ideas, or ask questions
+2. If you work at VTEX, use the #shoreline Slack channel for support