Skip to content

Latest commit

 

History

History
18 lines (15 loc) · 2.22 KB

CONTRIBUTING.md

File metadata and controls

18 lines (15 loc) · 2.22 KB
Raw

Contribution to LIMP Guidelines

Thank you for your interest in LIMP. The decision behind opening the source of LIMP was a token of gratitude to the FOSS community that made building LIMP from the start possible--LIMP wouldn't have seen the light without great Python programming language, and its aiohttp. Also, thanks to many other elements that are knowledge shared from the Github and StackOverflow communities.

If you also are interested in contributing back to the FOSS community, please help us making LIMP better. Things you can do:

  • Test LIMP in use-cases that we didn't come across before. Share with us what you find in a Github issue.
  • Found a bug! Report it to us on Github, or if you know how to fix it, we would appreciate your efforts to fix it on a forked repo and sending a Pull Request.
  • Develop more advanced sample apps as reference to other LIMP developers and share it on Github. Let's know about it and we will add it to LIMP docs.
  • Help us improve the docs. Look for ways to improve the docs. Don't hesitate to fork the repo, update the docs and send us a Pull Request.
  • Suggest features that are inline with LIMP goal and purpose. We welcome any suggestion.
  • Contribute to the source code directly! Yes, we welcome contributions to the source code. Fork the repo, work on whatever you think is missing or require an improvement in LIMP, and send us a Pull Request. Just in case, make sure no issue opened reporting the same as feature or todo-item where we are working on it, so your efforts don't go wasted.

Things to Pay Attention to

Whatever your contribution is, we would appreciate having it inline with the current standard used. For example:

  • When you help us with the docs please make sure you are using British English and not American English.
  • When you are contributing to the source code, make sure you use variables names in line with the overall naming scheme.
  • When you are fixing a bug, make sure you test at least two environments, or else report what environments you could test it on.
  • When opening an issue of any kind, look for another opened issue with the same context and enrich it with your comment, feedback or additional details.