Skip to content

Latest commit

 

History

History
55 lines (44 loc) · 5.65 KB

CONTRIBUTING.md

File metadata and controls

55 lines (44 loc) · 5.65 KB

Yorot Project Contribution Guide

Thanks for your interest in contributing to the project! Please follow these simple guidelines:

General

  • Please use my social accounts ( ex. my Instagram account) as your first point of call for basic/simple questions.
  • When creating an issue please use the issue template provided.
  • Searching the GitHub project is a must. It's quite likely your question has already been answered before. If something is unclear in the Wiki, of course feel free to ask; the idea is just to reduce the level of "noise" we have to go through, reading the same questions over and over again.
  • Please make sure to test out the latest version of Yorot to see whether the problem you are encountering still exists.
  • Don't cross-post: if you create an issue, and all the information is contained there, that's enough. There's no reason to also post it to anywhere else; it just creates "line noise". The project maintainers are very busy people like you and me, and things will sometimes take a few weeks (or in worst case, more) to answer. If you are in a rush - do your very best to investigate the problem thoroughly; if possible, fix the bug yourself and submit a pull request.
  • Before creating a GitHub issue or pull request, try looking through the list & issue archives to make sure the issue at hand hasn't been raised before. Google can also be helpful.
  • We do appreciate cultural/languages differences. That being said, never demand that someone (except the contributors) to help you. Please and thank you go a long way.

Issues

When creating an issue please use the provided by report template (the field will be pre-populated). A bug is a demonstrable problem that is caused by the code in the repository. Ideally each issue is a useful resource for references purposes (Don't take offence if someone edits your description). Your report should always look like any of the templates.

  1. Asking the same questions over and over again is wasting our time, search open/closed issues to see if your issue has already been addressed.
  2. Having to constantly query users to gather information is very frustrating! Use the bug template provided above.
  3. We have very limited active contributors (only 1 guy and it's me) so please spend as much time looking into your own problem as possible, the more you help yourself, the quicker things will get fixed.
  4. Please don't hijack issues, if your problem is distinct then please create a unique issue (after searching previous issues).
  5. Good bug reports are extremely helpful. The more information you provide, the more likely your issue will be resolved.
  6. Good bug reports shouldn't leave others needing to chase you up for more information. Be sure to include the details of your environment.
  7. 'Ask Don't Tell' : Ask how to achieve something, don't say it's broken just because you haven't got it working yet!
  8. Isolate the problem — ideally create a reproducible example.
  9. Include a screencast if relevant - Is your issue about a design or front end feature or bug? The most helpful thing in the world is if we can see what you're talking about. USe recording software and embed it to your issue.
  10. When including code, limit to small chunks and post large blocks as a Gist or etc.
  11. Please don't link binaries (e.g. zip files), either contribute your example as a GitHub project, a gist or another public code sharing service.

Change Requests

Change requests cover both architectural and functional changes to how Yorot works. If you have an idea for a refactor, or an improvement to a feature, etc - please be sure to:

  1. Use the GitHub search and check someone else didn't get there first
  2. Take a moment to think about the best way to make a case for, and explain what you're thinking as it's up to you to convince the project's leaders the change is worthwhile. Some questions to consider are:
    • Is it really one idea or is it many?
    • What problem are you solving?
    • Why is what you are suggesting better than what's already there?

Pull Requests/Feature Branches

Pull requests are awesome. If you're looking to raise a PR for something which doesn't have an open issue, please think carefully about raising an issue which your PR can close, especially if you're fixing a bug. This makes it more likely that there will be enough information available for your PR to be properly tested and merged.

  • Please limit your changes to a logical grouping, keeping changesets small increases the likelihood they will be merged
  • If you then want to make subsequent changes, it's actually best to not do them before the feature is merged. Please wait for feedback/review before progressing. This greatly improves our ability to review your changes and dramatically increases the likelihood they will be merged in a timely fashion.
  • Small (really, minimalistic) commits. Each individual commit only adds one specific thing. The basic approach to achieving this is to read your commit message. Do you feel the need to add multiple lines? Then you're doing too much at the same time.

You can contribute more by:

  • Downloading Yorot and reporting any problems while using it.
  • Checking out issues.
  • Editing the source code by creating a pull request or fork.
  • Advertising it (I'm open for free advertising.)
  • Supporting me on Patreon

this file is stolen (but i changed some stuff) from cefsharp contributing guideline.