The ultimate goal of the RiotAPI.github.io repository is to store community written documentation and examples in a single, publicly available and maintainable location; as such, community submissions are always welcome through pull requests. Pull requests will all be reviewed by either the Community Gurus and/or some trusted members of the community. Below you'll find a standard set of guidelines for contributing.
The first step to making a contribution is to know what you want to contribute. There are a couple good questions to ask before jumping on a new markdown file:
- What exactly do I want to contribute?
- Can I describe what I want to contribute in a succinct and concise manner (eg. an elevator pitch)?
- Can my contribution be better described as an addition or a modification?
- Does my contribution fall under the categories of API docs or Language best practices and examples?
- Does my contribution already exist?
- Can I merge my contribution with an existing contribution?
These are valuable questions for not only figuring out a more exact idea of what you want to contribute, but also how best to go about contributing. In some cases you might need to just add on or modify an existing contribution, some you may be creating an issue, while in others you may be adding a new post. All contributions are valuable, but with the risk of becoming a bloated mess of posts we'd rather keep contributions well categorized and focused.
In order to maintain a level of quality control on community posted content, there are a few set rules:
- Do not promote any activities that violate the API developer policies.
- Ensure all contributions have been checked for proper spelling and grammar to the best of your abilities. A few mistakes here and there are fine but they shouldn't litter the content.
- Ensure all language specific contributions adhere to the relevant language coding style guide. If a coding style guide doesn't exist for your language, create an issue with a request for which you'd like to use so we can approve and add that to the list below.
- Ensure all markdown contributions follow the GitHub Markdown Syntax.
- Ensure all new markdown contributions are pushed to the _drafts folder. This allows us to do a final pass on things like spelling, grammar and formatting before the contribution goes live.
- Do not post any examples that contain security vulnerabilities or do not properly secure API keys. It's ok to post unsafe code to explain potential security issues, but it should be clearly labeled as unsafe to use.
- Explain why you're doing things a certain way in your guide. Readers should understand what examples do and how they work, and not be encouraged to blindly copy/paste code.
- If you disagree with another author over the "best" way to do something, explain all the possible approaches to the situation, along with their pros and cons. Readers should be able to choose the approach that works best for their use case and personal preference.
In order to maintain consistency across guides, we ask that you try to adhere to specific coding style conventions for each language. Below you'll find a list of approved style guides on a per-language basis.
- PHP: PSR-2