Now that you've gone through the course and understand what it takes to be a successful maintainer, let's get practical and start your first open source project as a maintainer!
You'll need to have the following:
Sometimes, the hardest part is deciding what you will work on. Here are some general ideas to get you started:
- Identify a problem or need in the open source community.
- Think about a topic you're passionate about that others might be interested in.
- Think about a problem you've had to solve that others can benefit from.
Don't think too hard about it now. You can always go back and update things later. For now, if you need a place to start, let's create a repository about your favorite open source resources.
We will walk through the steps to set up your project in GitHub. Although it's not the only way to get started with a project, it's the one we'll use in this demonstration.
- Go to GitHub and sign in.
- Click on the "+" icon in the upper right corner and select "New repository."
- Enter a repository name and description, and choose whether the repository should be public or private.
- Initialize the repository with a README file and add a license.
- Click the "Create repository" button.
If you're using our starter idea, you could use the following:
- Name: favorite-open-source-resources
- Description: A markdown file of resources I've found most helpful.
Now that you have the repository, you can either edit it directly in GitHub or clone the project and work on it locally. We previously learned about how to create detailed READMEs, contributing guides, and codes of conduct in "How to Setup Your Open Source Project". If you need a reminder, take a look back at that chapter.
Your project already has a README file, but it's a good idea to update it with information about your project. Here's a template you can use:
# Project Name
## Overview
Provide a brief, high-level overview of your project. Include the goals and core values of the project. Explain how it contributes to the open source community and any specific problems it aims to solve.
## Table of Contents
- [Overview](#overview)
- [Getting Started](#getting-started)
- [Installation](#installation)
- [Usage](#usage)
- [Contributing to the Project](#contributing-to-the-project)
- [Acknowledgments](#acknowledgments)
- [License](#license)
## Getting Started
### Installation
Instructions on how to install the project. Include any prerequisites or dependencies.
### Usage
Guide on how to use the project, including any configuration steps or basic examples.
## Contributing to the Project
General instructions on how to submit contributions to the project with a link to your CONTRIBUTING.md file. Also, include information on how to engage with the community and maintainers.
## Acknowledgments
Show appreciation for the community's contributions, including developers, writers, and any other contributors.
## License
State the license under which the project is released and provide a link to the full license text.You should have initialized your project with a license, but if you did not, you can add a license to your project by creating a new file named LICENSE in the root of your repository. You can use the Choose a License website to help you select the right license for your project.
Your project will likely have similar contribution guidelines to other projects. You can follow these steps to create guidelines and provide a template. However, if you need a specific example, you can always refer to the OpenSauced Contributing Guidelines. Feel free to use those guidelines and update them as you see fit for your project.
- Create a new file named
CONTRIBUTING.mdin the root of your repository. - Outline the process for submitting issues and pull requests.
- Include coding standards, style guides, or any specific requirements.
- Mention how contributors can ask for help or clarification.
# Contributing to [Project Name]
Welcome to [Project Name]! We're thrilled you're considering contributing to our project. Every contribution, whether it's code, bug reports, feature requests, documentation, or community engagement, plays a significant role in its success.
## How to Contribute
We value all forms of contributions, not just code. Here's how you can contribute:
- **Code Contributions**: Check our issues labeled `good first issue` or `help wanted`.
- **Documentation**: Improvements to documentation, tutorials, or guides.
- **Community**: Participating in discussions, helping others, and sharing your experiences with the project.
## Getting Started
1. **Setting Up**: Here's how you can set up [Project Name] for development...
2. **Making Changes**: A guide to making changes and testing them.
3. **Submitting Contributions**: Steps to submit your contributions via Pull Requests.
## Community and Communication
- **Code of Conduct**: We have a Code of Conduct that all contributors are expected to adhere to.
- **Where to Ask Questions**: Join our Slack/Discord or post questions in our forums.
## Review Process
After you submit your contribution, here's what happens next...
## Recognition
We believe in recognizing all contributions, not just code. Here's how we do it...
## Additional Resources
- **FAQs**
- **Learning Resources**
Thank you for contributing to [Project Name]!It's essential to have a code of conduct to ensure that everyone feels welcome and safe in your project. Here's how to set up a code of conduct:
- Create a new file named
CONTRIBUTING.mdin the root of your repository. - Copy and paste the code of conduct you'd like to use. We recommend using the Contributor Covenant.
- Add a link to the code of conduct in your README and CONTRIBUTING files.
!> Make sure you attribute the code of conduct to the original author.
Creating good issues and using labels will help to create a strong project. Before creating your first issue, start by creating issue templates to make the process of submitting an issue clear to your contributors.
In this section, we will create an issue template for a bug report. You can also create templates for other types of issues, such as feature requests, questions, or documentation requests.
Below are the steps to create the template. After the steps, we'll share with you what we use at OpenSauced. Feel free to copy and paste that information into your repository and update it as needed.
- Create a new folder named
.githubin the root of your repository. - Within that folder, create a new folder named
ISSUE_TEMPLATE. - In the
.github/ISSUE_TEMPLATEdirectory, create a new file namedbug_report.yml. - Add a name (🐛 Bug report), description (Create a bug report to help us improve Open Sauced 🍕) to the template, and title ("Bug: ").
- If there are specific labels you want automatically generated when this issue is created, add them to the template. (
labels: [👀 needs triage, 🐛 bug]) - Next, you'll add the body, which includes the type and attributes for each section. This generally contains a checklist of steps to reproduce the bug. As part of that section, you should:
- Add a section for the expected behavior and actual behavior.
- Add a checklist of steps to reproduce the bug.
- Add a section for screenshots, if applicable.
- Add a section for additional context, if applicable.
- Finally, add a section for the code of conduct and contributing docs.
Here's what we use at OpenSauced:
name: 🐛 Bug report
description: Create a bug report to help us improve Open Sauced 🍕
title: "Bug: "
labels: [👀 needs triage, 🐛 bug]
body:
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out this bug report!
- type: textarea
attributes:
label: Describe the bug
description: A clear and concise description of what the bug is.
validations:
required: true
- type: textarea
attributes:
label: Steps to reproduce
description: Describe how to reproduce the behavior.
placeholder: |
1. Go to '...'
2. Click on '...'
3. Scroll down to '...'
4. See error
validations:
required: true
- type: dropdown
attributes:
multiple: true
label: Browsers
description: Select the browsers where the issue can be reproduced (that you know of).
options:
- "Chrome"
- "Firefox"
- "Safari"
- "Edge"
- "Opera"
- "Other (add additional context)"
- type: input
id: context
attributes:
label: Additional context (Is this in dev or production?)
description: Add any other context about the problem or helpful links here.
- type: checkboxes
id: terms
attributes:
label: Code of Conduct
description: By submitting this issue, you agree to follow our [Code of Conduct](https://docs.opensauced.pizza/contributing/code-of-conduct/)
options:
- label: I agree to follow this project's Code of Conduct
required: true
- type: checkboxes
id: contribution
attributes:
label: Contributing Docs
description: If you plan on contributing code please read - [Contribution Guide](https://docs.opensauced.pizza/contributing/introduction-to-contributing/)
options:
- label: I agree to follow this project's Contribution Docs
required: falseNow, let's follow the same process and make a feature request template.
- In the
.github/ISSUE_TEMPLATEdirectory, create a new file namedfeature_request.yml. - Add a name (🚀 Feature request), description (Suggest an idea for this project 💡), and title ("Feature: ") to the template.
- If there are specific labels you want automatically generated when this issue is created, add them to the template. We use 👀 needs triage, 💡 feature.
- Next, you'll add the body, which includes the type and attributes for each section. This generally contains a checklist of steps to reproduce the bug. As part of that section, you should:
- Add a section for the expected behavior and actual behavior.
- Add a dropdown for the type of feature request.
- Add a section for the suggested solution.
- Add a section for screenshots, if applicable.
- Add a section for additional context, if applicable.
- Finally, add a section for the code of conduct and contributing docs.
Here's what we use at OpenSauced:
name: 🚀 Feature request
description: Suggest an idea for this project 💡
title: "Feature: "
labels: [👀 needs triage, 💡 feature]
body:
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out this feature request!
- type: dropdown
attributes:
multiple: false
label: Type of feature
description: Select the type of feature request, the lowercase should also be the PR prefix.
options:
- "🍕 Feature"
- "🐛 Fix"
- "📝 Documentation"
- "🎨 Style"
- "🧑💻 Refactor"
- "🔥 Performance"
- "✅ Test"
- "🤖 Build"
- "🔁 CI"
- "📦 Chore"
- "⏩ Revert"
validations:
required: true
- type: textarea
attributes:
label: Current behavior
description: Is your feature request related to a problem? Please describe.
validations:
required: true
- type: textarea
attributes:
label: Suggested solution
description: Describe the solution you'd like.
- type: input
id: context
attributes:
label: Additional context
description: Add any other context about the problem or helpful links here.
- type: checkboxes
id: terms
attributes:
label: Code of Conduct
description: By submitting this issue, you agree to follow our [Code of Conduct](https://docs.opensauced.pizza/contributing/code-of-conduct/)
options:
- label: I agree to follow this project's Code of Conduct
required: true
- type: checkboxes
id: contribution
attributes:
label: Contributing Docs
description: If you plan on contributing code please read - [Contribution Guide](https://docs.opensauced.pizza/contributing/introduction-to-contributing/)
options:
- label: I agree to follow this project's Contribution Docs
required: false-
In your repository, click the "Issues" tab and then the "New issue" button.
-
Select the type of issue you want to create. In this example, we'll select Feature Request.
-
Write your issue. If you're following along the example, we'll write a feature request for a new resource:
**Type of feature:** 🍕 Feature **Current behavior:** I'd like to see a new resource for #100DaysOfOSS. **Suggested solution:** Add a new resource that introduces people to open source through [#100DaysOfOSS](https://docs.opensauced.pizza/community/100-days-of-oss/). **Code of Conduct:** I agree to follow this project's Code of Conduct. **Contributing Docs:** I agree to follow this project's Contribution Docs.
-
Once you've completed the issues, click "Submit new issue."
Now that you have your project set up, it's time to promote it! Here are some ideas to get you started:
- Share your project on social media, forums, and relevant communities.
- Write blog posts or tutorials about your project.
- Present your project at meetups, conferences, or online webinars.
- Create a Highlight on OpenSauced to showcase your project.
- Share your project with friends, family, and colleagues.
- Ask for feedback from your network.
In order to maintain a healthy project where contributors feel valued, it's important to recognize contributions. Here are some ways to do that:
- Use tools like the All Contributors bot to acknowledge different types of contributions.
- Highlight contributors in your README or on your project's website.
- Create a Highlight on OpenSauced to showcase contributors.
- Thank contributors publicly for their work.
Once your project is up and running, monitoring its health and activity is important. Here are some ways to do that:
- Create an OpenSauced Workspace to track your project's activity.
- Set up notifications for new issues and pull requests.
- Solicit feedback from users and contributors using discussions or surveys.
- Reflect on the project's direction and make adjustments as necessary.
You can learn more about how to create a successful project with OpenSauced with our Maintainers Guide to OpenSauced.
Congratulations on creating your first project! Now, you can share it on our Maintainers Guestbook page.
?> Remember, these steps are guidelines; the key to a healthy open source project is to foster an open, inclusive, and collaborative environment.