Before you begin:
- Have you read the code of conduct?
- Check out the existing issues & see if we accept contributions for your type of issue.
If you spot something new, open an issue using a template. We'll use the issue to have a conversation about the problem you want to fix.
Fork using GitHub Desktop:
- Getting started with GitHub Desktop will guide you through setting up Desktop.
- Once Desktop is set up, you can use it to fork the repo!
Fork using the command line:
- Fork the repo so that you can make your changes without affecting the original project until you're ready to merge them.
Fork with GitHub Codespaces:
- Fork, edit, and preview using GitHub Codespaces without having to install and run the project locally.
Make your changes to the file(s) you'd like to update. Here are some tips and tricks for using the docs codebase.
- Are you contributing to markdown? We use GitHub Markdown.
When you're done making changes and you'd like to propose them for review, use the pull request template to open your PR (pull request).
- Once you submit your PR, others from the Docs community will review it with you. The first thing you're going to want to do is a self review.
- After that, we may have questions, check back on your PR to keep up with the conversation.
- Did you have an issue, like a merge conflict? Check out our git tutorial on how to resolve merge conflicts and other issues.
Congratulations! The whole SuperOffice community thanks you. ✨
Once your PR is merged, you will be proudly listed as a contributor in the contributor chart.
Now that you're a part of the SuperOffice Docs community, you can keep participating in many ways.
Learn more about contributing:
- Types of contributions 📝
- Starting with an issue
- Opening a pull request
- Working in the superoffice/docs repository
- Reviewing
You can contribute to the SuperOffice Docs content and site in several ways. This repo is a place to discuss and collaborate on docs.superoffice.com! Our small, but mighty 💪 docs team is maintaining this repo, to preserve our bandwidth, off topic conversations will be closed.
Discussions are where we have conversations.
If you'd like help troubleshooting a docs PR you're working on, have a great new idea, or want to share something amazing you've learned in our docs, join us in discussions.
Issues are used to track tasks that contributors can help with. If an issue has a triage label, we haven't reviewed it yet and you shouldn't begin work on it.
If you've found something in the content or the website that should be updated, search open issues to see if someone else has reported the same thing. If it's something new, open an issue using a template. We'll use the issue to have a conversation about the problem you want to fix.
A pull request is a way to suggest changes in our repository.
When we merge those changes, they should be deployed to the live site within 24 hours. 🌍 To learn more about opening a pull request in this repo, see Opening a pull request below.
We are a small team working hard to keep up with the documentation demands of a continuously changing product. Unfortunately, we just can't help with support questions in this repository. If you are experiencing a problem with SuperOffice, unrelated to our documentation, please contact SuperOffice Support directly. Any issues, discussions, or pull requests opened here requesting support will be given information about how to contact SuperOffice Support, then closed and locked.
If you're having trouble with your SuperOffice account, contact Support.
SuperOffice's site policies are published on docs.superoffice.com, too!
If you find a typo in the site policy section, you can open a pull request to fix it. For anything else, see the CONTRIBUTING guide in the site-policy repo.
You can browse existing issues to find something that needs help!
Labels can help you find an issue you'd like to help with.
- The
help wantedlabel is for problems or updates that anyone in the community can start working on. - The
good first issuelabel is for problems or updates we think are ideal for beginners. - The
contentlabel is for problems or updates in the content on docs.superoffice.com. These will usually require some knowledge of Markdown.
You can use the GitHub user interface ✏️ for some small changes, like fixing a typo or updating a readme. You can also fork the repo and then clone it locally, to view changes and run your tests on your machine.
Here's some information that might be helpful while working on a Docs PR:
-
Content markup reference - All of our content is written in GitHub-flavored Markdown, with some additional enhancements.
-
Content style guide for SuperOffice Docs - This guide covers SuperOffice-specific information about how we style our content and images. It also links to the resources we use for general style guidelines.
-
Includes - We use includes to help us keep content up to date. Instead of writing the same long string of information in several articles, we create an include, then call it from the individual articles.
We (usually the docs team, but sometimes SuperOffice product managers or developers) review every single PR. The purpose of reviews is to create the best content we can for people who use SuperOffice.
💛 Reviews are always respectful, acknowledging that everyone did the best possible job with the knowledge they had at the time.
💛 Reviews discuss content, not the person who created it.
💛 Reviews are constructive and start conversation around feedback.
You should always review your own PR first.
For content changes, make sure that you:
- Confirm that the changes address every part of the content strategy plan from your issue (if there are differences, explain them).
- Review the content for technical accuracy.
- Copy-edit the changes for grammar, spelling, and adherence to the style guide.
- Check that all of your changes render correctly in staging. Remember, that lists and tables can be tricky.
- If there are any failing checks in your PR, troubleshoot them until they're all passing.
When you open a pull request, you must fill out the "Ready for review" template before we can review your PR. This template helps reviewers understand your changes and the purpose of your pull request.
We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
As you update your PR and apply changes, mark each conversation as resolved.