├── .github ├── CODEOWNERS └── workflows │ ├── compliance.yml │ ├── maintainer_course.yml │ └── triage.yml ├── .gitignore ├── Intro.code-workspace ├── LICENSE.txt ├── README.md ├── contributing ├── CONTRIBUTING.md ├── community-translations.md └── i18n-guidelines.md ├── docs ├── _assets │ ├── gifs │ │ ├── cli-tool.gif │ │ ├── create-github-project.gif │ │ ├── highlight.gif │ │ ├── issues-template.gif │ │ ├── org-permissions.gif │ │ ├── saved-replies.gif │ │ ├── set-up-repo.gif │ │ ├── team-sync-insights.gif │ │ └── team-sync.gif │ └── images │ │ ├── activity-repos-insights.png │ │ ├── completed-pr-template.png │ │ ├── contrib-insight-new.png │ │ ├── contributors-insights.png │ │ ├── create-issue.png │ │ ├── failed-automated-tests.png │ │ ├── feature-form.png │ │ ├── gh-actions.png │ │ ├── guestbook-issue-form.png │ │ ├── issue-assign.png │ │ ├── issue-number.png │ │ ├── list-graph.png │ │ ├── logo-on-dark.png │ │ ├── new-repo.png │ │ ├── opensauced-explore.png │ │ ├── opensauced-highlights.png │ │ ├── opensauced-profile.png │ │ ├── opensauced-signup.png │ │ ├── org-permissions.png │ │ ├── pizza-slice.png │ │ ├── pr-template-preview.png │ │ ├── pr-template.png │ │ ├── profile-generated.png │ │ ├── repos-insights.png │ │ ├── slice-Gradient-White.png │ │ ├── star-search-announcement-card.png │ │ └── workspace.png ├── becoming-a-maintainer │ ├── README.md │ ├── additional-resources.md │ ├── building-community.md │ ├── communication-and-collaboration.md │ ├── community-translations.md │ ├── getting-practical.md │ ├── glossary.md │ ├── how-to-setup-your-project.md │ ├── index.html │ ├── intro.md │ ├── issues-and-pull-requests.md │ ├── maintainer-powerups.md │ ├── maintainers-guestbook.md │ ├── maintaining-code-quality.md │ ├── metrics-and-analytics.md │ └── your-team.md └── intro-to-oss │ ├── README.md │ ├── additional-resources.md │ ├── conclusion.md │ ├── glossary.md │ ├── how-to-contribute-to-open-source.md │ ├── the-secret-sauce.md │ ├── tools-to-be-successful.md │ ├── types-of-contributions.md │ ├── what-is-open-source.md │ └── why-open-source.md ├── docusaurus.config.js ├── netlify.toml ├── package-lock.json ├── package.json ├── sidebars.js ├── src ├── components │ ├── index.js │ └── styles.module.css ├── css │ └── custom.css └── pages │ ├── index.js │ └── index.module.css └── static └── img ├── favicon.ico ├── logo_darkmode.png └── logo_lightmode.png /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @open-sauced/docs 2 | -------------------------------------------------------------------------------- /.github/workflows/compliance.yml: -------------------------------------------------------------------------------- 1 | name: "Compliance" 2 | 3 | on: 4 | pull_request_target: 5 | types: 6 | - opened 7 | - edited 8 | - synchronize 9 | 10 | permissions: 11 | pull-requests: write 12 | 13 | jobs: 14 | compliance: 15 | uses: open-sauced/hot/.github/workflows/compliance.yml@main -------------------------------------------------------------------------------- /.github/workflows/maintainer_course.yml: -------------------------------------------------------------------------------- 1 | name: Maintainer Course Action 2 | 3 | on: 4 | pull_request_target: 5 | types: 6 | - opened 7 | 8 | permissions: 9 | pull-requests: write 10 | 11 | jobs: 12 | intro_course_contributor: 13 | runs-on: ubuntu-latest 14 | steps: 15 | 16 | - name: Post comment for course contributors 17 | if: contains(github.event.pull_request.title, 'adds repo to guestbook') 18 | run: | 19 | PR_COMMENT="Congratulations on completing the Becoming a Maintainer Course with your contribution to this repository, @${{ github.actor }}! We'd love to continue to amplify your project. Here are some ways to do that: Create a [highlight](https://app.opensauced.pizza/feed) of your contribution to our guestbook — [more info here](https://opensauced.pizza/docs/features/highlights/) — and share it with us in our [Becoming a Maintainer Course discussion](https://github.com/orgs/open-sauced/discussions/35)!" 20 | curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" -X POST -d "{\"body\":\"$PR_COMMENT\"}" "https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/comments" -------------------------------------------------------------------------------- /.github/workflows/triage.yml: -------------------------------------------------------------------------------- 1 | name: "Assign issues with .take" 2 | 3 | on: 4 | issue_comment: 5 | types: 6 | - created 7 | - edited 8 | 9 | jobs: 10 | take-issue: 11 | name: Disable take issue 12 | runs-on: ubuntu-latest 13 | timeout-minutes: 10 14 | steps: 15 | - name: take an issue 16 | uses: bdougie/take-action@v1.6.1 17 | with: 18 | issueCurrentlyAssignedMessage: Thanks for being interested in this issue. It looks like this ticket is already assigned to a contributor. 19 | token: ${{ secrets.GITHUB_TOKEN }} 20 | blockingLabels: 👀 needs triage,blocked,core team work,needs design,duplicate 21 | blockingLabelsMessage: The issue you are trying to assign yourself is blocked until it can be triaged or by another label on the issue. -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Dependencies 2 | /node_modules 3 | 4 | # Production 5 | /build 6 | 7 | # Generated files 8 | .docusaurus 9 | .cache-loader 10 | 11 | # Misc 12 | .DS_Store 13 | .env.local 14 | .env.development.local 15 | .env.test.local 16 | .env.production.local 17 | 18 | npm-debug.log* 19 | yarn-debug.log* 20 | yarn-error.log* 21 | -------------------------------------------------------------------------------- /Intro.code-workspace: -------------------------------------------------------------------------------- 1 | { 2 | "folders": [ 3 | { 4 | "path": "." 5 | } 6 | ] 7 | } -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | This work is licensed under a Creative Commons Attribution 4.0 International License. You are free to share (copy and redistribute the material in any medium or format) and adapt (remix, transform, and build upon the material) for any purpose, even commercially, as long as you give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. 2 | 3 | For the full license text, please visit [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/). 4 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |
2 |  
3 |   OpenSauced 4 |  

🍕 The Open Source Education Path with OpenSauced 🍕

5 |   Welcome to OpenSauced's Intro Repository! 6 |
7 | 8 |
9 | 10 | This repository is the home of OpenSauced courses for people who want to learn to contribute to open source projects and for people who want to become project maintainers. 11 | 12 | Head over to the **[Intro to Open Source Course](./docs/intro-to-oss/README.md)** or **[Becoming A Maintainer Course](./docs/becoming-a-maintainer/README.md)** on GitHub to start learning! Alternatively, visit our [Open Source Education Path with OpenSauced website](https://opensauced.pizza/learn/#/). 13 | 14 | Check out the [Community Translations](./contributing/community-translations.md) for translations maintained by our community! 15 | 16 | ## **🤝 Contributing** 17 | 18 | We encourage you to contribute to OpenSauced! All contributors are required to abide by our [Code of Conduct](https://github.com/open-sauced/.github/blob/main/CODE_OF_CONDUCT.md). 19 | 20 | - For information on how to contribute to the intro repository, check out the [Contributing Guidelines](./contributing/CONTRIBUTING.md). 21 | 22 | - To translate the courses in our Open Source Education Path, check out our [🌐 i18n Guidelines](./contributing/i18n-guidelines.md). 23 | 24 | ## **🍕 Community** 25 | 26 | Do you have questions or need help? Join our [Community](https://github.com/orgs/open-sauced/discussions). 27 | 28 | ## **⚖️ LICENSE** 29 | 30 | [![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png)](https://creativecommons.org/licenses/by/4.0/) 31 | -------------------------------------------------------------------------------- /contributing/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing to OpenSauced Intro 2 | 3 | Contributions are always welcome, no matter how large or small. Before contributing, please read the [Code of Conduct](https://opensauced.pizza/docs/contributing/code-of-conduct/) and follow the directions in this guide. 4 | 5 | ## Recommended Communication Style 6 | 7 | 1. Always leave screenshots for visual changes. 8 | 2. Always leave a detailed description in the pull request. Leave nothing ambiguous for the reviewer(s). 9 | 3. Always review your code first. Be sure to run the project locally and test it before asking for a review. 10 | 4. Always communicate in the GitHub repository. Whether it is in the issue or the pull request, keeping the lines of communication open and visible to everyone on the team helps everyone around you. 11 | 12 | ## Issues 13 | 14 | - When you contribute to the project for the first time, please consider checking the [bug](https://github.com/open-sauced/intro/issues?q=is%3Aissue+is%3Aopen+label%3A%22%F0%9F%90%9B+bug%22), [good first issue](https://github.com/open-sauced/intro/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22), or [beginners only](https://github.com/open-sauced/intro/issues?q=is%3Aissue+is%3Aopen+label%3A%22beginners+only%22) labels. 15 | 16 | - If you wish to work on an open issue, please comment with `.take`, and it will be assigned to you.
If an issue is not assigned, it is assumed to be available for anyone to work on. So, assign yourself to an issue **before** beginning work to avoid conflicts. 17 | 18 | > **NOTE**: Please only self-assign an issue with the label "beginners only" or "good first issue" **one time**.
Maintainers may remove you from the assignees and not accept your pull request if you choose to proceed. 19 | 20 | - Do you spot a bug in any of our courses? Or do you have an idea for enhancing our courses and want to add a section or a chapter to a course? 21 | 22 | You can create an issue and fill out our issue form to address it. But our maintainers need to triage the issue before you can work on it. If you wish to work on the issue you submitted, please inform and tag the `@open-sauced/docs` team in the comment. 23 | 24 | You can always ask for help in our [Community](https://github.com/open-sauced/intro/discussions) if you get stuck while working on your changes or need clarification. 25 | 26 | ## Pull Requests (PRs) 27 | 28 | We actively welcome your PRs. However, before working on changes, you must ensure that **you are assigned** to an existing issue and **link your work to the issue in your PR template**. 29 | 30 | ### Before Submitting a PR Template 31 | 32 | 1. Ensure that your changes are made in a new branch. 33 | 34 | 2. Run and check your changes locally. Ensure that everything works as it should. 35 | 36 | ### Submitting a PR Template 37 | 38 | 1. Ensure that you address one issue in one PR.
If you work on multiple issues, work on them separately and create one PR to address each issue. 39 | 40 | 2. Completing the PR template. Make sure you **fill in all sections** and that you have: 41 | 42 | - **A valid title**. The PR title must begin with `feat:`, `fix:`, or anything related to your changes. 43 | - **A related issue**. [Link the issue number](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) that you worked on and add a keyword of "Closes", "Fixes", or "Resolves" in front of it. For example: Closes #123, Fixes #234, etc. 44 | 45 | 3. Do NOT delete any section of the PR template.
If a section is irrelevant to your changes, please explain or respond with "N/A". 46 | 47 | ### After Submitting a PR Template 48 | 49 | 1. Ensure that all checks are passed.
If you see any GitHub action bots or checks that failed after you submit your PR template, you need to read each one and understand why it failed. Then, you must address and fix it until all of them pass. 50 | 51 | 2. Do NOT DM maintainers or tag them in the comments to review your PR.
Maintainers are always notified whenever there is an incoming PR. If you haven't received a review within a week, please tag them in the PR comments to ask for an estimated review time. 52 | 53 | 3. Keep your branch up to date while waiting for review and resolve any merge conflicts in your terminal. 54 | 55 | 4. Response and address the reviewer's feedback. 56 | 57 | ### ⚠️ A PR will be marked as invalid and may be closed if: 58 | 59 | - the issue is not assigned to the contributor who opened the PR. 60 | - no issue is linked to the PR. 61 | - PR template is incomplete, or any section in the template is deleted. 62 | - changes are made directly in the default (`main`) branch. 63 | 64 | ## Getting Started 65 | 66 | ### Setup the Project Locally 67 | 68 | 1. [Fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) the [intro repository](https://github.com/open-sauced/intro) to your own GitHub account. 69 | 2. [Clone](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository) the forked repository to your local machine. 70 | 71 | ```bash 72 | git clone https://github.com/YOUR-USERNAME/intro.git 73 | ``` 74 | 75 | 3. Navigate to and open the project in your code editor. 76 | 77 | ```bash 78 | cd intro 79 | ``` 80 | 81 | 4. Create a new branch to work on your changes. Do NOT work directly on the `main` branch. 82 | 83 | ```bash 84 | git checkout -b YOUR-BRANCH-NAME 85 | ``` 86 | 87 | Replace "YOUR-BRANCH-NAME" with a descriptive name for your branch — for example, `feat/add-submit-button`. 88 | 89 | 5. Install the dependencies and run the project. 90 | 91 | ### Local Development 92 | 93 | > [!NOTE] 94 | > This project is built with [Docusaurus](https://docusaurus.io/). 95 | 96 | Running the project locally is essential to see your changes in real-time and test them thoroughly when you're contributing. 97 | 98 | 1. **Install the dependencies and run the project locally**. 99 | 100 | ```bash 101 | npm ci 102 | npm start 103 | ``` 104 | 105 | After the local development server is ready, it will automatically open the project at `http://localhost:3000/learn` on your browser. 106 | 107 | 2. **Make and test changes**. 108 | 109 | With the local server running, you can make changes to the files and immediately see the results in your browser. Test your changes thoroughly. 110 | 111 | 3. **Stop the server**. 112 | 113 | After completing and testing the changes, you can stop the local server by pressing `Ctrl + C` in the terminal. 114 | 115 | ## Working with the Content 116 | 117 | The contents of our courses are written in [Markdown](https://www.markdownguide.org/), a lightweight and easy-to-use markup language that allows you to format text in a readable and visually appealing way. 118 | 119 | Please read the "[Using Markdown for This Project](#using-markdown-for-this-project)" section for details about how to use it in this project. 120 | 121 | ### Adding Definitions to the Glossary 122 | 123 | If you add definitions to the "Glossary" chapter in the [Intro to Open Source](../docs/intro-to-oss/glossary.md) or [Becoming a Maintainer](../docs/becoming-a-maintainer/glossary.md) course, ensure the definitions are added **alphabetically**. 124 | 125 | ### Adding a New Section to a Chapter 126 | 127 | If your content can fall under the category of one of the course chapters, consider adding it as a new section to the chapter. Create a `heading 2` title and write your content. 128 | 129 | You can add a new chapter if it's more suitable for a standalone section. 130 | 131 | ### Adding a New Chapter and Adding it to the Sidebar 132 | 133 | In this section, we will walk you through adding a new chapter to any of our courses and adding it to the sidebar. 134 | 135 | #### Adding a New Chapter 136 | 137 | Follow these steps to add a new chapter to our course: 138 | 139 | 1. **Create a new Markdown file**. 140 | 141 | Create a new Markdown (`.md`) file in the course directory and name the file to reflect the chapter's content — for example, `how-to-contribute-to-open-source.md` for a chapter about how to contribute to open source. 142 | 143 | > **NOTE**: Be sure to follow naming conventions. Notice that file names are not capitalized, and there are hyphens in place of spaces between words. 144 | 145 | 2. **Add front matter**. 146 | 147 | At the beginning of the file, add front matter that is enclosed by three dashes `---` with below variables: 148 | 149 | - `id`: The ID is used to refer to a document when hand-writing sidebars. You can use the file name as an ID. 150 | - `title`: The chapter's title (`h1`). 151 | - `sidebar_label`: The title on the sidebar. 152 | - `keywords`: Keywords for the topics in the chapter. 153 | 154 | Here is an example: 155 | 156 | ```yml 157 | --- 158 | id: what-is-open-source 159 | title: "What is Open Source?" 160 | sidebar_label: "What is Open Source" 161 | keywords: 162 | [ 163 | "what is open source", 164 | "open source definition", 165 | "open source licenses explained", 166 | "open source history", 167 | "open source evolution", 168 | "Open Source", 169 | "Open Source Community", 170 | ] 171 | --- 172 | ``` 173 | 174 | 3. **Write content**. 175 | 176 | Open the newly created Markdown file in a text editor and write the content for your chapter using the Markdown syntax. You can include headings, text, images, links, lists, and other elements to present your information effectively. 177 | 178 | > **NOTE**: There should only be **one** `heading 1` in each file. 179 | 180 | 4. **Test your changes**. 181 | 182 | Before finalizing your new chapter, you should test your changes locally. You can build or render the project to ensure your new chapter appears as expected within the course structure. 183 | 184 | 5. **Update the sidebar**. 185 | 186 | After you add a new chapter, you must also add it to the sidebar for the users to discover the content. 187 | 188 | #### Adding New Chapters to the Sidebar 189 | 190 | The sidebar serves as a navigation menu. So, when you add a new chapter to a course, it's important to update the sidebar by including the link to the chapter. That way, users can navigate to the content seamlessly. 191 | 192 | Follow these steps to add new chapters to the sidebar: 193 | 194 | 1. Open the `sidebars.js` file located on the root. 195 | 2. **Add the new chapter link**. 196 | 197 | - Insert your new chapter in the `items` array of the related course. If you're unsure where best to put it, you can comment on the issue and tag the `@open-sauced/docs` maintainers to ask for help. 198 | - Use the below format to add the link to the new chapter: 199 | 200 | ```text 201 | 'FOLDER-NAME/ID', 202 | ``` 203 | 204 | Replace `FOLDER-NAME` with the course's folder name and `ID` with the `id` in the file's front matter. For example: 205 | 206 | ```javascript 207 | 'intro-to-oss/what-is-open-source', 208 | ``` 209 | 210 | 3. **Create a pull request**. 211 | 212 | Once you have created the new chapter and verified that it meets our project's requirements, you can submit your contribution by creating a pull request. 213 | 214 | 4. **Review and feedback**. 215 | 216 | Wait for maintainers to review your pull request, and be prepared to receive feedback from them or collaborators. Make changes if necessary to refine your contribution. 217 | 218 | After your contribution is accepted, your new chapter will become part of our course, enhancing its content for users and contributors. 219 | 220 | ## Using Markdown for This Project 221 | 222 | When contributing to this project, you must follow our Markdown convention below: 223 | 224 | ### 1. Headings 225 | 226 | Use the hash (`#`) symbol to create headings (titles and subtitles). There are six levels of section headings, and the number of symbols indicates the heading level. 227 | 228 | ```markdown 229 | # Heading 1 230 | 231 | ## Heading 2 232 | ``` 233 | 234 | ### 2. Text Formatting 235 | 236 | - Make text bold by enclosing it with double asterisks (`**`). 237 | - Make text italic by enclosing it with single underscores (`_`). 238 | - Create inline code by wrapping text with backticks (`` ` ``). 239 | 240 | ```markdown 241 | **This is a bold text.** 242 | 243 | _This is an italic text._ 244 | 245 | This is an `inline code`. 246 | ``` 247 | 248 | ### 3. Lists 249 | 250 | - Create ordered lists using numbers followed by a period (`1.`, `2.`, etc.). 251 | - Create unordered lists using hyphens (`-`). 252 | 253 | ```markdown 254 | 1. Item 1 255 | 2. Item 2 256 | 257 | - Unordered Item 1 258 | - Unordered Item 2 259 | ``` 260 | 261 | ### 4. Links 262 | 263 | Create links using square brackets (`[]`) for the link text and parentheses (`()`) for the URL. 264 | 265 | ```markdown 266 | [Open Source Education Path with OpenSauced](https://opensauced.pizza/learn/) 267 | ``` 268 | 269 | ### 5. Images 270 | 271 | Embed images using an exclamation mark (`!`), followed by square brackets (`[]`) for the alt text, and parentheses (`()`) for the image URL. 272 | 273 | ```markdown 274 | ![Create new repository on GitHub](../_assets/images/new-repo.png) 275 | ``` 276 | 277 | ### 6. Blockquotes 278 | 279 | Create blockquotes using the greater-than symbol (`>`). 280 | 281 | ```markdown 282 | > This is a blockquote. 283 | ``` 284 | 285 | ### 7. Code Blocks 286 | 287 | Create code blocks using triple backticks (` ``` `) for fenced code blocks and specify a language next to the backticks before the fenced code block to highlight the syntax. 288 | 289 | ```` 290 | ```bash 291 | git pull 292 | ``` 293 | ```` 294 | 295 | ### Markdown Tips 296 | 297 | - Preview your Markdown locally to ensure proper formatting before submitting your contribution. 298 | - Keep your Markdown content organized, and use headings to structure your sections. 299 | - There can only be one `heading 1` in each chapter. 300 | - Use code blocks to highlight code snippets or configuration examples. 301 | - Check out the official [Markdown Guide](https://www.markdownguide.org/basic-syntax/) website for more information about using Markdown. 302 | 303 | ## Translating the Courses 304 | 305 | Translating our courses helps make them more accessible to a broader audience. If you want to translate our [Open Source Education Path](https://opensauced.pizza/learn/#/), please read our [🌐 i18n Guidelines](i18n-guidelines.md) page. 306 | -------------------------------------------------------------------------------- /contributing/community-translations.md: -------------------------------------------------------------------------------- 1 | # Community Translations 2 | 3 | We are grateful for the contributions of the community in translating our [Open Source Education Path](https://opensauced.pizza/learn/#/). Although the OpenSauced team does not currently maintain these translation, we want to share the forked repositories with those taking the course. 4 | 5 | > [!NOTE] 6 | > If you'd like to improve a translation, you can contact the maintainers of the forked repository. If you'd like to translate our Open Source Education materials, please read our [🌐 i18n Guidelines](i18n-guidelines.md). 7 | 8 | ## List of Community Translations 9 | 10 | 11 | 14 | -------------------------------------------------------------------------------- /contributing/i18n-guidelines.md: -------------------------------------------------------------------------------- 1 | # 🌐 i18n Guidelines 2 | 3 | Welcome to our i18n Guidelines! We appreciate your interest in translating our courses. 4 | 5 | ## Community Translations 6 | 7 | At the moment, we are unable to offer translation maintenance. 8 | 9 | However, we know some contributors are willing to translate and help our courses to reach a broader audience. We value these contributions! ✨ 10 | 11 | Please keep reading if you want to translate the [Open Source Education Path with OpenSauced](https://opensauced.pizza/learn/#/). 12 | 13 | ## Why Translating Our Courses 14 | 15 | Here are some benefits of translating our courses: 16 | 17 | - You will have the opportunity to learn to maintain a project and **become the maintainer** of the translation as it will live in your forked repository. 18 | - You can learn and experience collaborating with contributors, nurturing the translation community, and even assembling your own maintainers' team! 19 | - You will be able to learn how to deploy and host a static website on your own. 20 | - You can make the translation available as soon as possible for a broader audience. 21 | - You can update the translation faster by reviewing and merging in pull requests yourself as a maintainer. 22 | 23 | > [!TIP] 24 | > It will be helpful taking our [Becoming a Maintainer](../docs/becoming-a-maintainer/README.md) course to equip you in maintaining your forked repository. 25 | 26 | ## Getting Started 27 | 28 | ### 1. Forking the Repository 29 | 30 | First, you must fork the [intro repository](https://github.com/open-sauced/intro). See the official GitHub docs for [forking a repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo#forking-a-repository). 31 | 32 | ### 2. Creating a Branch for the Translation 33 | 34 | [Create a branch](https://www.shellhacks.com/git-create-new-branch-and-checkout/) where the translation changes will be merged. You can name this branch anything. For example: `jp-translations`. 35 | 36 | > [!NOTE] 37 | > 38 | > - This will be the default branch of your translation and the one from which you deploy the translation. 39 | > - The `main` branch should be free from translations. 40 | 41 | ### 3. Installing and Running the Project 42 | 43 | Read our [contributing guidelines](CONTRIBUTING.md#getting-started) to install and run the project locally. 44 | 45 | ## Working with Translations 46 | 47 | The translation process will take time, but don't let this stop you from making the ongoing translations available to the community. 48 | 49 | What you need to know when working with translations: 50 | 51 | - Maintain the original project's file names and structure, but replace all content with the translations. This will help preventing broken links. 52 | - Ensure there are no broken links and that all links navigate to the correct paths. 53 | - Maintain consistency in terminology and style throughout the translated documentation. 54 | - Keep translations up to date with changes in the original documentation. 55 | - When a course, a chapter, or a section hasn't been translated, you can add a note to inform the readers and direct them to [our website](https://opensauced.pizza/learn/#/). 56 | 57 | ## Creating Contributing Guidelines for the Forked Repository 58 | 59 | You have complete control of how you want contributors to contribute to your forked repo. Therefore, you want to create contributing guidelines for contributors to contribute to your forked repo. 60 | 61 | You can name this file anything _except_ `CONTRIBUTING.md`. For example: `contributing-jp.md`. 62 | 63 | Put the file in the `contributing` folder at the root. Then, add the link to it as the last list in the "[🤝 Contributing](../README.md#-contributing)" section on the root README as below: 64 | 65 | ```markdown 66 | - For information on how to contribute to this translations repository, check out our [Translations Contributing Guidelines](LINK-TO-YOUR-FORKED-REPOSITORY-CONTRIBUTING-FILE). 67 | ``` 68 | 69 | ## Adding Translation as a Community Translation 70 | 71 | Once you are ready to share your translation, add it to the Community Translation list. 72 | 73 | Open the `community-translations.md` file located in the `contributing` folder on the root and list your translation. Read the instructions in the file to add it. 74 | -------------------------------------------------------------------------------- /docs/_assets/gifs/cli-tool.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/gifs/cli-tool.gif -------------------------------------------------------------------------------- /docs/_assets/gifs/create-github-project.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/gifs/create-github-project.gif -------------------------------------------------------------------------------- /docs/_assets/gifs/highlight.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/gifs/highlight.gif -------------------------------------------------------------------------------- /docs/_assets/gifs/issues-template.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/gifs/issues-template.gif -------------------------------------------------------------------------------- /docs/_assets/gifs/org-permissions.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/gifs/org-permissions.gif -------------------------------------------------------------------------------- /docs/_assets/gifs/saved-replies.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/gifs/saved-replies.gif -------------------------------------------------------------------------------- /docs/_assets/gifs/set-up-repo.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/gifs/set-up-repo.gif -------------------------------------------------------------------------------- /docs/_assets/gifs/team-sync-insights.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/gifs/team-sync-insights.gif -------------------------------------------------------------------------------- /docs/_assets/gifs/team-sync.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/gifs/team-sync.gif -------------------------------------------------------------------------------- /docs/_assets/images/activity-repos-insights.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/activity-repos-insights.png -------------------------------------------------------------------------------- /docs/_assets/images/completed-pr-template.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/completed-pr-template.png -------------------------------------------------------------------------------- /docs/_assets/images/contrib-insight-new.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/contrib-insight-new.png -------------------------------------------------------------------------------- /docs/_assets/images/contributors-insights.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/contributors-insights.png -------------------------------------------------------------------------------- /docs/_assets/images/create-issue.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/create-issue.png -------------------------------------------------------------------------------- /docs/_assets/images/failed-automated-tests.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/failed-automated-tests.png -------------------------------------------------------------------------------- /docs/_assets/images/feature-form.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/feature-form.png -------------------------------------------------------------------------------- /docs/_assets/images/gh-actions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/gh-actions.png -------------------------------------------------------------------------------- /docs/_assets/images/guestbook-issue-form.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/guestbook-issue-form.png -------------------------------------------------------------------------------- /docs/_assets/images/issue-assign.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/issue-assign.png -------------------------------------------------------------------------------- /docs/_assets/images/issue-number.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/issue-number.png -------------------------------------------------------------------------------- /docs/_assets/images/list-graph.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/list-graph.png -------------------------------------------------------------------------------- /docs/_assets/images/logo-on-dark.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/logo-on-dark.png -------------------------------------------------------------------------------- /docs/_assets/images/new-repo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/new-repo.png -------------------------------------------------------------------------------- /docs/_assets/images/opensauced-explore.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/opensauced-explore.png -------------------------------------------------------------------------------- /docs/_assets/images/opensauced-highlights.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/opensauced-highlights.png -------------------------------------------------------------------------------- /docs/_assets/images/opensauced-profile.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/opensauced-profile.png -------------------------------------------------------------------------------- /docs/_assets/images/opensauced-signup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/opensauced-signup.png -------------------------------------------------------------------------------- /docs/_assets/images/org-permissions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/org-permissions.png -------------------------------------------------------------------------------- /docs/_assets/images/pizza-slice.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/pizza-slice.png -------------------------------------------------------------------------------- /docs/_assets/images/pr-template-preview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/pr-template-preview.png -------------------------------------------------------------------------------- /docs/_assets/images/pr-template.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/pr-template.png -------------------------------------------------------------------------------- /docs/_assets/images/profile-generated.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/profile-generated.png -------------------------------------------------------------------------------- /docs/_assets/images/repos-insights.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/repos-insights.png -------------------------------------------------------------------------------- /docs/_assets/images/slice-Gradient-White.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/slice-Gradient-White.png -------------------------------------------------------------------------------- /docs/_assets/images/star-search-announcement-card.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/star-search-announcement-card.png -------------------------------------------------------------------------------- /docs/_assets/images/workspace.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/docs/_assets/images/workspace.png -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: Maintainer-README 3 | title: "Becoming a Maintainer with OpenSauced" 4 | sidebar_label: "Becoming a Maintainer" 5 | keywords: ["README", "Becoming a Maintainer with OpenSauced", "becoming an open source maintainer", "open source course", "open source course for beginners", "maintaining open source projects course", "maintaining open source projects course for beginners", "open source maintainers", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | Welcome to the Becoming a Maintainer Course with OpenSauced! This course is designed to provide you with an introduction to how to become an open source maintainer and guide you through the process of creating your open source project, working with contributors, and more. 9 | 10 | ## Course Overview 11 | 12 | The course is divided into chapters, with each covering a different aspect of being an open source maintainer: 13 | 14 | ### [Intro: Understanding the Role of an Open Source Maintainer](intro.md) 15 | 16 | This chapter introduces the role of maintainers in open source, the benefits and the responsibilities of becoming a maintainer, and the challenges they face. 17 | 18 | ### [How to Setup Your Open Source Project](how-to-setup-your-project.md) 19 | 20 | This chapter walks you through the crucial elements necessary for every project to succeed during its initial setup. 21 | 22 | ### [How to Handle Open Issues and Pull Requests](issues-and-pull-requests.md) 23 | 24 | In this chapter, you'll learn how to manage open issues and pull requests in your project, from triaging issues to reviewing pull requests. 25 | 26 | ### [How to Communicate and Collaborate Effectively](communication-and-collaboration.md) 27 | 28 | This chapter will discuss onboarding new contributors, utilizing different communication channels for your open source project's community, and maintaining healthy communication. 29 | 30 | ### [How to Maintain Code Quality and Documentation](maintaining-code-quality.md) 31 | 32 | This chapter covers ways of maintaining code quality and documentation in your open source project. 33 | 34 | ### [Building and Nurturing a Welcoming and Supportive Community](building-community.md) 35 | 36 | In this chapter, you will learn how to build and nurture a welcoming and supportive community in open source, particularly around your project. 37 | 38 | ### [Maintainer Power Ups](maintainer-powerups.md) 39 | 40 | This chapter introduces tools on GitHub that you can utilize to help you save some time, make your work lighter, and boost your productivity as a maintainer. 41 | 42 | ### [Building Your Open Source Dream Team](your-team.md) 43 | 44 | In this chapter, you'll learn how to create and assemble your team by examining effective collaboration and offering guidance on identifying, onboarding, and empowering your open source squad. 45 | 46 | ### [The Power of Metrics and Analytics](metrics-and-analytics.md) 47 | 48 | This chapter will help you understand your project's metrics and guide you through understanding, leveraging, and making decisions based on these metrics to create a thriving open source project. 49 | 50 | ### [Let's Get Practical: Starting Your Project](getting-practical.md) 51 | 52 | This chapter contains tutorials based on the previous chapters to help you prepare and launch your first open source project as a maintainer. 53 | 54 | ### Additional Information 55 | 56 | As this is the beginning of your open source maintainer journey, we've also provided additional information in these chapters: 57 | 58 | - [Glossary](glossary.md): A glossary of common terms and definitions used by open source maintainers. 59 | - [Additional Resources](additional-resources.md): A list of resources for further learning about open source maintainers. 60 | 61 | ## Getting Started 62 | 63 | If you are taking this course on our GitHub repository, navigate to the [`intro.md` file](intro.md) to start the course. Alternatively, visit the [Becoming a Maintainer with OpenSauced on the website](https://opensauced.pizza/learn/becoming-a-maintainer/) and start reading! 64 | 65 | :::tip 66 | 67 | Each chapter builds on the previous one, so we recommend reading them in order. 68 | 69 | ::: 70 | 71 | As you work through the course, we encourage you to experiment with the tools and concepts covered in the chapters. 72 | 73 | ## Building Your Open Source Resume 74 | 75 | One of the unique features of this course is that it guides you to build your open source resume using OpenSauced. OpenSauced is a platform that helps you track and showcase your open source contributions, making it easier to get noticed by potential employers and collaborators. 76 | 77 | To learn more about using OpenSauced to build your open source project, check out the [Maintainers Guide to OpenSauced](https://opensauced.pizza/docs/maintainers/maintainers-guide-to-open-sauced/). 78 | 79 | --- 80 | 81 | We hope you find this course informative and useful! If you have any questions or feedback, please don't hesitate to open an issue or reach out to us in the [Community](https://github.com/orgs/open-sauced/discussions). 82 | 83 | Happy learning and contributing! 84 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/additional-resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: additional-resources 3 | title: "Additional Resources" 4 | sidebar_label: "Additional Resources" 5 | keywords: ["additional resources for open source maintainers", "guides resources for open source maintainers", "blog posts resources for open source maintainers", "open source maintainers", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | On this page, you will find additional resources to help you learn more about all things around open source maintainers. 9 | 10 | ## Guides 11 | 12 | - [Open Source Guide](https://opensource.guide/) by GitHub: Open Source Guides are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open-source project. 13 | - [Contributor Ladder Template](https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md) by cncf: This is a template for a contributor ladder that outlines the different contributor roles within a project, along with the responsibilities and privileges that come with them. 14 | - [Maintainer Community](https://maintainers.github.com/auth/signin) by GitHub: The Maintainer Community is a private space for maintainers to connect with peers, preview GitHub features, and help GitHub support the open source community. 15 | 16 | ## Blog Posts 17 | 18 | - [New Maintainer Resources Series](https://dev.to/bekahhw/series/25520) 19 | - [Maintainer Toolkit Series](https://dev.to/bekahhw/series/24725) by BekahHW 20 | - [Maintainer Toolkit Series](https://dev.to/nickytonline/series/24726) by Nick Taylor 21 | - [The Missing Piece: Why Your Project Needs a Maintainer Onboarding Process](https://dev.to/opensauced/the-missing-piece-why-your-project-needs-a-maintainer-onboarding-process-np0) 22 | - [Scaling Open Source Projects: Navigating Challenges](https://dev.to/opensauced/navigating-the-challenges-of-scaling-open-source-projects-11h2) 23 | - [Collaborate, Conquer, & Grow: Mastering the Art of Issue Management for Open Source Projects](https://dev.to/opensauced/collaborate-conquer-grow-mastering-the-art-of-issue-management-for-open-source-projects-49gi) 24 | - [The Lonely Journey of Open-Source Maintainers: A Call for Connection and Recognition](https://dev.to/opensauced/the-lonely-journey-of-open-source-maintainers-a-call-for-connection-and-recognition-2ghe) 25 | - [The Role of Documentation in Open Source Success](https://dev.to/opensauced/the-role-of-documentation-in-open-source-success-2lbn) 26 | - [How To Make a Delicious Contributing Guide](https://dev.to/opensauced/how-to-make-a-delicious-contributing-guide-4bp3) 27 | - [What Does an Open Source Triage Team Do?](https://dev.to/opensauced/what-does-an-open-source-triage-team-do-2egd) 28 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/building-community.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: building-community 3 | title: "Building and Nurturing a Welcoming and Supportive Community" 4 | sidebar_label: "Building and Nurturing Community" 5 | keywords: ["building community", "building open source community", "nurturing community", "nurturing open source community", "welcoming and supportive community", "positive community culture", "how to build and nurture community", "best practices in building and nurturing community", "fostering community", "fostering open source community", "open source maintainer", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | Open source is more than just maintaining and improving a project. It's a dynamic environment where maintainers, contributors, and users come together to collaborate, contribute, and grow. That said, the people involved in the project are the core and heart of open source. 9 | 10 | As more people engage and contribute to your projects, it becomes crucial for you to provide them with the necessary support and motivation to establish a welcoming and positive open source community environment. Doing so can build stronger relationships and promote a sense of belonging among your community members, keeping them returning and remaining dedicated. 11 | 12 | In this chapter, you will learn how to build and nurture a welcoming and supportive open source community. 13 | 14 | ## Positive Community Culture 15 | 16 | There are many types of people when talking about engagements in a community. Some are actively engaging, some come and go, and some are lurkers. But one thing is sure: everyone has the same interest (your project), and they bring value to your project. You always want to ensure everyone feels welcomed, included, and, most importantly, safe in your community. One key to achieving this is fostering a positive community culture. 17 | 18 | ### Open Communication 19 | 20 | Successful open source communities encourage open communication. Open communication allows everyone to understand what's happening around the project and community, helps build trust, and increases healthy collaboration. Everyone should feel comfortable expressing thoughts and ideas, but at the same time, they should be able to listen and respectfully respond to others. For tips about communication and collaboration, read the chapter "[How to Communicate and Collaborate Effectively](communication-and-collaboration.md)." 21 | 22 | ### Diversity and Inclusivity 23 | 24 | Creating a safe and welcoming community environment involves prioritizing inclusion and promoting diversity. Inclusion means treating everyone with value, regardless of background, beliefs, or opinions. By fostering a culture where everyone is encouraged to be authentic while appreciating others, you can nurture a community where everyone feels respected and valued. Building a community where everyone feels they belong is the most important thing. 25 | 26 | ### Code of Conduct 27 | 28 | Every project should have a code of conduct as a clear set of guidelines for how members within the open source community should behave and treat each other. You can, for example, emphasize the importance of using positive and inclusive language, treating others with respect, and avoiding discrimination or harassment. Inform them of the consequences they may face if they do not follow the guidelines. A code of conduct helps to prevent conflicts, promotes respect, and ensures that everyone in the community feels safe and comfortable. You can read the "[Code of Conduct](how-to-setup-your-project.md#code-of-conduct)" section in the "How to Setup Your Open Source Project" chapter to create one. 29 | 30 | ### Addressing Conflicts 31 | 32 | Imagine seeing a member behave disrespectfully towards another member on GitHub or Discord, or receiving an incident report from a member saying someone harassed them. Unfortunately, most open source communities will have to address conflicts at some point. Being prepared to do so will help to maintain a positive culture. You can learn more about managing conflicts in the "[Handling Difficult Situations](communication-and-collaboration.md#handling-difficult-situations)" section in the "How to Communicate and Collaborate Effectively" chapter. 33 | 34 | ### Leading by Examples 35 | 36 | Leadership is not about being in charge. It's about taking responsibility and setting an example for others to follow. You want to demonstrate positive behavior, be respectful to others, and be willing to listen and learn. Doing so will encourage others to follow your example. 37 | 38 | ### Recognization and Appreciation 39 | 40 | Recognition is the key to unlocking the full potential of the open source community. Expressing gratitude and kindness towards others — in this case, your team and contributors — is fundamental to creating a supportive and positive community culture. 41 | 42 | Contributions to open source come in all shapes and sizes. You want to take a moment to recognize and track these invaluable contributions. Appreciating contributions can be made in many ways, such as through awards or rewards, public recognition, or even just acknowledging their contributions and efforts. One way to recognize and appreciate your contributors is by installing the [All Contributors](https://allcontributors.org/) bot in your project to automate adding project contributors. 43 | 44 | At OpenSauced, we recognize that [contributions aren't just green squares](https://opensauced.pizza/blog/moneyball-for-engineers) and appreciate all kinds of contributions that have made our projects and community thrive. That's why, besides having the All Contributors installed in our [guestbook repository](https://github.com/open-sauced/guestbook), we enjoy recognizing and giving shoutouts to our contributors through our monthly live stream, blog posts, newsletter, and social media. 45 | 46 | Remember that recognizing and appreciating contributions can create a ripple effect throughout the community, inspiring others to do the same and increasing positivity. 47 | 48 | ## Creating Opportunities for Contributions 49 | 50 | In an open source environment, people want to make meaningful contributions and be part of the community. If you want to see return contributors, you need to create the space and opportunities to encourage them to return and contribute more. In this section, we will discuss how to create opportunities for contributions. 51 | 52 | ### Identifying Contributors Levels 53 | 54 | To create opportunities, you need first to identify contributors' entry points. 55 | 56 | #### New Contributors 57 | 58 | They are generally new to open source or someone new to your project. This type of contributor usually still needs hand-holding and guidance. So, you want to be able to point them to resources about the flow of open source and how to use Git and GitHub. Consider having clear and updated project documentation for them to refer to. 59 | 60 | #### Intermediate Contributors 61 | 62 | Intermediate contributors have some experience in open source but want to go deeper in their engagement and contributions. They usually don't need hand-holding and can understand how to work with your project by reading the documentation or finding resources independently. On this level, they might want to grow their skills and network and be interested in becoming a maintainer. 63 | 64 | #### Expert Contributors 65 | 66 | They are seasoned open source contributors who can contribute at a high level and potentially lead projects. At this level, they can give ideas and contribute to enhancing your project outside the box because they enjoy using it. Whenever they encounter bugs, they want to fix them quickly so they can still use your project and implement it on their projects. 67 | 68 | ### Encouraging Diverse Contributions 69 | 70 | You want to create a space that welcomes diverse contributions, regardless of contributors' coding skills, for the success of your projects. By encouraging both coding and non-coding contributions, you can ensure everyone can participate and contribute their unique skills and perspectives. However, you also need to consider the amount of support you can give them if they need it. 71 | 72 | #### Code Contributions 73 | 74 | After identifying their entry points, consider creating issues for all levels of contributors. Good first issues are usually for beginners in open source and someone new to your project. When creating a `good first issue`, think of providing suggested solutions, the lines of code that cause the issue, and resources to help them work on it. For contributors who don't need extra support, you can create an issue with `beginners` or `help wanted` labels based on the complexity. 75 | 76 | #### Documentation 77 | 78 | You might add new features or change some things in your projects. That's one reason you want to always keep your documentation up to date: to reflect on the current state of your project. 79 | 80 | You can create issues to improve the documentation or encourage your community to create tutorials and how-to guides. 81 | 82 | #### Community Contributions 83 | 84 | As your community grows, engaging with each member becomes increasingly challenging. To manage your community effectively, having people who can facilitate interactions between members and provide timely responses will be helpful. 85 | 86 | You can encourage community members to contribute by engaging in online forums and chat apps. They can help answer questions, share insights, and provide support. This not only helps to build a sense of community around your project but also helps to foster a culture of collaboration and mutual support. 87 | 88 | #### Advocacy and Outreach 89 | 90 | Some of your contributors may have skills that can be useful to promote your project and organization, such as writing or public speaking. You can motivate them to get involved by encouraging them to write blog posts and create educational content related to your project. They can also speak at conferences or give workshops if they want to. Posting or reposting information about your project on social media is another way to contribute. At OpenSauced, we encourage our community to write blog posts under our [organization on Dev.to](https://dev.to/opensauced). 91 | 92 | #### Managing Issues 93 | 94 | Issue management involves identifying, analyzing, and prioritizing bug issues and feature requests during development. You can create a triage team and encourage your community to help you triage and prioritize the issues in your repositories. You want to equip them with a clear guide on managing issues like what we have at OpenSauced in our [Triage Guide](https://opensauced.pizza/docs/contributing/triage-guide/). You can also read [this article](https://dev.to/opensauced/collaborate-conquer-grow-mastering-the-art-of-issue-management-for-open-source-projects-49gi) to learn more about issue management. 95 | 96 | #### Community Events and Hackathons 97 | 98 | At OpenSauced, we organize the [#100DaysOfOSS challenge](https://opensauced.pizza/docs/community/100-days-of-oss/) to encourage contributors of all technical backgrounds to immerse themselves in collaborative development and engage with a supportive community. 99 | 100 | Organizing community events and hackathons is one way to strengthen your community's collaboration and relationships. You can create a survey or poll to gather feedback on what events your community wants to see. Then, consider forming a committee or group of members interested in organizing the events and letting them take charge with your support. By allowing your members to get involved and contribute, you can increase the sense of community and belonging. 101 | 102 | ## Fostering New Talents 103 | 104 | After you have created opportunities for people to contribute to your project, it's important to keep track of which contributors keep coming back and consistently producing quality work. These contributors have the potential to become core members of your community, and you want to foster their growth and development within your project. 105 | 106 | By building a core group of community members, you can ensure that your project can continue to grow and evolve even after maintainers move on to other projects. These core members can help to onboard new contributors, share knowledge and expertise, and provide continuity in the project's development. 107 | 108 | To foster the growth of these new talents, you can provide them with mentorship, feedback, and opportunities for leadership roles within the project. Investing in these contributors can build a solid and sustainable community to help your project thrive over the long term. 109 | 110 | ### Identify New Talents with OpenSauced 111 | 112 | You can utilize OpenSauced [Repository Insights](https://opensauced.pizza/docs/features/repo-insights/) and [Contributor Insights](https://opensauced.pizza/docs/features/contributor-insights/) features to identify new talents by tracking active project contributors. 113 | 114 | #### 1. Using Repository Insights 115 | 116 | You can list the projects you maintain on a Repository Insights Page. This feature allows you to monitor your projects' activity and identify contributors who actively contribute to and impact them. 117 | 118 | You can find more information about your contributors in the Contributors dashboard. It allows you to view their activity level, the date of their last contribution, and the number of contributions. It also gives you information on their time zone and the languages they use most. Learn more about Repository Insights for maintainers and how to create one on [OpenSauced Docs](https://opensauced.pizza/docs/maintainers/maintainers-guide-to-open-sauced/#repository-insights-connecting-your-repositories). 119 | 120 | #### 2. Using Contributor Insights 121 | 122 | After identifying potential new talents for your projects, you can select and add them to the list of a new or existing Contributor Insights Page. This feature enables you to monitor and analyze your contributors' activity levels and contributions more deeply, such as tracking the number of commits and pull requests they have made. You can read more about Contributor Insights for maintainers and how to create one on [OpenSauced Docs](https://opensauced.pizza/docs/maintainers/maintainers-guide-to-open-sauced/#contributor-insights-connecting-with-contributors). 123 | 124 | ## Conclusion 125 | 126 | Open source is a journey of learning, growth, and opportunity. So, building and nurturing a welcoming and supportive community is crucial for long-term success. 127 | 128 | A positive community culture that encourages diverse contributions and fosters new talents can help you attract and retain top talent, stimulate innovation, and increase productivity. By creating a supportive environment where people feel valued, respected, and empowered to share their ideas, you can unlock the full potential of your contributors and achieve your goals. 129 | 130 | However, building a positive community culture is not a one-time task; it requires continuous effort and commitment from everyone involved. You must invest in promoting diversity and inclusion, encouraging collaboration and teamwork, and fostering a sense of belonging. Doing so can create a culture of trust and respect that enables your community and projects to thrive. In short, building and nurturing a welcoming and supportive community is the right thing to do and a great strategy to help your project and your community succeed. 131 | 132 | In the [next chapter](maintainer-powerups.md), we will discuss tools and features on GitHub that can help save maintainers time. 133 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/community-translations.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: community-translations 3 | title: "Community Course Translations" 4 | sidebar_label: "community translations" 5 | keywords: ["community translations", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | We are grateful for the contributions of the community in translating our courses. Although the OpenSauced team does not currently maintain these projects, we want to share the forked copy of the repositories with those taking the course. Below, you will find the latest community translations. 9 | 10 | ## Intro to Open Source Course 11 | 12 | 13 | 16 | 17 | ## Becoming a Maintainer Course 18 | 19 | 20 | 23 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/glossary.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: glossary 3 | title: "Glossary" 4 | sidebar_label: "Glossary" 5 | keywords: ["glossary", "open source glossary", "glossary for open source maintainers", "open source maintainers", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | ## API Documentation 9 | 10 | API documentation is a technical document that explains how to use and work with an API. This manual contains all the information required to work with the API including details on how to make requests, what data formats are supported, and what response codes are returned. 11 | 12 | Examples of API documentation include Swagger, RAML, and API Blueprint. 13 | 14 | ## Backlog 15 | 16 | A backlog is a list of tasks that need to be completed within a project. Typically, these are tasks that are not yet assigned to a developer and are waiting to be worked on. Sometimes, these could be tasks that were open weeks or months ago and are still waiting to be worked on. 17 | 18 | ## Code Freeze 19 | 20 | A code freeze is a period of time where no new code is added to a project. It is often used to prepare for a release and ensure that the code is stable and ready for production. 21 | 22 | ## Code Review 23 | 24 | A code review is when a maintainer or contributor will review the work of another contributor. This is a great way to ensure that the code is high quality and meets the standards of the project. 25 | 26 | ## Containerization 27 | 28 | Containerization is a way of packaging and running applications. Instead of installing an app directly on your computer, you put it in a container that includes everything it needs to work. This container can then run on your computer alongside other containers. It's a way to organize and run multiple applications on the same machine, making it easier for developers to manage and scale their applications. 29 | 30 | Examples of containerization tools include Docker and Kubernetes. 31 | 32 | ## Continuous Integration (CI) 33 | 34 | Continuous integration (CI) is a development approach in which developers regularly merge code into a shared repository. For each change, an automated build and test process is run to detect errors as quickly as possible. 35 | 36 | Examples of CI tools include Jenkins, CircleCI, and TravisCI. 37 | 38 | ## Continuous Deployment (CD) 39 | 40 | Continuous deployment (CD) is often associated with continuous integration (CI) and refers to keeping your application deployable at any point or even automatically releasing to production. CD means that every change which passes the automated tests is deployed to production automatically. 41 | 42 | ## Contributor 43 | 44 | A contributor is someone who contributes to a project by adding code, documentation, tests, or other resources. 45 | 46 | ## DevOps 47 | 48 | DevOps is a mix between software development and IT operations. Examples of DevOps work would include automating the deployment of software, monitoring the performance of deployed software, and managing the infrastructure that the software runs on. 49 | 50 | ## Discord 51 | 52 | Discord is a voice, video, and text communication service. It is a great way to communicate with your team and keep everyone up to date on what is happening in your project. 53 | 54 | You can also create a Discord community to connect with your contributors and have multiple channels for different topics related to the project. 55 | 56 | ## Docker 57 | 58 | Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package. 59 | 60 | ## Git Hooks 61 | 62 | Git hooks are scripts that run automatically every time a particular event occurs in a Git repository. 63 | 64 | Here are some common Git hooks: 65 | 66 | - `pre-commit` - Run before a commit is created 67 | - `pre-push` - Run before a push is executed 68 | - `post-commit` - Run after a commit is created 69 | - `post-merge` - Run after a merge is executed 70 | 71 | ## GitHub Actions 72 | 73 | GitHub Actions are a way to automate tasks within your software development life cycle. GitHub Actions are event-driven, meaning that you can run a series of commands after a specified event has occurred. 74 | 75 | Examples of GitHub Actions include running tests, deploying to production, and sending notifications. 76 | 77 | ## GitHub Discussions 78 | 79 | GitHub Discussions are a way to have conversations about your project directly in GitHub. They are a great way to discuss ideas, ask questions, and share knowledge with your community. 80 | 81 | ## Issue Template 82 | 83 | An issue template is a file that contains a description of the issue you are creating. It is a great way to provide context to your issues and help developers understand what issues you are creating and why. 84 | 85 | Examples of issue templates include bug reports, feature requests, and documentation updates. 86 | 87 | ## Issue Tracker 88 | 89 | An issue tracker is a software application used to track issues and bugs within a project. It is often used in conjunction with a version control system and is a great way to keep track of bugs, enhancements, and tasks for your projects. 90 | 91 | GitHub has a built-in issue tracker but you can also use other tools such as Jira, Trello, and Asana. 92 | 93 | ## Linting 94 | 95 | Linting is the process of running a program that will analyze code for potential errors. A popular linting tool used frequently is ESLint. You can setup an action to run ESlint against each pull request that comes in to check for potential errors before it makes it into production. 96 | 97 | ## Milestones 98 | 99 | Milestones are groups of issues that correspond to a project, feature, or time period. You can use milestones to track the progress of groups of issues that are tied to a larger goal. 100 | 101 | ## Prettier Code Formatting 102 | 103 | Prettier is an opinionated code formatter that enforces a consistent style for your codebase. You can customize your Prettier configuration to fit your project's needs and customize how you prefer semicolons, single quotes, trailing commas, and more to be formatted. 104 | 105 | ## Pull Request (PR) Template 106 | 107 | A pull request template is a file that contains a description of the changes you are making to a project. It is a great way to provide context to your pull requests and help reviewers understand what changes you are making and why. 108 | 109 | You can also create an action to respond to pull requests that don't follow your pull request template and urge the contributor to update their pull request. 110 | 111 | ## Release Candidate 112 | 113 | A release candidate is a beta version of software with the potential to be a final product. It is typically the last version before the final release. 114 | 115 | ## Slack 116 | 117 | Slack is a cloud-based set of team collaboration tools and services. It is a great way to communicate with your team and keep everyone up to date on what is happening in your project. 118 | 119 | ## Scrum 120 | 121 | Scrum is an agile framework for brainstorming, developing, and delivering products. 122 | 123 | ## Technical Debt 124 | 125 | Technical debt is a when a codebase has increased maintenance costs because of earlier decisions made during development. 126 | 127 | ## Versioning 128 | 129 | Versioning is the process of assigning either unique version names or numbers to new releases of your project. Some versions are released as "major" versions, while others are released as "minor" versions. 130 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/how-to-setup-your-project.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: how-to-setup-your-project 3 | title: "How to Setup Your Open Source Project" 4 | sidebar_label: "How to Set Up Your Project" 5 | keywords: ["how to start an open source project", "how to setup open source project", "open source project setup", "start open source project", "create open source project", "write README for open source project", "project installation guide for open source", "open source license explained", "choosing open source license", "how to add code of conduct open source", "code of conduct open source project", "contributing guidelines open source", "issue templates", "create issue templates open source", "pull request template", "create pull request template open source", "Projects on GitHub", "GitHub project boards", "GitHub", "open source project best practices", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | There are many things to consider when you think about how to start an open source project. In this portion of the course, we will walk through the key components every project needs to succeed. 9 | 10 | ## Detailed README 11 | 12 | A README file contains an introduction to your open source project. A good README should be clear, concise, up-to-date, and detailed. This file is located in your root directory and serves as the first impression for your contributors. 13 | 14 | Here are some things to consider inside your README: 15 | 16 | - project title and summary 17 | - brief instructions on how to set up the project 18 | - images of the app and code examples 19 | - tech and tools used in the project 20 | - link to the contributing guidelines 21 | - link to the code of conduct 22 | - link to the open source license 23 | - link to community Discord, Slack group, or GitHub Discussions 24 | 25 | A README file is written in a markup language called [Markdown](https://www.markdownguide.org/), a popular language used in open source documentation like READMEs. 26 | 27 | Here are a few examples of good READMEs: 28 | 29 | - [OpenSauced App](https://github.com/open-sauced/app/blob/beta/README.md) 30 | - [Astro documentation](https://github.com/withastro/astro/blob/main/README.md) 31 | - [freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/README.md) 32 | 33 | ## Installation Guide 34 | 35 | This guide should include instructions for the following: 36 | 37 | - forking the repository 38 | - cloning the repository 39 | - installing the dependencies 40 | - setting up the environment variables 41 | - setting up the database, if applicable 42 | - running the project locally 43 | - setting up Docker containers, if applicable 44 | 45 | The best way to test your guide is by setting up the project locally using your guide. If you encounter issues getting your project to work, you will discover it quickly and can update the documentation to add or clarify the missing piece. 46 | 47 | The installation guide is best placed at the top of your project's README file, as it is the most accessible file for your contributors. 48 | 49 | Another good place would be in the CONTRIBUTING file. Besides providing guidelines about contributing to your project, this file can include installation setup, testing, linting, workflows, etc. You can place the installation instructions towards the top or bottom of your CONTRIBUTING file. You can take a look at [OpenSauced Contributing Guidelines](https://opensauced.pizza/docs/contributing/introduction-to-contributing/) as an inspiration. 50 | 51 | If your project is on the larger side, consider having a separate documentation site and dedicating a section for installation there. You can use documentation site generators like [Docusaurus](https://docusaurus.io/), [Starlight](https://starlight.astro.build/), or [docsify](https://docsify.js.org/#/). 52 | 53 | ## Open Source Software License 54 | 55 | You need to know that an open source project without a license is not available for anyone to use and distribute. Take a look at these explanations on [The Legal Side of Open Source](https://opensource.guide/legal/) on Open Source Guides: 56 | 57 | > Making your GitHub project public is not the same as licensing your project. Public projects are covered by [GitHub’s Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. 58 | > 59 | > If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so. 60 | 61 | So, every open source project must have a license written in a LICENSE file to grant further rights to other users. This file is typically located in the root directory for easy access for everyone. 62 | 63 | ### Choosing a License 64 | 65 | An open source software license is a legally binding agreement between the software creator and the end users. It dictates how others can use, modify, or distribute your software. 66 | 67 | Some licenses are more restrictive, like the GNU GPL (General Public License), while others are less restrictive, like the MIT license. Here are a few examples of licenses for OpenSauced projects: 68 | 69 | - [OpenSauced Docs - MIT license](https://github.com/open-sauced/docs/blob/main/LICENSE) 70 | - [OpenSauced App - Apache License 2.0](https://github.com/open-sauced/app/blob/beta/LICENSE) 71 | 72 | To better understand which license would work best for your project, please look at these helpful resources: 73 | 74 | - [How open source licenses work and how to add them to your projects](https://www.freecodecamp.org/news/how-open-source-licenses-work-and-how-to-add-them-to-your-projects-34310c3cf94/). 75 | - [tl;dr Legal](https://www.tldrlegal.com/) 76 | 77 | For a complete list of Open Source Initiative (OSI) approved licenses, please check out [their list](https://opensource.org/licenses/). 78 | 79 | ## Code of Conduct 80 | 81 | A code of conduct is an established set of rules and behaviors that all open source participants agree to abide by. This document helps to ensure a healthy and inclusive environment for all involved with the project. 82 | 83 | This set of rules and expectations will go inside a CODE_OF_CONDUCT file in the root directory of your project. Codes of conduct are generally divided into three main categories: pledge, standards, and enforcement. 84 | 85 | :::info 86 | 87 | Most open source maintainers will not write their code of conduct from scratch. Instead, they will add one using a [template provided by GitHub](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-code-of-conduct-to-your-project#adding-a-code-of-conduct-using-a-template) or copy and adapt from other codes of conduct and provide attribution. 88 | 89 | ::: 90 | 91 | ### Project Pledge 92 | 93 | The opening pledge is a statement of the type of environment that the project wants to create. Here is an excerpt from the [OpenSauced Code of Conduct](https://github.com/open-sauced/.github/blob/main/CODE_OF_CONDUCT.md): 94 | 95 | > 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. 96 | 97 | ### Project Standards 98 | 99 | The standards section explicitly outlines what is considered acceptable and non-acceptable behavior by all project participants. 100 | 101 | Here is an example from the [OpenSauced Code of Conduct](https://github.com/open-sauced/.github/blob/main/CODE_OF_CONDUCT.md): 102 | 103 | > Examples of behavior that contribute to creating a positive environment include: 104 | > 105 | > - Using welcoming and inclusive language 106 | > - Being respectful of differing viewpoints and experiences 107 | > - Gracefully accepting constructive criticism 108 | > - Focusing on what is best for the community 109 | > - Showing empathy towards other community members 110 | > 111 | > Examples of unacceptable behavior by participants include: 112 | > 113 | > - The use of sexualized language or imagery and unwelcome sexual attention or advances 114 | > - Trolling, insulting/derogatory comments, and personal or political attacks 115 | > - Public or private harassment 116 | > - Publishing others' private information, such as a physical or electronic address, without explicit permission 117 | > - Other conduct which could reasonably be considered inappropriate in a professional setting 118 | 119 | ### Project Enforcement 120 | 121 | You will want to explicitly state the consequence of what will happen if any member of the project behaves in an unacceptable way that violates your code of conduct. 122 | 123 | Here is an example from the [OpenSauced Code of Conduct](https://github.com/open-sauced/.github/blob/main/CODE_OF_CONDUCT.md): 124 | 125 | > Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at hello@opensauced.pizza. 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. Further details of specific enforcement policies may be posted separately. 126 | > 127 | > 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. 128 | 129 | ### Contributor Covenant 130 | 131 | The Contributor Covenant is a code of conduct you can use and adapt for your open source projects. To learn more, please visit the [official website](https://www.contributor-covenant.org/). 132 | 133 | ## Contributing Guidelines 134 | 135 | A key aspect of learning how to start an open source project is developing contributing guidelines that outline the expectations and processes for all contributors. A CONTRIBUTING file contains guidelines on how contributors can help with your project. It is usually located in the project's root directory so everyone can easily access it. 136 | 137 | Your guide should include the following sections: 138 | 139 | - project setup instructions 140 | - guidelines for creating new issues like bug reports and feature requests 141 | - information about which issues are available for contribution 142 | - guidelines for commit conventions for pull requests 143 | - guidelines for code and style conventions 144 | - guidelines for creating pull requests 145 | 146 | For an in-depth look into creating a robust CONTRIBUTING file, please read [this article](https://dev.to/opensauced/how-to-make-a-delicious-contributing-guide-4bp3) by OpenSauced. 147 | 148 | ## Issue Templates 149 | 150 | Issue templates help guide contributors in providing the specific and structured information needed when opening project issues. Having these templates in your repository will ensure you receive the desired information to triage the issue correctly. 151 | 152 | You can create various issue templates, such as bug reports, feature requests, documentation updates, etc. Inside these templates, you can have required fields like steps for reproducing the bug or a details section for a feature request. You can also attach specific labels like `feature`, `needs triage`, or `bug` to inform the types of issue templates. 153 | 154 | ### Creating Issue Templates 155 | 156 | There are two ways to create issue templates on GitHub. 157 | 158 | #### 1. Using GitHub's Template Builder 159 | 160 | To create issue templates using the GitHub's template builder, you will need to: 161 | 162 | - go to your project's settings, 163 | - navigate to the "Features" section, 164 | - click on "Set up templates" under "Issues". 165 | 166 | You can follow the [detailed guide](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-templates) on the GitHub documentation to create one. 167 | 168 | ![Issue template GIF](../_assets/gifs/issues-template.gif) 169 | 170 | #### 2. Using YAML Files 171 | 172 | You can also create custom issue templates using YAML frontmatter: 173 | 174 | - Create a folder called `.github` in the root directory. 175 | - Add a folder called `ISSUE_TEMPLATE` inside the `.github` folder. 176 | 177 | :::note 178 | 179 | The name of this folder should be in all caps, or else it will not work on GitHub. 180 | 181 | ::: 182 | 183 | - Create a YAML file like a `bug.yml` or `feature.yml` file inside the `ISSUE_TEMPLATE` folder. 184 | 185 | Here is the [bug report template](https://raw.githubusercontent.com/open-sauced/.github/main/.github/ISSUE_TEMPLATE/bug_report.yml) that we use at OpenSauced. To learn more about configuring issue templates, please visit the [official documentation](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository) on GitHub. 186 | 187 | ## Pull Request Templates 188 | 189 | Like issue templates, pull request templates allow you to guide your contributors in providing specific and structured information when opening pull requests in your project. This template will be in a file called `PULL_REQUEST_TEMPLATE.md`, which is usually located either in the root directory or the `.github` directory. 190 | 191 | Here are a few things to consider inside your pull request template: 192 | 193 | - section for contributors to describe the details of changes that were made and why 194 | - section for the type of change made (e.g., bug fix, feature, style update, etc.) 195 | - section to link corresponding issue tickets to the pull request (e.g., closes #123 or fixes #456) 196 | - section to place screenshots and screen recordings, if applicable 197 | 198 | Here is an example of a [pull request template](https://raw.githubusercontent.com/open-sauced/.github/main/.github/PULL_REQUEST_TEMPLATE.md) used by OpenSauced. Please read the [GitHub documentation](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository) to learn more about creating pull request templates. 199 | 200 | ![PR template example](../_assets/images/pr-template.png) 201 | 202 | ## Projects on GitHub 203 | 204 | Keeping track of your issues is getting more challenging as your project progresses. A great tool that can help you organize and track your issues is [Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) on GitHub. With projects, you can efficiently manage your project's features, roadmaps, or releases as they're built from and integrated with issues and pull requests that you add. 205 | 206 | You can choose a template for your project. One of the templates is the "Kanban" template. Here, you can create notes and place the existing issues and pull requests in the "Backlog", "Ready", "In progress", "In review", and "Done" columns. This will make it easy for you and your team to track the progress of your project. 207 | 208 | To create a new project: 209 | 210 | 1. Navigate to your GitHub profile and click the "Projects" tab. 211 | 2. Click the green "New project" button. 212 | 3. Choose a template. 213 | 4. Name your project and click the "Create project" button at the bottom. 214 | 215 | :::note 216 | 217 | Projects are private by default. You can make them private to core maintainers or publicly visible to everyone. 218 | 219 | ::: 220 | 221 | Please read the [GitHub documentation](https://docs.github.com/en/issues/planning-and-tracking-with-projects/managing-items-in-your-project/adding-items-to-your-project) to learn more about adding items to your project. 222 | 223 | ![GitHub Project Boards GIF](../_assets/gifs/create-github-project.gif) 224 | 225 | Learning how to start an open source project involves understanding the importance of clear goals, community, comprehensive documentation, and ensuring quality contributions get merged into your project. The [next chapter](issues-and-pull-requests.md) will discuss handling open issues and pull requests. 226 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | OpenSauced 6 | 7 | 8 | 9 | 13 | 19 | 20 | 21 | 22 |
23 | 80 | 81 | 82 | 83 | 87 | 88 | 89 | 90 | 91 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/intro.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: intro 3 | title: "Understanding the Role of an Open Source Maintainer" 4 | sidebar_label: "Understanding Maintainership" 5 | keywords: ["how to start an open source project", "What is an Open Source Maintainer", "open source maintainer role", "open source maintainer responsibilities", "benefits of being an open source maintainer", "challenges of open source maintainers", "day in the life of an open source maintainer", "open source maintainers", "open source community and maintainers", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | Being an open source maintainer can be a very gratifying and rewarding experience. But a lot of work goes into maintaining an open source project. You will have many responsibilities as a maintainer, including being a contributor, leader, mentor, and community manager. 9 | 10 | This course will provide you with a comprehensive overview of how to start an open source project, including information on the maintainer's role, insights into daily tasks, long-term responsibilities, and the overall impact of a maintainer in an open source project. 11 | 12 | ## What is an Open Source Maintainer? 13 | 14 | An open source maintainer is responsible for maintaining the health and success of a project. Maintainers help define the project's goals, work with other contributors, help build a community around the project, and uphold the project's quality standards. 15 | 16 | ### A Guide and Feedback Provider 17 | 18 | Being able to work with contributors from all backgrounds is an important skill to develop as a maintainer. Some contributors will be seasoned developers who are interested in getting started with your project, while others will be new to open source and development in general. So, it would be best to communicate well with your contributors. 19 | 20 | Working with contributors will include assisting them with any blockers they might have and providing constructive feedback so they can grow and strengthen their contributions to your project. 21 | 22 | ### A Welcoming Community Nurturer 23 | 24 | Not all open source communities are welcoming and inclusive, which can deter people from wanting to participate in open source at all. So, you must consistently lead your community with kindness, patience, and understanding. 25 | 26 | People are volunteering their time to contribute to your project with the intention of helping it grow. Setting a standard that your community is inclusive and helpful to everyone will trickle down to all community members and create a community that contributors will want to be a part of. 27 | 28 | ### A Project Quality Assurance 29 | 30 | One of the maintainer's responsibilities is to review and maintain the project to the existing quality standards. When you receive a pull request, you are responsible for ensuring that all of the tests are passing and the feature or fix is working as expected. It is also important to check and make sure that the new changes do not accidentally break something else in the project. Having a good testing suite and process will help with that. 31 | 32 | ## Maintainer Benefits 33 | 34 | Being an open source maintainer has many benefits, including career, leadership, and personal growth. 35 | 36 | ### Personal and Professional Growth 37 | 38 | As a maintainer, you are in a leadership position helping to guide contributors to success in contributing to your project. Leadership and mentorship skills are essential to develop and will help you grow professionally. 39 | 40 | Being a maintainer also helps you grow your technical skills. You will be responsible for contributing, reviewing pull requests, writing technical articles about your project, and possibly giving technical talks at conferences. 41 | 42 | ### Networking Opportunities 43 | 44 | Building relationships in the tech industry is a great way to connect with talented technologists worldwide and advance your career. By working with other contributors, you will get to learn from them, and they will get to see your leadership and technical abilities. 45 | 46 | There have been many instances where long-term open source relationships have become possible business ventures or future job opportunities. And if your project ends up being used by many people, you will be able to connect with a larger group of technologists. 47 | 48 | ## Maintainer Challenges 49 | 50 | While there are many benefits to being an open source maintainer, it can also be challenging. Here are a few challenges that maintainers face: 51 | 52 | ### Burnout 53 | 54 | Many open source maintainers have felt burned out by the sheer volume of work and responsibility it takes to maintain the project. Some have even gone as far as to walk away from the project when the work became too much to handle. 55 | 56 | If you feel overwhelmed by the workload and getting close to burnout, it is time to get the right support for your project. Identify regular contributors in the community and reach out to them to see if they are interested in becoming a maintainer. Onboarding new team members will help offload some of your responsibilities and decrease your stress around the project. 57 | 58 | When identifying possible new maintainers, look for contributors who have been invested in the project for some time and go above and beyond. Most contributors will be casual contributors to your project, which is fine. But there will be those who will regularly contribute and start to integrate more into the community. You will want to reach out to those individuals to recruit them to be a maintainer. 59 | 60 | ### Dealing with Loneliness 61 | 62 | Maintaining an open source project can be challenging and overwhelming, and it sometimes feels lonely and isolated. Most contributors will come and go, and you are still left to maintain the project alone or with a small group of people. However, it's essential for you not to go through this journey alone. 63 | 64 | Connecting with other maintainers from various open source projects is highly recommended so you can share your challenges, feelings, and experiences. Fellow maintainers can relate to the difficulties you are facing and offer suggestions on how to make your project and community better. By reaching out to others in similar situations, you can grow, learn from, and support each other. 65 | 66 | ## Key Responsibilities and Expectations 67 | 68 | The role of the maintainer is a multifaceted one. This section will discuss a few key responsibilities of an open source maintainer. 69 | 70 | ### Triaging Issues 71 | 72 | Learning to triage issues is essential for any open source maintainer. This involves going through the existing list of open issues and prioritizing them in order of importance. Some open issues will be critical bug fixes, while others might be nice to have feature requests. Sometimes, you might have issues opened for things that are not a right fit for the project. 73 | 74 | ### Reviewing Pull Requests 75 | 76 | Reviewing pull requests is an important part of a maintainer's job. It is the maintainer's responsibility to ensure that the suggested code or documentation update meets the standards of the project and doesn't introduce any new issues for the project. You will also need to work with the contributor to unblock them on issues they have or help them resolve failing tests. 77 | 78 | ### Testing and Stability 79 | 80 | A maintainer is responsible for making sure the application is working as expected. This will involve a combination of manual and automated testing. 81 | 82 | For manual testing, you will want to set time aside once in a while to run through new or existing features like a regular user would. If there are any bugs or poor user experiences, you must document them and create an issue. 83 | 84 | For automated testing, you can set up an automated test suite that runs on every pull request and merges into the main branch. If the test suite fails, you can reach out to the contributor and help them debug the error. Good automated test suites can help catch bugs from going into production and breaking the application. 85 | 86 | ### Documentation 87 | 88 | A good open source project will have a comprehensive set of documentation so all users will know how to run and maintain the project. In your project's README, you will want to have a basic overview of the project, along with how to set it up and how to contribute. As your project grows over time, you should keep your documentation up to date. 89 | 90 | If you are maintaining a larger project, consider using documentation builders like [Docusaurus](https://docusaurus.io/), [Starlight](https://starlight.astro.build/), or [docsify](https://docsify.js.org/#/) to host your documentation. Documentation also includes writing tutorials, building diagrams, or creating in-depth guides for the project. 91 | 92 | ### Community Management 93 | 94 | A vital component of any open source project is its community. Building a strong community can help accelerate the growth of your open source project. As new contributors discover and start to contribute to your project, you will want to create spaces for communication and collaboration. 95 | 96 | If your project is on GitHub, you can use [GitHub Discussions](https://docs.github.com/en/discussions) as a way for contributors to post questions and facilitate conversations. Consider creating communities on Discord or Slack and holding office hours or other events like X Spaces to encourage engagement. At one point, as you grow your community, you will want to recruit moderators to help maintain the healthy environment you set up. 97 | 98 | The [next chapter](how-to-setup-your-project.md) will teach you how to set up an open source project. 99 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/maintainer-powerups.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: maintainer-powerups 3 | title: "Maintainer Power Ups" 4 | sidebar_label: "Maintainer Powerups" 5 | keywords: ["maintainer powerups", "GitHub tools for open source maintainers", "open source maintainers productivity", "GitHub Actions", "GitHub Actions for open source projects", "types of GitHub Actions for open source projects", "automating open source maintainers tasks", "GitHub", "GitHub tools", "open source maintainers", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | Maintainers have a variety of daily tasks. You often juggle triaging new issues, reviewing pull requests, testing changes, and managing and moderating the community, such as welcoming new contributors and thanking contributors for their contributions. Most of the time, you are expected to respond to these tasks promptly. Sometimes, these never-ending tasks take too much time and are overwhelming. It would help if you were efficient in what you do. 9 | 10 | The good news is that some tools and features on GitHub allow you to automate tasks, which can help you save time and make your work lighter. In this chapter, we will talk about these maintainer power ups from GitHub. 11 | 12 | ## GitHub Actions 13 | 14 | Let's say your project receives more new issues and pull requests daily. You want to welcome each new contributor, thank them for their contributions, and tell them you will triage their issues and review their pull requests. You want to do more but don't have time to respond to them because you're still busy with something else. 15 | 16 | Setting up actions to automate these tasks will save you time responding to contributions individually. You can decide which actions to include in each repository. 17 | 18 | ![Create GitHub Action](../_assets/images/gh-actions.png) 19 | 20 | ### Types of Actions 21 | 22 | There are many types of actions that you can set up for your project, depending on what you need. Below are some GitHub Actions that you usually find across repositories: 23 | 24 | #### Linter 25 | 26 | Most open source repositories have linters that run on each pull request. Linter is a tool for detecting potential errors and maintaining a consistent code style in a project. [Super-Linter](https://github.com/marketplace/actions/super-linter) is one of the most used actions. This action can help you maintain code quality and achieve a more readable and consistent style. 27 | 28 | #### Deployed Previews 29 | 30 | You want to be able to view changes, especially visual ones, without shipping them to production. Having these previews in every pull request with [Netlify](https://docs.netlify.com/site-deploys/deploy-previews/) or [Vercel](https://vercel.com/features/previews) lets you preview changes before merging the pull request. 31 | 32 | #### Issue and Pull Request Scripts 33 | 34 | Having scripts to welcome new issues and pull requests and let contributors know that you will triage and review them will save you more time than writing them manually, one by one. You can use the [Create or Update Comment](https://github.com/marketplace/actions/create-or-update-comment) action, as we do here at OpenSauced, to [welcome new issues](https://github.com/open-sauced/app/blob/beta/.github/workflows/issue.yml). 35 | 36 | #### Code Scanning Tools 37 | 38 | Code scanning is a tool for detecting security vulnerabilities, possible bugs, and errors in code. You can use GitHub's [code scanning](https://docs.github.com/en/code-security/code-scanning) feature and configure tools like [CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql), which GitHub maintains, or third-party scanning tools such as [SonarQube](https://github.com/marketplace/actions/official-sonarqube-scan). 39 | 40 | #### Testing 41 | 42 | Setting up actions to run tests is helpful to ensure your app functions and performs as it should and that no regressions occur with new changes. [Cypress GitHub Action](https://docs.cypress.io/guides/continuous-integration/github-actions) is one of the examples of actions for E2E testing. You can also check out [Is Website Vulnerable](https://github.com/marketplace/actions/is-website-vulnerable) to find publicly known security vulnerabilities in JavaScript libraries' websites or [Step CI Action](https://github.com/marketplace/actions/step-ci-action) for API quality assurance. 43 | 44 | ### Creating and Customizing Actions 45 | 46 | You can search for available GitHub Actions on the [GitHub Marketplace](https://github.com/marketplace?type=actions). But if you can't find the one you need, you can create or customize your own actions from existing GitHub Actions. 47 | 48 | Brian Douglas, the founder of OpenSauced, created [Take Action](https://github.com/marketplace/actions/contributor-takes-action). This action allows contributors to assign themselves to an issue by typing the `.take` command in the issue's comment, allowing maintainers to focus on more important tasks than assigning issues. 49 | 50 | However, we want contributors only able to take issues that have passed our triage or are not meant to be worked on by the core team. So, we create the [Triage Action](https://github.com/open-sauced/app/blob/beta/.github/workflows/triage.yml) that will block the Take Action whenever a `needs triage` or `core team work` label exists. 51 | 52 | You can read more about GitHub Actions and how to create one in [the official documentation](https://github.com/features/actions). 53 | 54 | Here are some more resources to give you more information about GitHub Actions and how to set one up: 55 | 56 | - [GitHub Actions: A Maintainer's Best Friend](https://dev.to/opensauced/github-actions-a-maintainers-best-friend-488n) 57 | - [Setting Up Your First GitHub Action](https://dev.to/opensauced/setting-up-your-first-github-action-for-specific-contributions-33a4) 58 | 59 | ## CI/CD Pipelines 60 | 61 | Leveraging GitHub Actions to bring Continuous Integration / Continuous Delivery or Deployment (CI/CD) into your workflow directly in your repository will let you run code, test, build, and deliver or deploy software with simple and secure workflows. Automating these tasks will speed up your deployment process. 62 | 63 | Using Git, GitHub, and GitHub Actions to build a CI/CD pipeline should give you confidence in your code. 64 | 65 | ### Continuous Delivery vs. Continuous Deployment 66 | 67 | From the official [GitHub Resources](https://resources.github.com/ci-cd/): 68 | 69 | > In a CI/CD pipeline that uses continuous _delivery_, automation pauses when developers push to production. A human—your operations, security, or compliance team—still needs to manually sign off before final release, adding more delays. 70 | > 71 | > On the other hand, continuous _deployment_ automates the entire release process. Code changes are deployed to customers as soon as they pass all the required tests. 72 | 73 | A project usually starts with continuous delivery and integrates more automated testing over time. 74 | 75 | ### Build a CI/CD Pipeline with GitHub Actions 76 | 77 | Below are some helpful resources to help you build a CI/CD pipeline with GitHub Actions: 78 | 79 | - [GitHub Docs: The complete CI/CD solution](https://github.com/solutions/ci-cd/) 80 | - [How to build a CI/CD pipeline with GitHub Actions in four simple steps](https://github.blog/2022-02-02-build-ci-cd-pipeline-github-actions-four-steps/) 81 | 82 | ## GitHub CLI 83 | 84 | [GitHub CLI](https://cli.github.com/) is an open source tool that enables you to use GitHub from your computer's command line. It allows you to: 85 | 86 | - forking and cloning repositories, 87 | - checking out a pull request and reviewing it locally, 88 | - creating issues and pull requests, 89 | - viewing a pull request, issue, or repository right from your terminal. 90 | 91 | Using the GitHub CLI will save you time and boost your productivity as a maintainer. You don't need to switch between the GitHub website and your terminal. 92 | 93 | Visit the [GitHub CLI repository](https://github.com/cli/cli#installation) for information on installing GitHub CLI on your machine, and read [this blog post](https://dev.to/opensauced/boost-productivity-with-the-github-cli-2mne) to get started. 94 | 95 | ## Issues and Pull Request Templates 96 | 97 | Have you ever found yourself in a situation where you're reviewing pull requests or triaging issues, but you can't understand what's happening because contributors didn't provide sufficient information? Or, have you had to close an issue or pull request because the description, screenshot, or other crucial information was missing? 98 | 99 | The good news is that you can address these problems by creating issue and pull request templates. These templates allow you to customize and standardize it to include necessary information. You can see them as guides for contributors to follow when writing an issue or pull request for your project. Creating templates saves time on triaging issues, reviewing pull requests, and ensuring you get all the information you need from your contributors. Additionally, future contributors can benefit from these templates by understanding the history of changes made, which can help them debug or understand the code involved. 100 | 101 | You can learn more about [configuring issue templates](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository) and [creating a pull request template](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository) on the official GitHub documentation. 102 | 103 | ## Saved Replies 104 | 105 | Sometimes, you repeatedly write the same reply to issues or pull requests. Clear communication between maintainers and contributors is crucial. So, when you write all comments manually, your messages will no longer be consistent and may be unclear. You can create saved replies when you frequently respond to issues and pull requests with the same comments. 106 | 107 | [Saved replies](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies) allow you to create a reusable response to issues, pull requests, and discussions and use it across repositories. It will save you time responding to contributors while keeping the consistency of your message. You can always modify your replies if necessary. 108 | 109 | Read the GitHub documentation for complete instructions about how to [create saved replies](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/creating-a-saved-reply). 110 | 111 | ![Saved replies gif](../_assets/gifs/saved-replies.gif) 112 | 113 | ## Code Owners 114 | 115 | Most of the time, contributors don't know the maintainers of a project, so they don't know who to reach out to review their pull requests. When they create a pull request, they usually leave a comment without tagging anyone, like, "Can you please review my PR?" Without being tagged, maintainers don't get notified about this new pull request and comment, causing it to be missed from the radar. Adding the CODEOWNERS file to the repository will help you to automate and tackle this issue. 116 | 117 | From the [official GitHub documentation](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners): 118 | 119 | > You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository. 120 | 121 | Here is an example of a [CODEOWNERS file](https://github.com/open-sauced/docs/blob/main/.github/CODEOWNERS) in the OpenSauced docs repository that contains code as below: 122 | 123 | ```text 124 | * @open-sauced/docs 125 | ``` 126 | 127 | This syntax means that the `@open-sauced/docs` team will be the default owner for everything in the repository and will automatically added as reviewers whenever someone creates a pull request. 128 | 129 | :::note 130 | 131 | If you want to match two or more code owners with the same pattern, all the code owners must be on the same line. 132 | 133 | ::: 134 | 135 | There are some benefits to having this file in your repository: 136 | 137 | - **Review request notification** 138 | 139 | Once you have specified who can review and maintain a repository, these code owners are automatically notified and requested for review when someone opens a pull request that modifies code that they own. That way, you don't need to add reviewers manually. 140 | 141 | - **Prevent contributors from manually adding reviewers** 142 | 143 | Setting up the CODEOWNERS file prevents external contributors from manually adding reviewers because it automatically adds them. That way, contributors don't have to comment and tag anyone on the comment to review their pull request. It also helps you to stop them from adding non-maintainers — such as regular contributors — as reviewers. 144 | 145 | - **Branch protection** 146 | 147 | If you opt-in to "Require approval" and "Require review from Code Owners" to protect a branch, a certain number of code owners must approve any pull request before it can be merged into the protected branch. This can reduce the chance of merging pull requests that can break production. 148 | 149 | Now that you understand the basics of what maintainers do and the tools, the [next chapter](your-team.md) will teach you how to build your team. 150 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/maintainers-guestbook.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: maintainers-guestbook 3 | title: "Maintainers Guestbook" 4 | sidebar_label: "Maintainers Guestbook" 5 | keywords: ["maintainers guestbook", "list of new open source projects", "Becoming A Maintainer Course", "open source maintainers", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | Congratulations on finishing the Becoming a Maintainer Course with OpenSauced. Welcome to our Maintainers Guestbook, where you can share your first project with us! 9 | 10 | ## Projects List 11 | 12 | 13 | 16 | 17 | - [Virtual Coffee](https://github.com/virtual-Coffee/virtualcoffee.io/) by [VirtualCoffee](https://github.com/virtual-Coffee/) 18 | - [Postpartum Wellness App](https://github.com/BekahHW/postpartum-wellness-app) by [BekahHW](https://github.com/BekahHW/) 19 | - [Idrinth API Bench](https://github.com/idrinth-api-bench/issues) by [Idrinth](https://github.com/Idrinth/) 20 | - [Favorite Open Source Resources](https://github.com/Izuchii/favorite-open-source-resources) by [Izuchii](https://github.com/Izuchii/) 21 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/maintaining-code-quality.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: maintaining-code-quality 3 | title: "How to Maintain Code Quality and Documentation" 4 | sidebar_label: "Maintaining Code Quality and Documentation" 5 | keywords: ["maintaining code quality", "maintaining code quality of open source projects", "maintaining documentation", "maintaining open source project documentation", "code reviews best practices", "ensuring high-quality contributions in open source", "open source maintainers", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | Maintaining a project with high code quality and up-to-date documentation is important. This will help contributors understand the project and make it easier for them to contribute. 9 | 10 | This chapter will cover ways of maintaining code quality and documentation in your open source project. 11 | 12 | ## Code Reviews and High-Quality Contributions 13 | 14 | Code reviews are essential to maintaining code quality in an open source project. You should take the time to review each pull request and ensure that the proposed changes are high quality and do not introduce any new bugs or issues. You will receive pull requests from contributors who are new to the project and might not be familiar with the codebase. It is important to be patient and provide constructive feedback to help them improve their contributions. 15 | 16 | The following sections will cover some best practices for conducting code reviews and ensuring high-quality contributions. 17 | 18 | ### Conventional Commits 19 | 20 | [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) is a specification for structuring commit messages. It provides an easy way to understand the type of changes being made and helps maintain a clean and organized commit history. 21 | 22 | Using Conventional Commits in your project is highly recommended. You can encourage contributors to use it when making changes to the project by adding a guide to your contribution guidelines. The "[Commits](https://opensauced.pizza/docs/contributing/introduction-to-contributing/#commits)" section in the OpenSauced contributing guidelines asks contributors to use Conventional Commits. 23 | 24 | Here are some examples of Conventional Commit messages: 25 | 26 | ```text 27 | feat: add password reset functionality 28 | docs: update installation instructions 29 | chore(build): update dependencies 30 | fix(login): resolve issue with incorrect password validation 31 | refactor(api): streamline error handling in user service 32 | ``` 33 | 34 | ### Incomplete Pull Requests 35 | 36 | When you review a pull request, the first thing to check is that the proposed changes are complete and do not introduce new bugs or issues. It should also be clear what the proposed changes are about and what problem they are trying to solve. 37 | 38 | The contributor should link the proposed changes to an existing issue, and they should fill out all necessary information in the pull request template. If the pull request still needs to be completed, reach out to the contributor and ask them to provide the missing information. 39 | 40 | Remember that you will be dealing with contributors at all levels. Some might be new to open source and not realize they have failed to provide the necessary information. Giving constructive feedback with patience is important to help them improve their contributions. 41 | 42 | ### Large and Unfocused Pull Requests 43 | 44 | Sometimes, you might get pull requests that are too large and unfocused. Examples of large and unfocused pull requests include: 45 | 46 | - Pull requests that try to solve multiple issues at once 47 | - Pull requests that refactor large parts of the codebase 48 | - Pull requests that add a lot of new functionality 49 | 50 | Large pull requests can be challenging to review effectively and sometimes introduce bugs. In this situation, it is important to ask the contributor to break down the pull request into smaller, more focused pull requests. 51 | 52 | ### Automated Tests 53 | 54 | Setting up testing can help ensure that new contributions don't break existing functionality. Automated tests can be run on every pull request to ensure the new code passes all the tests. This will help maintain the quality of the code and make it easier for contributors to contribute. 55 | 56 | If some tests in the new pull request don't pass the checks, contact the contributor and ask them to fix the failing tests. Sometimes, the contributor might need help understanding why the tests are failing. In these cases, you need to work with the contributor to help them understand the problem and fix the failing tests. 57 | 58 | To learn more about testing, please refer to [this section](maintainer-powerups.md#testing) in the "Maintainer Power Ups" chapter. 59 | 60 | ### Code Quality Check 61 | 62 | It is important to check for code quality and good software engineering practices when conducting code reviews. This includes checking for proper variable naming, adherence to coding standards, and easy-to-read and understand code. A coding style guide is encouraged to help contributors understand your project's coding standards. 63 | 64 | Many tools can help you check for code quality. You can set up linting for your project to ensure no syntax errors or style issues. You can also set up code scanning tools to check for security vulnerabilities and other issues in the codebase. 65 | 66 | To learn more about these tools, please refer to [this section](maintainer-powerups.md#code-scanning-tools) in the "Maintainer Power Ups" chapter. 67 | 68 | ### Branch Protection Rules 69 | 70 | You can set up branch protection rules on GitHub to ensure all pull requests are reviewed before merging. You can also create a rule to require the number of approvals before a pull request can be merged. This not only assures that the maintainers have reviewed all contributions but also helps maintain the quality of the code, especially for larger projects. 71 | 72 | You can learn more about branch protection rules in the [official GitHub documentation](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule#about-branch-protection-rules). 73 | 74 | ## Project Documentation Maintainance 75 | 76 | Documentation is an essential part of maintaining an open source project. It helps contributors understand the project and makes it easier for them to contribute. So, it is important to keep the documentation up to date and ensure it reflects the project's current state. 77 | 78 | Regularly reviewing your project's documentation is recommended to ensure it is up-to-date and accurate. You can set a schedule for once a month to review your project's documentation manually. As you review the documentation, look for ways to improve it and make it easier for contributors to understand the project. Think about times when a new contributor struggled to understand the project and update the documentation to make it easier for them to understand. 79 | 80 | Another thing to consider in your review is running through the installation and setup instructions to ensure they are accurate and up to date. Are there any steps that still need to be included? Are there any steps that are no longer necessary? If so, update the documentation to reflect the project's current state. 81 | 82 | If you have a more complex project, consider adding diagrams or images to help explain the project's architecture. This can help contributors understand how the project is structured and make it easier for them to contribute. 83 | 84 | Now, let's move to the [next chapter](building-community.md), where we will discuss building and nurturing a welcoming and supportive community. 85 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/metrics-and-analytics.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: metrics-and-analytics 3 | title: "The Power of Open Source Metrics and Analytics for New Maintainers" 4 | sidebar_label: "The Power of Metrics and Analytics" 5 | keywords: ["metrics and analytics for open source maintainers", "understanding types of metrics in open source", "setting open source project goals", "understanding and interpreting open source project data", "making open source project data-driven decisions with OpenSauced", "Workspace OpenSauced", "Repository Insights Page OpenSauced", "Contributor Insight Page OpenSauced", "open source maintainers", "Open Source", "Open Source metrics"] 6 | --- 7 | 8 | Understanding what's happening with your project and contributors as it grows can be challenging for new maintainers. Think of open source metrics and analytics like a compass and map in your maintainer journey. Understanding metrics for open source projects and your own project can help you to set goals, identify project needs, and understand your community. This chapter will guide you through understanding, leveraging, and making decisions based on these insights to create a thriving open source project. 9 | 10 | ## Understanding Types of Open Source Metrics 11 | 12 | - **Code Metrics:** Code metrics provide a quantitative measure of the codebase's state, focusing on aspects that impact its quality, maintainability, and scalability. 13 | - **Community Metrics:** Community metrics shed light on the human element of the project, highlighting the growth, engagement, and overall health of the surrounding community. 14 | - **Project Health Metrics:** Project health metrics provide insights into the project's responsiveness, efficiency, and overall well-being. 15 | 16 | Considering a holistic approach to open source metrics can ensure you're not overly focused on one type to the detriment of others. For example, while high code quality is important, it should be balanced with strong community engagement to ensure a sustainable project future. 17 | 18 | Diverse metrics offer a more complete picture of a project's health and potential areas for growth or improvement. This could include balancing code metrics with community and project health metrics to ensure the project is not only technically sound but also welcoming and engaging for new contributors. It's about finding the right mix that supports your project's goals and values, fostering an environment where the codebase and the community thrive together. 19 | 20 | ## Setting Project Goals 21 | 22 | Setting clear and achievable goals can help you with project management. can help you with project management. Your goals might vary and include improving code quality, expanding the community, or streamlining issue resolution. When you set specific goals, you're better able to make decisions about prioritization and using resources (don't forget, time is a resource!). 23 | 24 | Remember, goals for your open source project are final. They will evolve as the project grows. Metrics can inform these changes, providing insights that reveal new opportunities or challenges. For instance, if a project sets an initial goal to increase contributor numbers but later finds that engagement or quality is suffering, it might shift focus towards improving onboarding processes or documentation. 25 | 26 | Maintainers should regularly review their goals in the context of the project's current metrics and broader trajectory. This adaptability ensures the project remains aligned with its community's needs and your vision as a maintainer. 27 | 28 | Choose metrics that align with your project's priorities. For example, if community growth is the goal, focus on new contributor rates and engagement levels. Below are some examples of metrics you may want to track. 29 | 30 | ### Community Growth Goals 31 | 32 | - **New Contributor Rates**: Tracking new contributors can be a key indicator of your project's appeal and growth potential. 33 | - **Active Contributors**: The count of contributors who have made at least one commit, pull request, or comment in the last month. 34 | - **Community Engagement**: Engagement metrics might include the number of comments on issues and pull requests, PR reviews, or the number of members in your community space (Slack, Discord, etc.). 35 | - **Retention Rate**: The percentage of new contributors who continue contributing over time, indicating how well the project retains its community members. 36 | 37 | ### Code Quality Goals 38 | 39 | - **Documentation Coverage**: Having documentation coverage ensures your project is accessible to newcomers and reduces the entry barrier for contributors. 40 | - **Commit Frequency**: Knowing the commit frequency can help you understand the project's development activity over time and can help you identify trends in contribution, potential stagnation, or support needs. 41 | 42 | ### Project Health Goals 43 | 44 | - **Issue Velocity**: How quickly issues are closed. This can reflect how quickly the concerns are acknowledged, an important aspect of project responsiveness. 45 | - **Pull Request Velocity**: How fast pull requests are closed. This can help you see how efficiently problems are solved. 46 | - **Benchmarking**: Use OpenSauced to establish current metrics as benchmarks, setting realistic targets for improvement. 47 | - **Timeline**: Set a clear timeline for achieving these goals, creating a sense of urgency and momentum. 48 | 49 | ## Understanding and Interpreting Open Source Metrics 50 | 51 | Understanding and interpreting data helps us to understand and share the story behind the numbers. Some ways to do this include: 52 | 53 | - **Trend Analysis**: Look for patterns over time, such as cyclical increases in contribution activity, to plan for future resource allocation. 54 | - **Anomaly Detection**: Identify unexpected spikes or drops in metrics and investigate potential causes, such as new feature releases or community events. 55 | - **Comparative Analysis**: Compare metrics against similar projects to gauge your project's performance in the broader open source ecosystem. 56 | 57 | ## Making Data-Driven Decisions 58 | 59 | Making data-driven decisions involves using the insights you've gathered to guide your project's direction. 60 | For example, if you see that your project has a high number of new contributors but a low retention rate, you might decide to focus on improving the onboarding process for new contributors. 61 | 62 | A great way to make data-driven decisions about your project is to create a Workspace in OpenSauced. This will allow you to bring together repositories, insights, and collaboration tools in one place. 63 | 64 | ## Creating a Workspace for Your Project with OpenSauced 65 | 66 | An OpenSauced [Workspace](https://opensauced.pizza/docs/features/workspaces/) serves as your project's command center, where you can learn more about your project and share it with others. This section guides you through creating and optimizing a Workspace to manage your project efficiently. 67 | 68 | To create a Workspace: 69 | 70 | 1. Log in to your [OpenSauced account](https://app.opensauced.pizza/). Once you're there, click the "Workspace" on the top bar, and you should see your personal workspace. 71 | 2. Click on the "Edit" button. You'll be prompted to name your workspace and add repositories. 72 | 3. Add your project's repository. 73 | 4. Click "Create Workspace" to create your Workspace. 74 | 75 | ![Workspaces](../_assets/images/workspace.png) 76 | 77 | Within the Repositories dashboard, you can view the following metrics, which are over a period of thirty days by default: 78 | 79 | - **Pull Requests**: This includes the total opened and merged pull requests for the repositories included in your workspace, as well as the velocity of pull requests being merged. 80 | - **Issues**: This includes the total opened and closed issues for the repositories included in your workspace, as well as the velocity of issues being closed. 81 | - **Engagement**: This includes the total stars, forks, and activity ratio for the repositories included in your workspace. 82 | 83 | :::tip 84 | 85 | You can customize the time period for these metrics by selecting 7 days, 30 days, or 90 days from the dropdown menu. 86 | 87 | ::: 88 | 89 | If you want to benchmark your project against other similar projects or if you'd like to create a list of repositories for inspiration, you can create a [Repository Insight](https://opensauced.pizza/docs/features/repo-insights/) in your Workspace. 90 | 91 | ### Creating a New Repository Insight Page 92 | 93 | To connect and track repositories, click the "+" next to "Insights" in the sidebar, then select "New Repository Insight." You will be redirected to a page where you can create your new Repository Insight Page. 94 | 95 | #### Using Your Repository Insights Page 96 | 97 | Once you have connected your repositories, you will be redirected to your Repository Insight Page. Here, you will see a dashboard with an overview of the repositories and the contributors who have contributed to them. 98 | 99 | There are three tabs that provide you with more information on these repositories: 100 | 101 | ##### Repositories Dashboard 102 | 103 | This dashboard allows you to view more detailed information on each repository, including activity levels, PR overview, PR velocity, spam PRs, contributors, and activity stats over the last 30 days. 104 | 105 | :::tip 106 | 107 | To learn and understand more about the data provided, see [Understanding Repository Insights Data](https://opensauced.pizza/docs/maintainers/understanding-repo-insights/). 108 | 109 | ::: 110 | 111 | ![repositories dashboard](../_assets/images/repos-insights.png) 112 | 113 | ##### Contributors Dashboard 114 | 115 | The Contributors dashboard allows you to view more detailed information on each contributor, including their activity levels, the number of repositories they contributed to, the date of their last contribution, their most used language, their time zone, the number of contributions, and their activity stats over the last 30 days. 116 | 117 | You can select and add your contributors to a [Contributor Insight Page](https://opensauced.pizza/docs/features/contributor-insights/) to learn more about them. 118 | 119 | ##### Activity Dashboard 120 | 121 | The Activity dashboard shows a graph of the last time each contributor created their PR and how many lines of code they've touched. It also provides more detailed information on each contributor when you hover over their image, including their latest PRs and repositories they've contributed to. Clicking their image will bring you to their profile on OpenSauced. 122 | 123 | You can use the information in this dashboard to help you learn about their engagement and general interests. It will be helpful if you want to collaborate with them or consider recruiting a maintainer for your project. 124 | 125 | ![activity graph](../_assets/images/activity-repos-insights.png) 126 | 127 | You can create a Contributor Insight Page to track your contributors and ensure you're growing a healthy open source community. 128 | 129 | ### Creating a Contributor Insight Page 130 | 131 | OpenSauced Contributor Insights feature allows you to categorize, monitor, and analyze various groups of contributors. This feature offers insights into each contributor's activities and contributions, helping you to track individual contribution histories, identify active engagement, recognize new or alumni contributors, and compare the performance of different contributors. 132 | 133 | The Contributor Insights features allow you to: 134 | 135 | - track the commits and PRs of the contributors on your list 136 | - filter your contributors by their activity level, including most active, new, and alumni 137 | - view the repositories your contributors have contributed to, the top programming languages they've used, and their time zones 138 | 139 | In terms of tracking metrics to understand your contributors, here are some things you could look at: 140 | 141 | - **Engaged contributors**: Keep tabs on contributors actively interacting with your repository. 142 | - **VIP contributors**: Highlight and track contributors you've identified as key maintainers or significant contributors. 143 | - **Alumni contributors**: Keep an eye on contributors who have decreased their engagement or left the project. 144 | 145 | To create a new Contributor Insight Page: 146 | 147 | 1. Click the "+" next to "Insights" in the sidebar. 148 | 2. Click "New Contributor Insight." You will be redirected to a page where you can create your new Contributor Insight Page. 149 | 150 | ![New Contributor Insight Page](../_assets/images/contrib-insight-new.png) 151 | 152 | 3. Give your page a name. 153 | 4. Add contributors to your page by searching for their GitHub username, syncing your GitHub Team, or importing your GitHub Following. 154 | 155 | ![team sync gif](../_assets/gifs/team-sync.gif) 156 | 157 | #### Using Your Contributor Insight Page 158 | 159 | Once you have created your page, you will be redirected to your Contributor Insight Page. Here, you will see a dashboard with an overview of the contributors. 160 | 161 | There are three tabs that provide you with more information on these repositories: 162 | 163 | ##### Overview Dashboard 164 | 165 | The Overview dashboard gives you a high-level view of the contributors in your Contributor Insight Page, including the total number of commits in the last 30 days and the types of contributors: Active, New, and Alumni. 166 | 167 | ##### Activity Dashboard 168 | 169 | The Activity dashboard gives you a graph view with more detailed information on each contributor, including the type of activity, repositories they've contributed to, and how they compare to each other. 170 | 171 | You can filter your Contributor Insight Page by All Contributors, Active Contributors, New Contributors, and Alumni Contributors. 172 | 173 | ![list graph](../_assets/images/list-graph.png) 174 | 175 | ##### Highlights Dashboard 176 | 177 | The Highlights dashboard gives you a list of the highlights that the contributors listed on your page have created. This is a great way to see what other contributors are up to and to show them support. 178 | 179 | :::tip 180 | 181 | To learn and understand more about the data provided, see [Understanding Contributor Insights Data](https://opensauced.pizza/docs/maintainers/understanding-contribs-insights/). 182 | 183 | ::: 184 | 185 | ### Leveraging OpenSauced for Project Success 186 | 187 | Embracing open source metrics and analytics through OpenSauced gives you the knowledge to make informed decisions and foster a culture of transparency and continuous improvement. By setting clear goals, analyzing project data, and engaging with your community, you create a foundation for sustained growth and success. Remember, the open source journey is a marathon, not a sprint. With OpenSauced, you have a partner every step of the way, guiding your project toward achieving its full potential. 188 | 189 | It's time to put what you've learned into practice! Let's move on to the [next chapter](getting-practical.md). 190 | -------------------------------------------------------------------------------- /docs/becoming-a-maintainer/your-team.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: your-team 3 | title: "Building Your Open Source Dream Team" 4 | sidebar_label: "Building Your Team" 5 | keywords: ["building open source team", "how to build an open source team", "assembling an open source maintainer team", "building an open source maintainer team", "finding new maintainers for open source projects", "identifying potential open source maintainers using OpenSauced", "best practices for onboarding new open source team members", "types of open source maintainers team", "triage team", "maintainer team", "documentation team", "onboarding open source maintainers", "GitHub permissions for open source teams", "offboarding open source team members", "open source maintainer recruitment strategies", "open source maintainers", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | Managing an open source project requires clear communication, empathy, and technical understanding. You might find that initially, you can do all or most of the work by yourself. That's great! If you want your project to grow and thrive, cultivating a diverse, motivated, and effective team around you can help you do that. This chapter looks at how to collaborate with your team effectively and offers guidance on identifying, onboarding, and empowering your open source squad. 9 | 10 | ## Types of Teams 11 | 12 | Creating teams on GitHub allows you to grant more permissions to a group of people depending on their team status. Here are some common team types and why a maintainer might find them beneficial: 13 | 14 | ### Triage Team 15 | 16 | Triage teams help handle incoming issues and pull requests efficiently. They categorize, prioritize, and assign issues to appropriate maintainers or contributors, reducing the maintainer's workload and ensuring timely attention to important matters. 17 | 18 | **Benefits**: Faster response to users, improved issue tracking, and better allocation of resources. 19 | 20 | ### Maintainer Team 21 | 22 | The maintainer team shares responsibility for code reviews, bug fixes, and feature development. A team of maintainers with specialized skills can handle larger projects, provide broader expertise, and ensure better code quality and consistency. 23 | 24 | **Benefits**: Reduced individual workload, faster development cycles, and more diverse perspectives on code and decisions. 25 | 26 | ### Documentation (Docs) Team 27 | 28 | The docs team creates and maintains high-quality documentation for users and contributors. A dedicated documentation team ensures clear, up-to-date information is readily available, reducing support requests and confusion. 29 | 30 | **Benefits**: Improved user experience, easier onboarding for new contributors, and less time spent answering basic questions. 31 | 32 | ### Other Team Variations 33 | 34 | - Security Team 35 | - Design Team 36 | - Community Team 37 | - Marketing Team 38 | - Core Team\* 39 | 40 | :::info 41 | 42 | Sometimes, the Maintainer Team and the Core Team are the same. Generally speaking, a Core Team often focuses on broader responsibilities like strategy, governance, and community management, providing insight into the project's direction. The Maintainer Team is more likely to focus on the project's day-to-day management and technical aspects. 43 | 44 | ::: 45 | 46 | ## Assembling Your A-Team: Adding New Members 47 | 48 | Now that you understand a little bit about teams, let's look at how to identify new members for your team. 49 | 50 | ### Recognizing the Need 51 | 52 | Just like a superhero team expands to face escalating threats, your project might reach a point where additional team members are needed. This could be when the workload starts to overwhelm you (solo maintainer) or your existing team or when you are taking on complex challenges that require specialized expertise. Identifying these challenging points is important for ensuring your project's continued momentum. 53 | 54 | ### Scouting for Superpowers 55 | 56 | Your search for new teammates should be deliberate and thoughtful. Look for contributors who have consistently shown commitment and skills through active involvement in your project. Their contributions to issues, pull requests, and community discussions can help you determine if they understand the project and your vision. Other things to consider are having enthusiasm, a collaborative spirit, and alignment with your project's goals. Open source projects thrive on passion and shared purpose. 57 | 58 | ### Inviting Your Team 59 | 60 | Once you've identified potential team members, extend a formal invitation. This public acknowledgment of their contributions not only shows your appreciation but also serves as an inspiration to other community members. Platforms like GitHub offer streamlined mechanisms for adding team members, making it a seamless process to welcome your new team members officially. 61 | 62 | ## Granting Team Permissions 63 | 64 | Each team should have a specific set of permissions that allow them to do what they need to succeed. Here are some common permissions that teams might need: 65 | 66 | ### Repository-Specific Permissions 67 | 68 | - **Read**: Allow members to view code, issues, and pull requests.
_Suitable for stakeholders, external collaborators, or those needing general visibility._ 69 | - **Triage**: Grant permission to manage issues and pull requests (assign, label, comment, close) but not directly modify code.
_Ideal for triage teams and community managers._ 70 | - **Write**: Allow members to push code, create branches, and open pull requests.
_Necessary for developers and maintainers who are actively contributing to the codebase._ 71 | - **Maintain**: Grant broader management permissions, including deleting branches, editing protected files, and managing releases.
_Suitable for core maintainers responsible for project health._ 72 | - **Admin**: Provide full control over the repository, including sensitive actions like deleting or changing its visibility.
_Reserved for trusted individuals or those with specific administrative needs._
73 | 74 | To access your team's permissions, navigate to your team's page on GitHub and click the "Settings" tab. From there, you can update your team's permissions in the "Member privileges" section. 75 | 76 | Here's what it will look like in GitHub: 77 | 78 | ![team permissions](../_assets/images/org-permissions.png) 79 | 80 | ### Additional Permissions to Consider 81 | 82 | - **Project Permissions (if using GitHub Projects)**: Grant access to manage projects, tasks, and milestones within a repository. 83 | - **Organization-Wide Permissions**: For organization-wide teams, consider granting permissions to manage members, billing, security settings, and other organization-level features. 84 | 85 | ### Best Practices for Team Permissions 86 | 87 | - **Start with restrictive permissions**: Grant the minimum permissions necessary for a team to perform its tasks. 88 | - **Review permissions regularly**: As projects evolve and team needs change, revisit permissions to ensure they remain appropriate. 89 | - **Utilize code owners**: Assign specific people or teams as code owners for different parts of the codebase to ensure appropriate oversight and review using the special [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file. 90 | 91 | ### Specific Examples 92 | 93 | - **Triage Team**: Grant "Triage" permission to the triage team's primary repository. 94 | - **Maintainer Team**: Grant "Write" or "Maintain" permissions to repositories they actively contribute to. 95 | - **Documentation Team**: Grant "Write" permission to the documentation repository, potentially "Read" access to other relevant repositories. 96 | 97 | You can see some of the options here: 98 | 99 | ![Team permissions GIF](../_assets/gifs/org-permissions.gif) 100 | 101 | ## Expanding the Horizons: Enlisting Additional Maintainers 102 | 103 | ### Specialization: The Key to Scale 104 | 105 | The need for specialized attention in specific areas might arise as your project grows in complexity. Documentation might require someone who can write for audiences at all levels of expertise, while community engagement might need a charismatic presence. Identifying these needs and recruiting contributors with relevant expertise allows you to delegate ownership and ensure all aspects of your project receive the dedicated care they deserve. 106 | 107 | ### Recruiting Maintainers & Team Members 108 | 109 | It is certainly possible that there's no contributor with the right skills and passion to take on a specific role. In those cases, you might need to look outside your existing community. Reach out to other projects or communities that might have individuals with the necessary expertise. 110 | 111 | One way to look for potential maintainers is to create a [Repository Insight Page](https://opensauced.pizza/docs/features/repo-insights/) with projects with a similar tech stack. This will allow you to see who contributes to those projects regularly, their most used languages, and more. From there, you can narrow your search to individuals who are already familiar with your project's stack and have a proven track record of contributions by adding them to a [Contributor Insight Page](https://opensauced.pizza/docs/features/contributor-insights/). Contributor Insights allows you to see more about where they're contributing, their timezone, activity level, and more. 112 | 113 | #### Creating a Repository and a Contributor Insight Page 114 | 115 | To connect and track your repositories, click the "+" next to "Insights" in the sidebar, then select "New Repository Insight." You will be redirected to a page where you can create your new Repository Insight Page. 116 | 117 | There are two ways to add repositories to your Repository Insight Page: 118 | 119 | 1. **Sync GitHub organization**. Syncing your GitHub organization is a good idea if you want a unified view of your project activities and the list of contributors to your project. 120 | 2. **Add individual repositories**. Adding individual repositories is a good idea if you want to look at similar repositories to recruit team members. 121 | 122 | ![Sync team GIF](../_assets/gifs/team-sync-insights.gif) 123 | 124 | From there, you can create a list of contributors you're interested in learning more about or connecting with by selecting them from the Contributors dashboard and creating a new Contributor Insight Page. 125 | 126 | ![Contributor insights list](../_assets/images/contributors-insights.png) 127 | 128 | ## Adding Team Members 129 | 130 | Once you've identified potential team members, reach out to them. Let them know why you're asking them to become a team member and provide them with a clear understanding of what you expect if they accept the role. This will help them make an informed decision and ensure they can meet your expectations. 131 | 132 | Check out [this guide](https://docs.github.com/en/organizations/organizing-members-into-teams/adding-organization-members-to-a-team) to learn how to add them to your team on GitHub. 133 | 134 | ## Onboarding New Team Members 135 | 136 | To ensure that your new team members are set up for success, it's important to have an onboarding process. This will help them to understand their responsibilities, the project's goals, and how they can contribute. 137 | 138 | Here are some things to consider: 139 | 140 | - **Roles & Responsibilities:** Clearly define the team member's role and responsibilities. This will help them to understand what they're responsible for and what they can expect from you. 141 | - **Communication:** Establish clear communication channels and expectations. This will help to ensure that everyone is on the same page and that you're able to communicate effectively. 142 | - **Goals:** Clearly define the project's goals and how the team members can contribute. This will help them to understand how they can contribute to the project's success. 143 | - **Timeline:** Set clear expectations for the timeline. This will help them understand what to do and the deadlines. 144 | 145 | One way to onboard your new team members is to have clear guidelines and include them in your documentation. If you need an idea for creating one, you can look at the [OpenSauced Community Maintainers Guidelines](https://opensauced.pizza/docs/contributing/opensauced-maintainers-guide/community-maintainers-guide/) or read [this blog post](https://dev.to/opensauced/the-missing-piece-why-your-project-needs-a-maintainer-onboarding-process-np0). 146 | 147 | ## Keeping Track of Your Team 148 | 149 | As your team grows, it's important to keep track of your team's participation and contributions. Depending on the number of people on your team, consider creating a [Contributor Insight Page](https://opensauced.pizza/docs/features/contributor-insights/) to keep track of your team's contributions. This will allow you to see who is contributing to your project and how often, and it will help you identify when it's time to remove someone from your team. 150 | 151 | ![Team sync GIF](../_assets/gifs/team-sync.gif) 152 | 153 | ## Saying Farewell: Handling Team Departures 154 | 155 | As time passes and people's lives change, you'll find that even the most dedicated teams might face departures. Inactivity, discord with project values, or mutual agreement can lead to changes in your team. It's important to approach these situations with respect and understanding. Privately communicate the reasons behind the decision, acknowledge the individual's contributions, and express gratitude for their time and effort. Remember, fostering a positive and supportive environment, even during departures, contributes to the overall well-being of your project community. 156 | 157 | Check out [this guide](https://docs.github.com/en/organizations/organizing-members-into-teams/removing-organization-members-from-a-team) on GitHub for removing the person from your team. 158 | 159 | ## Conclusion 160 | 161 | Remember, the team is there to support you and the project and to help you achieve your goals. As you grow your team, keep in mind that you're not just adding people to your project; you're adding people to your community. Make sure you're adding people who align with your project's values and goals and who will be a positive addition to your community. 162 | 163 | In the [next chapter](metrics-and-analytics.md), you will learn how metrics and analytics are helpful for new maintainers. 164 | -------------------------------------------------------------------------------- /docs/intro-to-oss/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: Contributor-README 3 | title: "Intro to Open Source with OpenSauced" 4 | sidebar_label: "Intro to Open Source" 5 | keywords: ["README", "Intro to Open Source with OpenSauced", "open source course", "open source course for beginners", "contributing to open source course", "contributing to open source course for beginners", "open source contributors", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | Welcome to the Intro to Open Source Course with OpenSauced! This course is designed to provide you with an introduction to open source and guide you through the process of contributing to open source projects. 9 | 10 | ## Prerequisites 11 | 12 | Before diving into the world of open source, it's essential to have a basic understanding of programming concepts and some experience working with code. While the course will provide examples and demos, you'll get the most out of the material if you have some prior knowledge. 13 | 14 | Additionally, this course assumes that you are familiar with Git and GitHub. Git is a widely-used version control system, and GitHub is a popular platform for hosting and collaborating on Git repositories. If you're not already familiar with Git and GitHub, we recommend taking some time to learn the basics before starting this course. 15 | 16 | ## Course Overview 17 | 18 | The course is divided into chapters, each covering a different aspect of open source: 19 | 20 | ### [What is Open Source?](what-is-open-source.md) 21 | 22 | This chapter provides an introduction to open source, its history, and its importance in today's software development landscape. 23 | 24 | ### [Why Open Source?](why-open-source.md) 25 | 26 | In this chapter, you'll learn about the benefits of open source software, such as increased collaboration, faster development, and improved quality. 27 | 28 | ### [Tools to be Successful](tools-to-be-successful.md) 29 | 30 | Discover the key tools and platforms necessary for a successful journey in open source development. From Git and GitHub for version control and collaboration to CodeSee for code visualization and VS Code as your code editor, this chapter provides an overview of how to leverage these essential tools. 31 | 32 | ### [How to Contribute to Open Source](how-to-contribute-to-open-source.md) 33 | 34 | This chapter covers finding projects to work on, submitting contributions, onboarding contributors to new projects, and the outcomes after submitting contributions. Tips for finding projects include browsing GitHub and GitLab, following personal interests, joining open source communities, and utilizing platforms like OpenSauced. 35 | 36 | ### [The Secret Sauce](the-secret-sauce.md) 37 | 38 | This chapter focuses on providing lesser-known strategies and tips for making a lasting impact in the open source community. This chapter provides strategies for finding issues, gaining traction in your open source journey, and leveraging OpenSauced to build your open source resume. 39 | 40 | ### [Types of Open Source Contributions](types-of-contributions.md) 41 | 42 | This chapter explains the non-coding and coding types of contributions involved with open source projects. 43 | 44 | ### Additional Information 45 | 46 | As this is the beginning of your open source journey, we've also provided additional information in these chapters: 47 | 48 | - [Glossary](glossary.md): A glossary of common terms and definitions used in open source. 49 | - [Additional Resources](additional-resources.md): A list of resources for further learning about open source, including blog posts, tutorials, and guides. 50 | 51 | ## Let's Get Started 🚀 52 | 53 | Now that we've set the stage, it's time to embark on your open source journey! In the [next chapter](what-is-open-source.md), we'll dive into the definition of open source and explore its history, laying the groundwork for a deeper understanding of open source collaboration. Let's get started! 54 | 55 | :::tip 56 | 57 | Each chapter builds on the previous one, so we recommend reading them in order. 58 | 59 | ::: 60 | 61 | As you work through the course, we encourage you to experiment with the tools and concepts covered in each chapter. The best way to learn is by doing, so try contributing to an open source project or building your project from scratch! 62 | 63 | ## Building Your Open Source Resume 64 | 65 | One of the unique features of this course is that it guides you to build your open source resume using OpenSauced. OpenSauced is a platform that helps you track and showcase your open source contributions, making it easier to get noticed by potential employers and collaborators. 66 | 67 | To learn more about using OpenSauced to build your open source resume, check out the "[Building Your Open Source Resume](the-secret-sauce.md#building-your-open-source-resume)" section in "The Secret Sauce" chapter. 68 | 69 | ## Expectations 70 | 71 | This course is designed to provide you with a solid foundation in open source collaboration. While we'll cover a range of topics and provide examples, demos, and opportunities for hands-on practice, it's essential to have realistic expectations about what you can achieve during the course. 72 | 73 | 1. **Practice is crucial**: Learning about open source is just the beginning; to truly develop your skills and become a proficient contributor, you'll need to practice consistently. Keep in mind that the more you contribute to open source projects, the more you'll learn and grow as a developer. 74 | 75 | 2. **Patience is key**: Becoming proficient in open source collaboration takes time and effort. Don't be discouraged if you encounter challenges along the way; remember that every contribution, no matter how small, is valuable and helps improve the project. 76 | 77 | 3. **Engagement with the community**: Open source is more than just code; it's about the people who collaborate and contribute to projects. Engage with the community by asking questions, sharing your knowledge, and supporting others. Building relationships with other contributors will enhance your open source experience and help you grow as a developer. 78 | 79 | 4. **Continuous learning**: Open source is a rapidly evolving field, with new projects, tools, and technologies emerging all the time. Stay curious and open to learning, and take advantage of resources like documentation, tutorials, and community forums to expand your knowledge and stay up-to-date with the latest developments. 80 | 81 | 5. **Developing a growth mindset**: Embrace the challenges and opportunities that come with open source collaboration. Adopt a growth mindset, which focuses on learning, improvement, and resilience. By viewing obstacles as opportunities for growth, you'll be better equipped to navigate the complex world of open source and achieve success in your contributions. 82 | 83 | --- 84 | 85 | We hope you find this course informative and useful! If you have any questions or feedback, please don't hesitate to open an issue or reach out to us in the [Community](https://github.com/orgs/open-sauced/discussions). 86 | 87 | Happy learning and contributing! 88 | -------------------------------------------------------------------------------- /docs/intro-to-oss/additional-resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: additional-resources 3 | title: "Additional Resources" 4 | sidebar_label: "Additional Resources" 5 | keywords: ["additional resources", "resources to contribute to open source", "guides and tutorials resources to contribute to open source", "blog posts resources to contribute to open source", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | On this page, you can find resources to help you learn further about contributing to open source: 9 | 10 | ## Guides and Tutorials 11 | 12 | - [Open Source Guides](https://opensource.guide/) by GitHub: Comprehensive guides on various aspects of open source, including getting started, contributing, maintaining projects, and building communities. 13 | 14 | - [First Contributions](https://github.com/firstcontributions/first-contributions) by Roshan Jossey: A beginner-friendly guide that walks you through making your first contribution to an open source project. 15 | 16 | - [A Beginner’s Guide to Open Source Software Development](https://training.linuxfoundation.org/training/beginners-guide-open-source-software-development/) by The Linux Foundation: A free online course that covers the basics of open source software, including its history, licenses, and development models. 17 | 18 | - [Mozilla's Open Source Student Network (OSSN)](https://community.mozilla.org/en/): Provides resources and support for students interested in open source, including guides, events, and mentorship opportunities. 19 | 20 | - [Introduction to GitHub and Open Source Projects](https://www.digitalocean.com/community/tutorial_series/an-introduction-to-open-source) by DigitalOcean: A beginner-friendly tutorial series that covers the basics of open source, including how to find projects to contribute to, understand the codebase, and submit contributions. 21 | 22 | - [Open Source Friday](https://opensourcefriday.com/) by GitHub: A global movement that encourages individuals and organizations to contribute to open source every Friday. The website provides resources and guides on how to get started in open source and find projects to contribute to. 23 | 24 | ## Blog Posts 25 | 26 | - [Beyond Content Creation: How Open Source Contributions Can Help You Get Noticed](https://dev.to/opensauced/beyond-content-creation-how-open-source-contributions-can-help-you-get-noticed-4l5n) 27 | - [Writing Your First Pull Request: Tips, Best Practices, and AI-Powered Tools for Success](https://dev.to/opensauced/writing-your-first-pull-request-tips-best-practices-and-ai-powered-tools-for-success-3bg9) 28 | - [How to Contribute to Open Source without Knowing How to Code: A guide with project suggestions](https://dev.to/opensauced/how-to-contribute-to-open-source-without-knowing-how-to-code-a-guide-with-project-suggestions-59e5) -[How to Write a Good Issue: Tips for Effective Communication in Open Source](https://dev.to/opensauced/how-to-write-a-good-issue-tips-for-effective-communication-in-open-source-5443) 29 | - [Good first issues don't exist](https://opensauced.pizza/blog/good-first-issues-dont-exist) 30 | -------------------------------------------------------------------------------- /docs/intro-to-oss/conclusion.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: conclusion 3 | title: "Conclusion" 4 | sidebar_label: "Conclusion" 5 | keywords: ["conclusion", "steps to continue open source contributions", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | As we wrap up this course on getting started with open source, let's recap the key takeaways and discuss what's next in your open source journey. 9 | 10 | ## Takeaways 11 | 12 | Throughout this course, we've covered a range of topics designed to help you understand and navigate the world of open source: 13 | 14 | - **[What is Open Source?](what-is-open-source.md)**: We discussed the definition of open source, its history, and the core principles that guide the open source movement. 15 | 16 | - **[Why Open Source?](why-open-source.md)**: We explored the benefits of engaging with open source projects, including access to knowledge, community, and skills development. 17 | 18 | - **[Tools to be Successful](tools-to-be-successful.md)**: We introduced essential tools and platforms for open source contributors, such as GitHub, Git, CodeSee, Visual Studio Code, and Discord. 19 | 20 | - **[How to Contribute to Open Source](how-to-contribute-to-open-source.md)**: We discussed the process of finding projects to work on, submitting contributions, onboarding to new projects, and what happens after your contribution is submitted. 21 | 22 | - **[The Secret Sauce](the-secret-sauce.md)**: We shared strategies for getting started with open source contributions, gaining traction in your contributions, and developing your open source resume using OpenSauced. 23 | 24 | - **[Types of Open Source Contributions](types-of-contributions.md)**: We shared the coding and non-coding types of contributions in open source, along with examples. 25 | 26 | By understanding these concepts and applying the strategies we've discussed, you'll be well-equipped to embark on a successful open source journey. 27 | 28 | ## What's Next? 29 | 30 | With the knowledge and tools you've gained from this course, you're ready to dive into the world of open source and start making meaningful contributions. Here are some next steps to help you continue your open source journey: 31 | 32 | 1. **Identify your interests and goals**: Before you start contributing to open source projects, take some time to think about your interests, passions, and goals. This will help you identify projects that align with your values and objectives. 33 | 34 | 2. **Find projects to contribute to**: Use platforms like GitHub, OpenSauced, and CodeTriage to discover open source projects that align with your interests and skills. Look for projects with active communities, clear documentation, and well-defined contribution guidelines. 35 | 36 | 3. **Start contributing**: Once you've identified a project to contribute to, start by tackling small, manageable tasks to build your confidence and gain experience. As you become more comfortable, take on more complex tasks and challenges. 37 | 38 | 4. **Connect with the open source community**: Join online forums, chat platforms, and social media groups related to the projects you're interested in. Engage with other contributors, ask questions, and share your knowledge. 39 | 40 | 5. **Attend events and conferences**: Participate in open source events, conferences, and meetups to learn from others, network with fellow developers, and stay up-to-date on the latest trends and best practices in the open source world. 41 | 42 | 6. **Share your experiences**: Document your open source journey by writing blog posts, creating tutorials, or giving presentations. This will not only help others learn from your experiences but also establish you as a thought leader in the open source community. 43 | 44 | 7. **Continue learning**: Open source is a dynamic and ever-evolving field. Stay current with the latest tools, techniques, and best practices by attending workshops, taking online courses, and reading articles and books on open source development. We've included an [additional resources section](additional-resources.md) for more information. 45 | 46 | In conclusion, embarking on an open source journey is a rewarding and enriching experience that can help you develop new skills, connect with like-minded individuals, and make a lasting impact on the projects you work on. With the knowledge and tools you've gained from this course, you're well-prepared to take on the exciting challenges and opportunities that await you in the open source world. So go forth and start contributing – the open source community eagerly awaits your participation! 47 | -------------------------------------------------------------------------------- /docs/intro-to-oss/glossary.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: glossary 3 | title: "Glossary" 4 | sidebar_label: "Glossary" 5 | keywords: ["glossary", "open source glossary", "glossary for open source contributors", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | ## Branch 9 | 10 | A branch is a separate version of the code that's created for development purposes. Branches allow contributors to experiment with changes without affecting the main codebase. When changes are ready to be merged into the main codebase, they're typically submitted as a pull request. 11 | 12 | ## Bug 13 | 14 | A bug refers to an error, flaw, or defect in code that adversely affects the proper functioning of the software. Open source projects often depend on contributions from the community to identify and rectify these bugs. 15 | 16 | ## Clone 17 | 18 | Cloning is the process used to copy an existing Git repository into a new local directory. The `git clone` command will create a new local directory for the repository, copy all the contents of the specified repository, create the remote tracked branches, and checkout an initial branch locally. By default, Git clone will create a reference to the remote repository called origin. 19 | 20 | ## Contributor 21 | 22 | A contributor is anyone who makes changes, additions, or suggestions to an open source project. Contributors can be developers, designers, writers, testers, or anyone else who helps to make the project better. 23 | 24 | ## Core Member 25 | 26 | A core member is a contributor who has been granted additional privileges or responsibilities within an open source project. Core members are typically trusted contributors who have demonstrated a deep understanding of the project and have made significant contributions to its development. 27 | 28 | ## Docs 29 | 30 | Docs is an abbreviation for "documentation". It primarily explains how to implement and use a product or an open source project. It also provides information on how to contribute to the project and expectations for contributors. Documentation is often written using [Markdown](https://www.markdownguide.org/), a lightweight markup language. 31 | 32 | ## Fork 33 | 34 | A fork is a copy of a repository. When you fork a repository, you create a new copy of the codebase that you can modify and experiment with without affecting the original codebase. 35 | 36 | ## Issue 37 | 38 | An issue is a problem or bug that needs to be addressed in the code. Issues can be created by anyone, and they're often used to keep track of bugs, feature requests, and other tasks that need to be done. 39 | 40 | ## Maintainer 41 | 42 | A maintainer is a person or a group of people responsible for maintaining a specific open source project. Maintainers are typically responsible for reviewing and accepting or rejecting contributions from other contributors. They also have the authority to make final decisions about the direction and scope of the project. 43 | 44 | ## Markdown 45 | 46 | Markdown is a lightweight markup language commonly used for creating formatted text documents. It is widely used for creating documentation and README files in software development due to its simplicity and readability. 47 | 48 | ## Merge 49 | 50 | Merging is the process of combining changes from one branch into another. When a pull request is accepted and merged, the changes made in the pull request become part of the main codebase. 51 | 52 | ## Onboarding 53 | 54 | Onboarding documentation helps new team members or collaborators quickly become familiar with a project's structure, goals, and processes. 55 | 56 | ## OSS Projects 57 | 58 | OSS stands for "Open Source Software" projects. These are software projects where the source code is made available to the public, allowing anyone to view, use and modify the software. 59 | 60 | ## Pull Request 61 | 62 | A pull request is a request from a contributor to a maintainer for changes made to the code to be pulled into a codebase. 63 | 64 | ## Quality Assurance 65 | 66 | Quality assurance in open source projects involves testing, reviewing, and ensuring the software meets the desired standards. Community members often contribute to testing and reporting issues to improve the software's quality. 67 | 68 | ## Release Notes 69 | 70 | Release notes are documents that detail changes, enhancements, bug fixes, and new features in each software release. They inform users and stakeholders about what to expect in a new version of the software. 71 | 72 | ## Repository 73 | 74 | A repository is a central location where code is stored and managed. In open source, repositories are often hosted on platforms like GitHub, GitLab, or Bitbucket. Each repository can contain one or more projects, and contributors can submit changes to the code by making pull requests. 75 | 76 | ## Style Guide 77 | 78 | A style guide is a set of rules and conventions that define the preferred formatting, writing style, and visual elements used in documentation and other content. This helps maintain consistency and clarity across documents, making them easier to read and understand. 79 | -------------------------------------------------------------------------------- /docs/intro-to-oss/the-secret-sauce.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: the-secret-sauce 3 | title: "The Secret Sauce" 4 | sidebar_label: "The Secret Sauce" 5 | keywords: ["open source secret sauce", "how to make a lasting impact in open source", "open source resume builder", "building open source resume", "building open source resume with OpenSauced", "finding issues in open source", "addressing issues in open source", "gaining recognition in open source", "building a strong open source profile", "becoming a valuable contributor to open source projects", "tips for building a strong reputation in open source", "effectively highlight open source contributions", "open source contribution", "open source contribution for beginners", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | In this chapter, we'll share some lesser-known strategies and tips for making a lasting impact in the open source community. We'll discuss how to focus on open issues, gain traction in your contributions, and develop your open source resume using OpenSauced. 9 | 10 | ## Open Issues — More than PRs that Fix Typos 11 | 12 | While fixing typos and improving documentation are valuable contributions to open source projects, it's essential to look beyond these low-hanging fruits and focus on addressing open issues. Tackling open issues not only helps the project move forward but also allows you to develop a deeper understanding of the codebase and demonstrate your problem-solving abilities. 13 | 14 | Here are some tips for finding and addressing open issues: 15 | 16 | 1. **Browse the issue tracker**: Most open source projects use an issue tracker to manage bugs, feature requests, and other tasks. Browse the issue tracker to find issues that align with your interests and skills. 17 | 18 | 2. **Look for beginner-friendly issues**: Many projects use labels like "good first issue" or "help wanted" to indicate issues that are suitable for newcomers. Start with these issues to build your confidence and gain experience before tackling more complex tasks. 19 | 20 | 3. **Understand the issue**: Before diving into an issue, make sure you understand the problem and the desired outcome. If you're unsure about anything, ask questions or seek clarification from the project maintainers or other contributors. 21 | 22 | 4. **Communicate your intentions**: Before you start working on an issue, let the project maintainers and other contributors know that you're interested in addressing it. This can help avoid duplicated efforts and ensure that everyone is on the same page. 23 | 24 | 5. **Test your changes**: Once you've addressed an issue, test your changes thoroughly to ensure they work as expected and don't introduce new problems. 25 | 26 | By focusing on open issues rather than just fixing typos, you'll make a more significant impact on the projects you contribute to and demonstrate your commitment to the open source community. 27 | 28 | ## Getting Traction in Contributions 29 | 30 | As you become more experienced in open source contributions, you may want to increase your impact on the projects you work on and gain recognition for your efforts. Here are some strategies for gaining traction in your contributions: 31 | 32 | 1. **Become a regular contributor**: Consistently contribute to the same projects over time. This will help you develop a deeper understanding of the codebase, build relationships with other contributors, and establish yourself as a valuable member of the community. 33 | 34 | 2. **Take on challenging tasks**: As you gain experience, tackle more complex issues and features. This will not only help you grow as a developer but also demonstrate your ability to handle challenging tasks and contribute meaningfully to the project. 35 | 36 | 3. **Collaborate with others**: Open source is all about collaboration. Work with other contributors to address issues, develop features, and share knowledge. By collaborating effectively, you'll not only improve the project but also build a strong network of connections in the open source community. 37 | 38 | 4. **Share your expertise**: Share your knowledge and insights by writing blog posts, creating tutorials, or giving presentations about the projects you work on. This will not only help others learn from your experiences but also establish you as a thought leader in the open source community. 39 | 40 | 5. **Mentor new contributors**: As you become more experienced in open source contributions, consider mentoring new contributors who are just starting their open source journey. This can help you give back to the community, develop your leadership skills, and build a positive reputation. 41 | 42 | ## Building Your Open Source Resume 43 | 44 | Building a strong open source resume can help you showcase your skills, experience, and contributions to potential employers, collaborators, and the wider developer community. OpenSauced is an excellent tool for tracking your open source contributions and developing your open source resume. Let's look at how you can use OpenSauced to support your open source journey. 45 | 46 | 1. **Sign up for an OpenSauced account**: if you haven't already created an account, visit [opensauced.pizza](https://opensauced.pizza/) and sign up for an account using your GitHub credentials. 47 | 48 | 2. **Visit Your Public Profile Page**: After signing up, a public profile page will be created for you. This page will display your GitHub profile information and a list of your open source contributions. You can navigate to it by clicking on your username in the top right corner of the page. 49 | 50 | ![Navigating to public profile page at OpenSauced](../_assets/images/opensauced-profile.png) 51 | 52 | 3. **Build Your Open Source Resume**: From here, you'll be able to add highlights to Pull Requests and Issues that you've contributed to. You can also add a description and links to your open source resume. These will be aggregated into a single page that you can share with others, as well as a summary of your contributions that will be displayed on your public profile page. 53 | 54 | Let's showcase our guestbook contribution from the previous chapter! In your profile, you'll see a "Highlights" section with a text input. When you click this, you'll be able to add a title, some thoughts, and a link to your PR. This will be displayed on your public profile page. Let's add a highlight for our guestbook contribution. 55 | 56 | ### Effectively Highlight Your Contributions 57 | 58 | Important information to include when you're highlighting your contributions: 59 | 60 | - New material you've created, 61 | - Project details (tools, libraries, size, and complexity), 62 | - The type of your contributions: bug fix, feature, performance, documentation, etc., 63 | - The details of your contribution including improvements and impacts made on the project and on the community, 64 | - Collaboration and teamwork details. 65 | 66 | ### Formatting Your Highlight 67 | 68 | To be most effective in highlighting your contributions, we recommend using the following format: 69 | 70 | - **Description**: When highlighting your contribution, we recommend mentioning the impact that it had on the overall project. This would be helpful in highlighting your qualifications for job positions, especially if you have employment gaps. Consider using the following model to help you craft this highlight into a story: 71 | - Success verb + noun + metric + outcome. 72 | - Example: While I was reviewing some pull requests for this year's GirlScript Summer of Code, I noticed that most of them would not merge in spite of me and the owner giving approvals. So, I **created a GitHub Action where pull requests automatically merge once they have passed the deployment steps(successive verb + noun)**, which **increased productivity rates by 80%(metric + outcome).** 73 | - **Add a repo**: Provide the complete name of the repository to which you are making contributions. 74 | - **URL**: Paste the URL to your pull request, issue or your blog post. 75 | 76 | ![Adding a highlight to a profile at OpenSauced](../_assets/images/opensauced-highlights.png) 77 | 78 | - **Share it!**: Once you've built up a portfolio of open source contributions, you can share your OpenSauced resume with others by clicking the share button in the header of your profile page. This can be especially helpful when applying for jobs, networking with other developers, or promoting your work in the open source community. 79 | 80 | By leveraging OpenSauced to track your open source contributions and develop your resume, you'll be better equipped to showcase your skills, experience, and impact in the open source community. Additionally, you can refer to the [Job Seekers Guide](https://opensauced.pizza/docs/opensauced-guides/job-seekers-guide/job-seekers-guide-introduction/) in our docs to learn how to use OpenSauced to land a job in the tech industry. 81 | 82 | In conclusion, getting started with open source contributions and making a lasting impact on the projects you work on requires a combination of technical skills, collaboration, and persistence. By focusing on open issues, gaining traction in your contributions, and leveraging tools like OpenSauced, you'll be well on your way to a successful and fulfilling open source journey. 83 | 84 | In the [next chapter](types-of-contributions.md), we will discuss various types of open source contributions. 85 | -------------------------------------------------------------------------------- /docs/intro-to-oss/tools-to-be-successful.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: tools-to-be-successful 3 | title: "Tools to be Successful" 4 | sidebar_label: "Tools to be Successful" 5 | keywords: ["tools to be successful", "tools to contribute to open source projects", "Github & Git", "GitHub", "Git", "Getting Started with Git and GitHub", "Git tutorial", "VS Code", "VS Code and Git tutorial", "VS Code benefits", "contributing to open source with VS Code", "Discord", "Discord benefits when contributing to open source projects", "contributing to open source", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | To be successful in your open source journey, it's essential to familiarize yourself with the tools and platforms commonly used by the community. These tools will help you collaborate effectively, manage your projects, and contribute to open source projects. In this chapter, we'll discuss the following essential tools for open source collaboration: 9 | 10 | - GitHub & Git 11 | - Visual Studio Code (VS Code) 12 | - Discord 13 | 14 | ## Prerequisites 15 | 16 | Before completing the following walkthrough, complete the following: 17 | 18 | - Create a [GitHub account](https://github.com/) 19 | - Download [VS Code](https://code.visualstudio.com/) 20 | 21 | ## GitHub & Git 22 | 23 | ### Introduction to Git 24 | 25 | Git is a distributed version control system designed to handle everything from small to very large projects with speed and efficiency. It was created by Linus Torvalds, the creator of the Linux kernel, to manage the development of the Linux kernel itself. 26 | 27 | Git allows developers to track changes in their code, collaborate with other developers, and manage multiple versions of their projects. Some of the key features of Git include: 28 | 29 | - **Branching**: Git allows developers to create branches, which are separate copies of their codebase. This enables them to work on new features or bug fixes without affecting the main codebase. Once the changes are complete, they can merge the branch back into the main codebase. 30 | - **Staging Area**: Git provides a staging area where developers can prepare their changes before committing them to the repository. This allows them to review and organize their changes before making them permanent. 31 | - **Distributed Version Control**: Unlike centralized version control systems, Git is a distributed version control system. This means that every developer has a complete copy of the repository on their local machine, allowing them to work offline and independently of a central server. 32 | 33 | ### Introduction to GitHub 34 | 35 | GitHub is a web-based platform for version control and collaboration that uses Git as its underlying technology. It provides a simple and user-friendly interface for managing Git repositories, as well as a host of features and tools for collaborating with other developers. 36 | 37 | Some of the key features of GitHub include: 38 | 39 | - **Issue Tracking**: GitHub provides an integrated issue tracking system that allows developers to create, assign, and manage issues related to their projects. Issues can be categorized using labels, milestones, and assignees, making it easy to keep track of project progress and prioritize tasks. 40 | - **Pull Requests**: GitHub introduces the concept of pull requests, which allow developers to propose changes to a project's codebase. Pull requests enable code review, discussion, and collaboration before changes are merged into the main codebase. 41 | - **Forking**: GitHub allows users to create a copy of a repository, known as a fork. This enables them to make changes to the codebase without affecting the original project. Once the changes are complete, they can submit a pull request to have their changes reviewed and potentially merged into the main codebase. 42 | - **GitHub Actions**: GitHub Actions is a powerful automation tool that allows you to create custom workflows to automate tasks like building, testing, and deploying your code. 43 | 44 | ### Getting Started with Git and GitHub 45 | 46 | To get started with Git and GitHub, follow these steps: 47 | 48 | 1. **Install Git**: Download and install Git on your computer by visiting the [official Git website](https://git-scm.com/) and following the installation instructions for your operating system. 49 | 50 | 2. **Configure Git**: After installing Git, open a terminal or command prompt and configure your Git user information by running the following commands: 51 | 52 | ```bash 53 | git config --global user.name "Your Name" 54 | git config --global user.email "your.email@example.com" 55 | ``` 56 | 57 | Replace `Your Name` with your full name and `your.email@example.com` with the email address you used to sign up for GitHub. 58 | 59 | #### Practicing Contributing with VS Code 60 | 61 | To practice using GitHub, we're going to walk through creating a repository, cloning the repository, making changes, and pushing those changes. 62 | 63 | 1. **Create a new repository**: Log in to your GitHub account and click the green "New" button on the sidebar. Alternatively, click the "+" icon in the upper right corner and select "New repository" from the dropdown menu. 64 | 65 | Choose yourself as the owner of the repository, and enter a name for your repository. For this example, we'll use `practice-repository`. 66 | 67 | ![Create new repository on GitHub](../_assets/images/new-repo.png) 68 | 69 | Choose whether you want it to be public or private. You can also choose to initialize the repository with a README file, a `.gitignore` file, and/or a license. 70 | 71 | For this example, initialize the repository with a README file. 72 | 73 | 2. **Clone the repository**: Once you have created a new repository, you can clone it to your local machine by running the following command in your terminal or command prompt: 74 | 75 | ```bash 76 | git clone https://github.com/YOUR-USERNAME/REPOSITORY-NAME.git 77 | ``` 78 | 79 | Replace "YOUR-USERNAME" with your GitHub username and "REPOSITORY-NAME" with `practice-repository`. 80 | 81 | 3. **Access your repository in your code editor**: For this example, we're using VS Code. Open VS Code, navigate to the file tab, and then open your `practice-repository`. 82 | 83 | 4. **Make changes and commit**: There should be one file in your repository: `README.md`. Inside that file, below `# practice-repository`, type 'hello world!' Once you have made changes, you can stage and commit them. 84 | 85 | Open your terminal and make sure you are in the right directory. For example, my coding projects are inside of my `Projects` folder. Using my terminal, I would access this repository by running this command: 86 | 87 | ```bash 88 | cd projects/practice-repository 89 | ``` 90 | 91 | Once in the correct repository, use the following commands to add the changes you made and write a commit message with a description of the changes: 92 | 93 | ```bash 94 | git add . 95 | git commit -m "Your commit message" 96 | ``` 97 | 98 | Replace "Your commit message" with a brief description of the changes you made. 99 | 100 | 5. **Push your changes**: After committing your changes, you can push them to your remote GitHub repository by running the following command: 101 | 102 | ```bash 103 | git push origin main 104 | ``` 105 | 106 | This will push your changes to the `main` branch of your remote repository. If you want to check your work, navigate to your GitHub repository. You should now see 'hello world!' in your README.md file. 107 | 108 | You have now successfully set up Git and GitHub on your local machine and are ready to collaborate on open source projects! 109 | 110 | ## VS Code 111 | 112 | Visual Studio Code (VS Code) is a popular, free, and open source code editor developed by Microsoft. It supports a wide range of programming languages and offers many features that make it a great choice for open source development, including: 113 | 114 | - **Built-in Git support**: VS Code provides built-in support for Git, allowing you to manage your Git repositories, stage and commit changes, and resolve merge conflicts directly from the editor. 115 | - **Extensibility**: VS Code offers a rich ecosystem of extensions that can enhance your development experience and add support for additional languages, tools, and frameworks. 116 | - **Integrated terminal**: VS Code includes an integrated terminal that allows you to run commands, scripts, and build tasks directly from the editor. 117 | - **Customizable**: VS Code is highly customizable, allowing you to tailor the editor to your preferences and workflow. You can customize the theme, keybindings, and settings to create a personalized development environment. 118 | 119 | To download and install VS Code, visit the [official website](https://code.visualstudio.com/) and follow the instructions for your operating system. 120 | 121 | ## Discord 122 | 123 | Discord is a popular messaging and voice chat platform that is widely used by open source communities for communication and collaboration. By joining Discord servers related to your interests and projects, you can: 124 | 125 | - **Connect with other developers**: Discord allows you to chat with other developers, ask questions, and share your knowledge with the community. 126 | - **Stay up-to-date**: Many open source projects use Discord to share updates, announcements, and other important information. By joining their servers, you can stay informed about the latest developments and contribute more effectively. 127 | - **Participate in discussions**: Discord servers often host discussions on various topics related to open source development. By participating in these discussions, you can learn from others, share your insights, and contribute to the collective knowledge of the community. 128 | - **Find collaboration opportunities**: Discord servers can be a great place to find others who share your interests and are looking for collaboration opportunities. By networking with other developers, you can discover new projects to work on and form valuable partnerships. 129 | 130 | To get started with Discord, visit the [official website](https://discord.com/) and sign up for an account. Once you have an account, you can search for open source communities and projects on platforms like GitHub or GitLab to find their Discord servers and join the conversation. 131 | 132 | By familiarizing yourself with these tools and platforms, you'll be equipped to collaborate effectively, manage your projects, and contribute to open source projects. In the [next chapter](how-to-contribute-to-open-source.md), we'll discuss how to contribute to open source projects, including finding projects to work on, submitting contributions, and what happens after your contribution is accepted. 133 | -------------------------------------------------------------------------------- /docs/intro-to-oss/types-of-contributions.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: types-of-contributions 3 | title: "Types of Open Source Contributions" 4 | sidebar_label: "Types of Contributions" 5 | keywords: ["types of contributions", "types of open source contributions", "open source contributions", "non-coding contributions", "types of non-coding contributions", "open source non-coding contributions", "types of coding contributions", "coding contributions", "open source coding contribution", "contributing to open source documentation", "graphic design contribution in open source", "content creation contribution in open source", "open source for beginners", "open source contribution for beginners", "Open Source", "Open Source Community"] 6 | --- 7 | 8 | Contributions to open source projects can take many forms, such as coding, documentation, testing, and more. It is important to note that open source contributions are not limited to developers only. Anyone can contribute to open source projects, regardless of their technical skills. 9 | 10 | In this chapter, we will discuss the non-coding and coding types of contributions in open source. 11 | 12 | ## Non-Coding Contributions 13 | 14 | Non-coding contributions are types of contributions that do not involve writing or modifying code. However, they are essential for the sustainability and growth of open source projects. 15 | 16 | These types of contributions allow individuals with various skills and backgrounds to participate and make meaningful contributions to the software and the community. You can read [this article](https://dev.to/opensauced/how-to-contribute-to-open-source-without-knowing-how-to-code-a-guide-with-project-suggestions-59e5) to learn more about contributing to open source projects without knowing how to code. 17 | 18 | Next, we will talk about some common non-coding contributions. 19 | 20 | ### Documentation 21 | 22 | Are you a lover of words? Do grammar errors irritate you? Do you like breaking down complex problems or helping people learn? Then, documentation is for you! 23 | 24 | Documentation is crucial to open source projects. It involves creating, improving, or maintaining the written resources accompanying open source software projects. Documentation can make a project more accessible and user-friendly, help attract new users, and encourage repeat contributions to the project. 25 | 26 | #### Tips for Contributing to Documentation 27 | 28 | If you are interested in contributing to documentation, here are a few tips that you might find helpful: 29 | 30 | - **Read the entire documentation**.
Reading the whole documentation will help you better understand the product and how to use it. 31 | 32 | - **Find a task that fits your skills and interests**.
If you're unsure where to start, look for issues or discussions you believe you can solve before reaching out to a maintainer. 33 | 34 | - **Use the product**.
Using the product yourself will help you gain user insight and help you determine which information needs to be added to or removed from the documentation. 35 | 36 | - **Be patient and persistent**.
Writing good documentation takes time. Don't be afraid to ask for help if you need it. 37 | 38 | #### Examples of Documentation Contributions 39 | 40 | Now, you might wonder what you should do to contribute to a project's documentation. Here are some examples of what to contribute: 41 | 42 | - **Write or update the README file**
If you see that a project needs a README explaining how to install and use it, you can offer to write one. Or, if you notice information or instructions are missing from the README, you can create an issue and suggest how to update it. 43 | 44 | - **Create a tutorial**
When the documentation about a feature is unavailable, you can address this and create a tutorial that guides users through the feature. 45 | 46 | - **Update documentation**
Sometimes, a project has new changes or releases, but the maintainers still need to update the documentation. You can help update the documentation to reflect these new changes. 47 | 48 | - **Translate documentation**
If you are proficient in other languages, you can help a project by translating the documentation to expand its reach to more users. 49 | 50 | - **Fix typos and grammatical errors**
Although they seem small, fixing typos and grammatical errors can help maintain consistency and clarify the documentation. 51 | 52 | ### Graphic Design 53 | 54 | Are you a creative person who's into design? If so, you might want to consider contributing to an open source project through design. 55 | 56 | This contribution involves creating visual assets for open source projects, such as logos, icons, illustrations, website designs, and other graphical elements. These visual assets play a significant role in enhancing the project's overall user experience and branding. Graphic design contributions can make open source software more appealing, user-friendly, and recognizable. 57 | 58 | Here are some examples of what to contribute through design: 59 | 60 | - **Logo and branding**
Designing a unique and memorable logo for an open source project can help establish its identity and brand. A well-designed logo can make the project recognizable and give it a professional image. 61 | 62 | - **Icon design**
Icons are essential for user interfaces. You can create custom icons for software applications or websites, improving the visual appeal and usability of the project. 63 | 64 | - **Website design**
Open source projects often have websites to provide information and documentation about the project. You can contribute by designing website layouts, graphics, banners, and other visual elements to make the site more attractive and user-friendly. 65 | 66 | - **User Interface (UI) design**
UI design is crucial for software projects. You can create mockups, wireframes, and high-fidelity designs for the user interface, making it more intuitive and visually appealing. 67 | 68 | - **User Experience (UX) design**
By considering how users interact with the software, you can contribute to improving the overall user experience. This includes designing user flows, navigation, and usability testing. 69 | 70 | - **Accessibility design**
Software and websites must be accessible to all users, regardless of whether they have disabilities. You can contribute, for example, by creating accessible color schemes and contrast or positioning visual elements within the project. You can help ensure all visual elements are clear and easy to use. 71 | 72 | - **Responsive design**
Designing visuals that work well on various devices and screen sizes is crucial for modern web applications. Responsive design ensures the project looks good and functions properly on desktop and mobile devices. 73 | 74 | ### Content Creation 75 | 76 | Contribution through content creation—blog posts, videos, or streaming—involves researching, writing or recording, editing, and publishing the content. The goal is to inform and educate others on a particular open source software, project, technology, or best practices to attract more users and contributors. Like documentation, you don't necessarily have to know how to code to create these contents. 77 | 78 | Here are some ideas about what to create: 79 | 80 | - **Latest features**
You can share the latest features of an open source project, such as a new version of the software or a new plugin. 81 | 82 | - **Tutorial**
Most of the time, documentation has limited space to explain the project in detail to accommodate all levels of users. You can take this opportunity to target particular audiences and create a tutorial on installing and configuring the software or using it. 83 | 84 | - **Impact**
You can consider sharing about an open source project's impact on its users. Why do they want to use it, or what are the benefits of using the software? That way, you are helping to promote the project to gain more users. 85 | 86 | - **Open source best practices**
Although many content creators have shared information about how to use Git and GitHub or how to contribute to open source, whenever you learn something new, you can always share it through your content. You never know if what you create can inspire and help others contribute to open source. 87 | 88 | ## Coding Contributions 89 | 90 | Coding contributions power open source development. They entail writing, modifying, or improving the actual source code of an open source project, directly impacting the software's functionality and quality. 91 | 92 | Contributors collaborate with project maintainers and the community to ensure their code contributions align with project goals and coding standards. Open source projects typically have guidelines and processes for accepting and integrating coding contributions, such as code reviews and continuous integration. 93 | 94 | Here are some examples of contributions you can make to a project with your coding skills: 95 | 96 | - **Write new code**
This is the most common type of coding contribution. You write new code to add features or enhance the functionality of an open source project. 97 | 98 | - **Bug fix**
Identifying and fixing bugs is a critical coding contribution. You locate issues within the codebase, diagnose them, and then write code to fix them. Bug fixes improve the software's stability and reliability. 99 | 100 | - **Code refactor**
Refactoring code involves restructuring and improving existing code without changing its behavior. This helps enhance code readability, maintainability, and scalability, which are vital for the project's long-term health. 101 | 102 | - **API design and maintenance**
You can contribute to projects with public APIs by designing, maintaining, or improving the API to ensure its quality and reliability. 103 | 104 | - **Feature development**
You can help implement new features or functionalities in response to user needs or project goals. Feature development involves planning, designing, and coding new components or capabilities. 105 | 106 | - **Performance optimization**
You can contribute to optimizing the software's performance by improving algorithms or optimizing resource usage. This type of contribution aims to make the software run more efficiently. 107 | 108 | - **Testing and Quality Assurance (QA)**
Writing automated tests, including unit tests, integration tests, and end-to-end tests, is a coding contribution that ensures software reliability. Testing helps catch and prevent regressions and issues. 109 | 110 | --- 111 | 112 | Congratulations on finishing this course! Let's recap what you have learned in the [next chapter](conclusion.md). 113 | -------------------------------------------------------------------------------- /docs/intro-to-oss/what-is-open-source.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: what-is-open-source 3 | title: "What is Open Source?" 4 | sidebar_label: "What is Open Source" 5 | keywords: ["what is open source", "open source definition", "open source licenses explained", "open source history", "open source evolution", "Open Source", "Open Source Community", "open source software", "history of open source"] 6 | --- 7 | 8 | In this chapter, we'll explore the history of open source and what that means. Before contributing to a project, you should understand what is open source and the principles behind it to help you appreciate the context in which you'll be collaborating and contributing. 9 | 10 | ## Definition 11 | 12 | Open source refers to a type of software whose source code is made available to the public, allowing anyone to view, use, modify, and distribute the code. This is in contrast to proprietary software, where the source code is kept secret and only the compiled program is distributed. The core principle behind open source is the idea of collaboration and the belief that sharing knowledge and resources leads to better, more reliable, and more innovative software. 13 | 14 | Open source software is built on the premise that when many people work together, they can create something greater than the sum of its parts. Contributors to open source projects come from diverse backgrounds, and they bring a wide range of skills, experiences, and perspectives to the table. This diversity of thought and expertise leads to more robust, innovative, and reliable software. 15 | 16 | ### Open Source Licenses 17 | 18 | For software to be considered open source, it must be released under a license that grants users the right to access, modify, and distribute the source code. There are numerous open source license types, each with its own set of terms and conditions. Some popular open source licenses include the MIT License, the GNU General Public License (GPL), and the Apache License. 19 | 20 | These open source licenses are crucial because they ensure that the software remains open and accessible to everyone. By granting users the right to view, modify, and distribute the code, open source licenses promote a culture of collaboration, innovation, and shared knowledge. 21 | 22 | ## Brief History of Open Source 23 | 24 | The history of open source dates back to the early days of computing when software was freely shared among researchers and developers. 25 | 26 | ### Early Beginnings 27 | 28 | In the 1950s and 1960s, computer software was often bundled with hardware, and source code was freely shared among researchers and developers. During this time, it was common for programmers to collaborate, share ideas, and modify each other's code to improve and innovate. 29 | 30 | However, in the 1970s and 1980s, as the software industry began to grow and commercialize, companies started to view software as a valuable asset and began to restrict access to source code. This shift marked the beginning of the divide between proprietary software and the emerging open source movement. 31 | 32 | ### The Birth of Free Software 33 | 34 | In response to the growing restrictions on software access and distribution, computer scientist Richard Stallman founded the Free Software Foundation (FSF) in 1985. The FSF's goal was to promote the development and use of free software, which they defined as software that grants users the freedom to run, study, share, and modify the code. This concept is similar to open source but places a greater emphasis on the ethical and political aspects of software freedom. 35 | 36 | Stallman and the FSF went on to develop the GNU Project (which stands for "GNU's Not Unix"), an ambitious effort to create a completely free and open operating system. While the GNU Project provided many essential components, it was missing a critical piece: a free and open kernel, the core component of an operating system. 37 | 38 | ### The Arrival of Linux 39 | 40 | In 1991, a Finnish computer science student named Linus Torvalds developed a free and open source kernel called Linux. When combined with the GNU system, Linux formed a complete, free, and open source operating system that is still widely used today. The success of Linux helped to popularize the concept of open source and sparked a wave of new projects, tools, and technologies. 41 | 42 | ### The Open Source Initiative 43 | 44 | In 1998, Christine Peterson, an Executive Director at Foresight coined the term "open source software" as a [deliberate effort to make this field...more understandable to newcomers and to business[es]](https://opensource.com/article/18/2/coining-term-open-source-software). She, alongside Eric S. Raymond, Bruce Perens, and other developers and advocates then created The Open Source Initiative (OSI) to spread more awareness about this concept. From there, the OSI developed the definition of open source, a set of criteria that software must meet to be considered open source. These criteria include free distribution, source code availability, derived works, and license integrity. 45 | 46 | The OSI's efforts to promote open source led to a surge of interest and adoption by both individuals and organizations. Today, open source software is widely used across various industries, and many well-known technology companies, such as Google, IBM, and Microsoft, actively support and contribute to open source projects. 47 | 48 | ### The Growth of Open Source Communities 49 | 50 | As the open source movement gained momentum, numerous communities and platforms emerged to facilitate collaboration and knowledge sharing. Some notable examples include: 51 | 52 | - **SourceForge**: Launched in 1999, SourceForge was one of the first web-based platforms to provide tools and resources for developers to collaborate on open source projects. At its peak, SourceForge hosted thousands of projects and attracted millions of users. 53 | - **GitHub**: Founded in 2008, GitHub quickly became the go-to platform for hosting and collaborating on Git repositories. Today, GitHub is home to millions of open source projects and boasts a vibrant community of contributors from around the world. 54 | - **GitLab**: Launched in 2011 as an open source alternative to GitHub, GitLab offers a suite of tools and features for managing Git repositories, tracking issues, and facilitating collaboration. 55 | 56 | These platforms have played a crucial role in fostering the growth of open source communities and making it easier for developers to contribute to and collaborate on projects. 57 | 58 | ### The Rise of Corporate Involvement 59 | 60 | In recent years, there has been a significant increase in corporate involvement in open source projects. Many companies now recognize the value of open source and actively contribute to and support various projects. Some companies have even gone so far as to open source their own internal tools and technologies, such as [Google's TensorFlow](https://app.opensauced.pizza/s/tensorflow/tensorflow) and [Facebook's React](https://app.opensauced.pizza/s/facebook/react). 61 | 62 | This increased corporate involvement has not only led to more resources and support for open source projects but has also helped to legitimize the open source movement and encourage wider adoption. 63 | 64 | ## The Evolution of Open Source 65 | 66 | The open source movement has come a long way since its early beginnings. Today, open source software is everywhere, powering everything from websites and mobile apps to artificial intelligence and machine learning algorithms. 67 | 68 | As open source continues to evolve, new projects, tools, and technologies are constantly emerging, pushing the boundaries of what's possible and driving innovation across a wide range of industries. 69 | 70 | The growing popularity of open source has also led to a thriving ecosystem of conferences, meetups, and online communities where developers can come together to learn, collaborate, and share their knowledge. By participating in these events and engaging with the open source community, you'll have the opportunity to expand your skills, build your network, and stay up-to-date with the latest developments in the field. 71 | 72 | The history of open source software shows us how collective efforts can produce reliable, innovative, and widely adopted technologies. 73 | 74 | In the [next chapter](why-open-source.md), we'll explore the many benefits of contributing to open source projects and discuss how open source collaboration can help you access knowledge, connect with a community, and develop valuable skills. 75 | -------------------------------------------------------------------------------- /docs/intro-to-oss/why-open-source.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: why-open-source 3 | title: "Why Open Source?" 4 | sidebar_label: "Why Open Source" 5 | keywords: ["why open source", "why contribute to open source", "open source project contribution benefits", "Open Source", "Advantages of open source software"] 6 | --- 7 | 8 | In the previous chapter, we explored the concept of open source and its history. Now, let's look at the many benefits of open source software contributions. By understanding the advantages of open source collaboration, you'll be better equipped to leverage the opportunities it presents and make the most of your open source journey. 9 | 10 | ## Access to Knowledge 11 | 12 | One of the key benefits of open source contributions is to access a wealth of knowledge and resources. As an open source contributor, you'll be able to: 13 | 14 | 1. **Learn from real-world projects**: Open source projects provide a unique opportunity to study and learn from real-world codebases. By examining how other developers have tackled complex problems, you can gain insights into best practices, design patterns, and cutting-edge techniques that you can apply to your own projects. 15 | 16 | 2. **Access diverse perspectives**: Open source projects attract contributors from all around the world, each bringing their own unique set of skills, experiences, and perspectives. By collaborating with others, you can broaden your understanding of different technologies, programming languages, and development methodologies. 17 | 18 | 3. **Stay up-to-date with the latest trends**: The open source community is often at the forefront of innovation, with new projects, tools, and technologies constantly emerging. By participating in open source projects, you can stay up-to-date with the latest developments in your field and learn about emerging trends and best practices. 19 | 20 | 4. **Access high-quality resources**: The open source community is known for its commitment to producing high-quality documentation, tutorials, and other educational resources. By tapping into this wealth of knowledge, you can deepen your understanding of various technologies and concepts, and continue to grow as a developer. 21 | 22 | ## Access to the Open Source Community 23 | 24 | The open source community is a diverse, global network of developers, enthusiasts, and advocates who share a common passion for collaboration and knowledge sharing. By contributing to open source projects, you can: 25 | 26 | 1. **Connect with like-minded individuals**: Open source projects provide an opportunity to collaborate with others who share your interests and passions. By working together, you can form lasting connections and friendships that can enrich your personal and professional life. 27 | 28 | 2. **Expand your network**: The open source community is vast and interconnected, with countless projects, events, and forums where developers come together to collaborate and share knowledge. By participating in these activities, you can expand your professional network and connect with potential mentors, collaborators, and even employers. 29 | 30 | 3. **Develop communication and collaboration skills**: Working on open source projects often involves collaborating with others, either remotely or in person. This can help you develop essential communication and collaboration skills, such as providing constructive feedback, resolving conflicts, and working effectively in a team. 31 | 32 | 4. **Give back to the community**: Contributing to open source projects is a way to give back to the community that has provided you with valuable knowledge and resources. By sharing your skills and expertise, you can help support the continued growth and success of the open source movement. 33 | 34 | ## Access to Skills 35 | 36 | Contributing to open source projects can help you develop a wide range of technical and non-technical skills that are highly valued in the job market. As an open source contributor, you'll have the opportunity to: 37 | 38 | 1. **Improve your programming skills**: Working on real-world projects is an excellent way to improve your programming skills and deepen your understanding of various technologies and languages. By tackling challenging problems and learning from other contributors, you can refine your abilities and become a more proficient developer. 39 | 40 | 2. **Gain experience with new technologies**: Open source projects often involve cutting-edge technologies and tools that may not be used in your day-to-day work or studies. By contributing to these projects, you can gain hands-on experience with new technologies and broaden your skillset. 41 | 42 | 3. **Build your portfolio**: Contributing to open source projects allows you to create a public record of your work, showcasing your skills and expertise to potential employers. A strong portfolio of open source contributions can help you stand out in the job market and demonstrate your commitment to continuous learning and professional growth. 43 | 44 | 4. **Develop problem-solving and critical thinking skills**: Working on open source projects often involves tackling complex problems and making important decisions. By navigating these challenges, you can develop valuable problem-solving and critical thinking skills that can be applied to various aspects of your life and career. 45 | 46 | 5. **Learn project management and organization**: Contributing to open source projects can expose you to various aspects of project management and organization, such as setting priorities, managing deadlines, and coordinating with team members. These skills can be invaluable in both your personal and professional life, helping you become a more effective and organized individual. 47 | 48 | 6. **Develop leadership and mentorship skills**: As you gain experience in the open source community, you may find yourself in a position to mentor and guide new contributors. By taking on these leadership roles, you can develop essential skills, such as communication, empathy, and delegation, that can help you succeed in your career and personal life. 49 | 50 | ## Additional Advantages of Open Source Contributions 51 | 52 | In addition to the above-mentioned benefits of open source software, contributing to open source projects can also provide several other advantages, such as: 53 | 54 | 1. **Increased job opportunities**: Many employers value open source experience and actively seek out candidates who have a proven track record of contributing to open source projects. By showcasing your open source contributions, you can increase your chances of landing your dream job or advancing your career. 55 | 56 | 2. **Professional development**: Open source contributions can be a great way to enhance your professional development, to understand the advantages of open source software, and demonstrate your commitment to continuous learning and growth. By engaging with the open source community, you can stay current with the latest trends and technologies, expand your skillset, and build your reputation as a knowledgeable and skilled developer. 57 | 58 | 3. **Personal fulfillment**: Contributing to open source projects can be a rewarding and fulfilling experience, both personally and professionally. By sharing your skills and knowledge, you can make a tangible difference in the world and contribute to something greater than yourself. 59 | 60 | 4. **Opportunities for recognition**: Open source projects often attract the attention of industry leaders, influencers, and media outlets. By making significant contributions to high-profile projects, you can gain recognition and establish yourself as an expert in your field. 61 | 62 | In the [next chapter](tools-to-be-successful.md), we'll discuss the essential tools and resources you'll need to be successful in your open source journey, including GitHub, Git, VS Code, and Discord. By familiarizing yourself with these tools, you'll be better equipped to collaborate with others, manage your projects, and contribute effectively to open source projects. 63 | -------------------------------------------------------------------------------- /docusaurus.config.js: -------------------------------------------------------------------------------- 1 | 2 | // @ts-check 3 | // `@type` JSDoc annotations allow editor autocompletion and type checking 4 | // (when paired with `@ts-check`). 5 | // There are various equivalent ways to declare your Docusaurus config. 6 | // See: https://docusaurus.io/docs/api/docusaurus-config 7 | 8 | import {themes as prismThemes} from 'prism-react-renderer'; 9 | 10 | /** @type {import('@docusaurus/types').Config} */ 11 | const config = { 12 | title: 'Open Source Education with OpenSauced', 13 | tagline: 'Empowering Your Open Source Journey: From First Contribution to Project Leadership', 14 | favicon: 'img/favicon.ico', 15 | 16 | // Set the production url of your site here 17 | url: 'https://opensauced.pizza', 18 | // Set the // pathname under which your site is served 19 | // For GitHub pages deployment, it is often '//' 20 | baseUrl: '/learn/', 21 | 22 | // GitHub pages deployment config. 23 | // If you aren't using GitHub pages, you don't need these. 24 | organizationName: 'OpenSauced', // Usually your GitHub org/user name. 25 | projectName: 'open source learning path', // Usually your repo name. 26 | 27 | onBrokenLinks: 'throw', 28 | onBrokenMarkdownLinks: 'warn', 29 | 30 | // Even if you don't use internationalization, you can use this field to set 31 | // useful metadata like html lang. For example, if your site is Chinese, you 32 | // may want to replace "en" with "zh-Hans". 33 | i18n: { 34 | defaultLocale: 'en', 35 | locales: ['en'], 36 | }, 37 | 38 | presets: [ 39 | [ 40 | 'classic', 41 | /** @type {import('@docusaurus/preset-classic').Options} */ 42 | ({ 43 | docs: { 44 | sidebarPath: './sidebars.js', 45 | // Dynamic editUrl construction 46 | editUrl: ({ versionDocsDirPath, docPath }) => 47 | `https://github.com/open-sauced/intro/edit/main/${versionDocsDirPath}/${docPath}`, 48 | routeBasePath: '/', 49 | }, 50 | theme: { 51 | customCss: './src/css/custom.css', 52 | }, 53 | }), 54 | ], 55 | ], 56 | 57 | themeConfig: 58 | /** @type {import('@docusaurus/preset-classic').ThemeConfig} */ 59 | ({ 60 | // Replace with your project's social card 61 | image: 'img/docusaurus-social-card.jpg', 62 | navbar: { 63 | title: 'Open Source Education Path', 64 | logo: { 65 | alt: 'My Site Logo', 66 | src: '/img/favicon.ico', 67 | }, 68 | items: [ 69 | { 70 | type: 'docSidebar', 71 | sidebarId: 'introToOSS', 72 | position: 'left', 73 | label: 'Intro to Open Source', 74 | }, 75 | { 76 | type: 'docSidebar', 77 | sidebarId: 'becomingAMaintainer', 78 | position: 'left', 79 | label: 'Becoming a Maintainer', 80 | }, 81 | {href: 'https://opensauced.pizza/docs/community-resources', label: 'Blog', position: 'left'}, 82 | { 83 | href: 'https://github.com/open-sauced/intro', 84 | label: 'GitHub', 85 | position: 'right', 86 | }, 87 | ], 88 | }, 89 | footer: { 90 | logo: { 91 | alt: "OpenSauced Logo", 92 | src: "img/logo_lightmode.png", 93 | href: "https://opensauced.pizza/", 94 | height: 40, 95 | }, 96 | style: "light", 97 | links: [ 98 | { 99 | title: "Learn", 100 | items: [ 101 | { 102 | label: "Contributing guide", 103 | to: "https://github.com/open-sauced/intro/blob/main/contributing/CONTRIBUTING.md", 104 | }, 105 | { 106 | label: "Open Source Courses", 107 | to: "https://intro.opensauced.pizza/#/", 108 | }, 109 | ], 110 | }, 111 | { 112 | title: "Community", 113 | items: [ 114 | { 115 | label: "GitHub", 116 | href: "https://github.com/orgs/open-sauced/discussions", 117 | }, 118 | { 119 | label: "X", 120 | href: "https://x.com/saucedopen", 121 | }, 122 | ], 123 | }, 124 | { 125 | title: "More", 126 | items: [ 127 | { 128 | label: "Blog", 129 | href: "https://opensauced.pizza/docs/community-resources", 130 | }, 131 | { 132 | label: "Watch our feature demos", 133 | href: "https://www.youtube.com/playlist?list=PLHyZ0Wz_A44VRlE-YS9me5qxDNRgK5T3H" 134 | } 135 | 136 | ], 137 | }, 138 | ], 139 | copyright: `Copyright © ${new Date().getFullYear()} My Project, Inc. Built with Docusaurus.`, 140 | }, 141 | prism: { 142 | theme: prismThemes.github, 143 | darkTheme: prismThemes.dracula, 144 | }, 145 | }), 146 | }; 147 | 148 | export default config; 149 | -------------------------------------------------------------------------------- /netlify.toml: -------------------------------------------------------------------------------- 1 | [build] 2 | publish = "build" 3 | command = "npm run build" 4 | 5 | [build.environment] 6 | NODE_VERSION = "18.0" -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "@open-sauced/intro.opensauced.pizza", 3 | "version": "0.0.0", 4 | "private": true, 5 | "scripts": { 6 | "docusaurus": "docusaurus", 7 | "start": "docusaurus start", 8 | "build": "docusaurus build", 9 | "swizzle": "docusaurus swizzle", 10 | "deploy": "docusaurus deploy", 11 | "clear": "docusaurus clear", 12 | "serve": "docusaurus serve", 13 | "write-translations": "docusaurus write-translations", 14 | "write-heading-ids": "docusaurus write-heading-ids" 15 | }, 16 | "dependencies": { 17 | "@docusaurus/core": "3.4.0", 18 | "@docusaurus/plugin-content-docs": "^3.4.0", 19 | "@docusaurus/preset-classic": "3.4.0", 20 | "@mdx-js/react": "^3.0.0", 21 | "clsx": "^2.0.0", 22 | "fs": "^0.0.1-security", 23 | "path": "^0.12.7", 24 | "prism-react-renderer": "^2.3.0", 25 | "react": "^18.0.0", 26 | "react-dom": "^18.0.0" 27 | }, 28 | "devDependencies": { 29 | "@docusaurus/module-type-aliases": "3.4.0", 30 | "@docusaurus/types": "3.4.0" 31 | }, 32 | "browserslist": { 33 | "production": [ 34 | ">0.5%", 35 | "not dead", 36 | "not op_mini all" 37 | ], 38 | "development": [ 39 | "last 3 chrome version", 40 | "last 3 firefox version", 41 | "last 5 safari version" 42 | ] 43 | }, 44 | "engines": { 45 | "node": ">=18.0" 46 | } 47 | } 48 | -------------------------------------------------------------------------------- /sidebars.js: -------------------------------------------------------------------------------- 1 | // @ts-check 2 | 3 | /** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */ 4 | const sidebars = { 5 | // Manually create sidebars for each course 6 | 7 | introToOSS: [ 8 | { 9 | type: 'category', 10 | label: 'Intro to Open Source', 11 | items: [ 12 | 'intro-to-oss/Contributor-README', 13 | 'intro-to-oss/what-is-open-source', 14 | 'intro-to-oss/why-open-source', 15 | 'intro-to-oss/tools-to-be-successful', 16 | 'intro-to-oss/how-to-contribute-to-open-source', 17 | 'intro-to-oss/the-secret-sauce', 18 | 'intro-to-oss/types-of-contributions', 19 | 'intro-to-oss/conclusion', 20 | 'intro-to-oss/additional-resources', 21 | 'intro-to-oss/glossary', 22 | ], 23 | }, 24 | ], 25 | 26 | becomingAMaintainer: [ 27 | { 28 | type: 'category', 29 | label: 'Becoming a Maintainer', 30 | items: [ 31 | 'becoming-a-maintainer/Maintainer-README', 32 | 'becoming-a-maintainer/intro', 33 | 'becoming-a-maintainer/how-to-setup-your-project', 34 | 'becoming-a-maintainer/issues-and-pull-requests', 35 | 'becoming-a-maintainer/communication-and-collaboration', 36 | 'becoming-a-maintainer/maintaining-code-quality', 37 | 'becoming-a-maintainer/building-community', 38 | 'becoming-a-maintainer/maintainer-powerups', 39 | 'becoming-a-maintainer/your-team', 40 | 'becoming-a-maintainer/metrics-and-analytics', 41 | 'becoming-a-maintainer/getting-practical', 42 | 'becoming-a-maintainer/maintainers-guestbook', 43 | 'becoming-a-maintainer/additional-resources', 44 | 'becoming-a-maintainer/glossary', 45 | ], 46 | }, 47 | ], 48 | }; 49 | 50 | export default sidebars; -------------------------------------------------------------------------------- /src/components/index.js: -------------------------------------------------------------------------------- 1 | import clsx from 'clsx'; 2 | import Heading from '@theme/Heading'; 3 | import styles from './styles.module.css'; 4 | 5 | const FeatureList = [ 6 | { 7 | title: 'Easy to Use', 8 | Svg: require('@site/static/img/undraw_docusaurus_mountain.svg').default, 9 | description: ( 10 | <> 11 | Docusaurus was designed from the ground up to be easily installed and 12 | used to get your website up and running quickly. 13 | 14 | ), 15 | }, 16 | { 17 | title: 'Focus on What Matters', 18 | Svg: require('@site/static/img/undraw_docusaurus_tree.svg').default, 19 | description: ( 20 | <> 21 | Docusaurus lets you focus on your docs, and we'll do the chores. Go 22 | ahead and move your docs into the docs directory. 23 | 24 | ), 25 | }, 26 | { 27 | title: 'Powered by React', 28 | Svg: require('@site/static/img/undraw_docusaurus_react.svg').default, 29 | description: ( 30 | <> 31 | Extend or customize your website layout by reusing React. Docusaurus can 32 | be extended while reusing the same header and footer. 33 | 34 | ), 35 | }, 36 | ]; 37 | 38 | function Feature({Svg, title, description}) { 39 | return ( 40 |
41 |
42 | 43 |
44 |
45 | {title} 46 |

{description}

47 |
48 |
49 | ); 50 | } 51 | 52 | export default function HomepageFeatures() { 53 | return ( 54 |
55 |
56 |
57 | {FeatureList.map((props, idx) => ( 58 | 59 | ))} 60 |
61 |
62 |
63 | ); 64 | } 65 | -------------------------------------------------------------------------------- /src/components/styles.module.css: -------------------------------------------------------------------------------- 1 | .features { 2 | display: flex; 3 | align-items: center; 4 | padding: 2rem 0; 5 | width: 100%; 6 | } 7 | 8 | .featureSvg { 9 | height: 200px; 10 | width: 200px; 11 | } 12 | -------------------------------------------------------------------------------- /src/css/custom.css: -------------------------------------------------------------------------------- 1 | /* stylelint-disable docusaurus/copyright-header */ 2 | /** 3 | * Any CSS included here will be global. The classic template 4 | * bundles Infima by default. Infima is a CSS framework designed to 5 | * work well for content-centric websites. 6 | */ 7 | 8 | /* You can override the default Infima variables here. */ 9 | :root { 10 | --ifm-color-primary: #2e8555; 11 | --ifm-color-primary-dark: #29784c; 12 | --ifm-color-primary-darker: #277148; 13 | --ifm-color-primary-darkest: #205d3b; 14 | --ifm-color-primary-light: #33925d; 15 | --ifm-color-primary-lighter: #359962; 16 | --ifm-color-primary-lightest: #3cad6e; 17 | } 18 | html[data-theme='dark'] { 19 | --ifm-color-primary: #25c2a0; 20 | --ifm-color-primary-dark: #21af90; 21 | --ifm-color-primary-darker: #1fa588; 22 | --ifm-color-primary-darkest: #1a8870; 23 | --ifm-color-primary-light: #29d5b0; 24 | --ifm-color-primary-lighter: #32d8b4; 25 | --ifm-color-primary-lightest: #4fddbf; 26 | } 27 | 28 | .docusaurus-highlight-code-line { 29 | background-color: rgba(0, 0, 0, 0.1); 30 | display: block; 31 | margin: 0 calc(-1 * var(--ifm-pre-padding)); 32 | padding: 0 var(--ifm-pre-padding); 33 | } 34 | 35 | html[data-theme='dark'] .docusaurus-highlight-code-line { 36 | background-color: rgba(0, 0, 0, 0.3); 37 | } 38 | 39 | .footer__title { 40 | position: relative; 41 | } 42 | 43 | .footer__col > .footer__title::after { 44 | content: ''; 45 | display: inline-block; 46 | width: 28px; 47 | height: 23px; 48 | background-position: center; 49 | background-size: contain; 50 | position: absolute; 51 | background-repeat: no-repeat; 52 | } -------------------------------------------------------------------------------- /src/pages/index.js: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import Layout from '@theme/Layout'; 3 | import Link from '@docusaurus/Link'; 4 | import useDocusaurusContext from '@docusaurus/useDocusaurusContext'; 5 | import clsx from 'clsx'; 6 | import styles from './index.module.css'; 7 | 8 | function HomepageHeader() { 9 | const {siteConfig} = useDocusaurusContext(); 10 | return ( 11 |
12 |
13 |

Open Source Education with OpenSauced

14 |

Empowering Your Open Source Journey: From First Contribution to Project Leadership

15 |
16 |
17 | ); 18 | } 19 | 20 | export default function Home() { 21 | return ( 22 | 23 | 24 |
25 |
26 |
27 |
28 |
29 |

Intro to Open Source Course

30 |

This course is designed to equip you with the skills and knowledge you need to contribute to open source projects. It offers engaging exercises to help you begin your journey towards becoming a successful contributor, and even provides an opportunity to get your first pull request merged.

31 | 32 | Start the Intro to Open Source Course 33 | 34 |
35 |
36 |
37 |
38 |

Becoming a Maintainer

39 |

This course is designed to aid people who are interested in becoming open source project maintainers. It guides you through maintainers' best practices and provides resources and tools that help maintainers perform their tasks. This course is equipped with a tutorial for you to get practical.

40 | 41 | Start the Becoming a Maintainer Course 42 | 43 |
44 |
45 |
46 |
47 |
48 | 49 | ); 50 | } -------------------------------------------------------------------------------- /src/pages/index.module.css: -------------------------------------------------------------------------------- 1 | .heroBanner { 2 | background: #000; /* Black background */ 3 | color: #fff; 4 | padding: 4rem 1rem; /* Adjusted for smaller screens */ 5 | text-align: center; 6 | display: flex; 7 | justify-content: center; 8 | align-items: center; 9 | min-height: 20vh; /* Ensure there's enough space for the content */ 10 | flex-direction: column; /* Ensure column layout on smaller screens */ 11 | } 12 | 13 | .heroContent { 14 | position: relative; 15 | z-index: 1; 16 | padding: 0 2rem; /* Add padding to ensure content doesn't touch the edges */ 17 | } 18 | 19 | .heroTitleOS { 20 | font-size: clamp(2rem, 5vw, 4rem); 21 | font-weight: bold; 22 | margin-bottom: 0.5rem; 23 | background: linear-gradient(to right, #e74c3c, #e67e22); 24 | -webkit-background-clip: text; 25 | -webkit-text-fill-color: transparent; 26 | } 27 | 28 | .heroTitle { 29 | font-size: clamp(2rem, 5vw, 4rem); 30 | font-weight: bold; 31 | margin-bottom: 0.5rem; 32 | } 33 | 34 | .heroSubtitle { 35 | font-size: clamp(1rem, 2.5vw, 1.5rem); 36 | color: #fff; 37 | } 38 | 39 | .main { 40 | padding: 2rem 1rem; 41 | display: flex; 42 | justify-content: center; 43 | align-items: center; 44 | flex-direction: column; /* Ensure column layout on smaller screens */ 45 | flex: 1 0 auto; 46 | } 47 | 48 | .cards { 49 | display: grid; 50 | grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)); 51 | gap: 2rem; 52 | max-width: 1200px; /* Limit the width of the card container */ 53 | width: 100%; 54 | } 55 | 56 | .card { 57 | background: #fff; 58 | border: 1px solid #ddd; 59 | border-radius: 8px; 60 | box-shadow: 0 2px 5px rgba(0, 0, 0, 0.1); 61 | padding: 2rem; 62 | text-align: left; 63 | transition: transform 0.3s, box-shadow 0.3s; 64 | font-size: 18px; 65 | } 66 | 67 | .card:hover { 68 | transform: translateY(-5px); 69 | box-shadow: 0 4px 10px rgba(0, 0, 0, 0.15); 70 | } 71 | 72 | .cardContent { 73 | display: flex; 74 | flex-direction: column; 75 | align-items: flex-start; 76 | height: 100%; /* card content takes the full height */ 77 | } 78 | 79 | .cardIcon { 80 | width: 40px; 81 | height: 40px; 82 | margin-bottom: 1rem; 83 | } 84 | 85 | .card h3 { 86 | color: #000b05; 87 | margin-bottom: 1rem; 88 | } 89 | 90 | .card p { 91 | color: #333; 92 | margin-bottom: 1rem; 93 | } 94 | 95 | .cardLink { 96 | margin-top: auto; /* Push the button to the bottom */ 97 | background: linear-gradient(to right, #e74c3c, #e67e22); 98 | border-radius: 50px; 99 | color: #fff; 100 | padding: 0.5rem 1rem; 101 | text-decoration: none; 102 | transition: background 0.3s; 103 | text-align: center; 104 | display: inline-block; 105 | } 106 | 107 | .cardLink:hover { 108 | background: #e74c3c; /* Use the darkest color in the gradient */ 109 | color: #fff; /* Keep the text white */ 110 | } -------------------------------------------------------------------------------- /static/img/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/static/img/favicon.ico -------------------------------------------------------------------------------- /static/img/logo_darkmode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/static/img/logo_darkmode.png -------------------------------------------------------------------------------- /static/img/logo_lightmode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Virtual-Coffee/intro/b825258481030ff87a345f8e4d588c39cb3df86c/static/img/logo_lightmode.png --------------------------------------------------------------------------------