Skip to content

Latest commit

 

History

History
51 lines (40 loc) · 3.84 KB

CONTRIBUTING.md

File metadata and controls

51 lines (40 loc) · 3.84 KB
Raw

Contribution Guidelines

So you want to help with the development of Trébol? Thanks so much! Please, follow guidance as described in this file.

These are not mandatory rules, but if you want your contributions to be accepted eagerly, it is better to follow them as good as you can.

If you have any questions, don't hesitate to contact @bglamadrid (me) for it.

Where is help needed? 🤔

  • Try the live demo, see if you have any suggestions or find anything wrong with it
  • Improve existing documentation
    • Suggest or submit better contribution guidelines
    • This codebase is basically documented through JSDoc comments and test units
  • See the Issues section to find technical work that needs doing. Most of these tasks relate to:
    • Writing code to comply with newer backend REST API
    • Adding new client-side functionality
    • Improving user experience and accesibility
    • Finding code that is worth improving, be it about performance, readability, or else
  • Translate the application to more languages; please read the Angular guide on working with translation files so you know how to proceed

Submitting issues 💡

  • Before submitting an issue, please do search in the current issues list to prevent creating duplicates
    • Remember you can also join the discussion of an ongoing issue; if you have anything to say, please don't hesitate
  • Your issues should relate at least to one of the following subjects, and they should include certain basic information based on them:
    • bug - explain the expected behavior vs the resulting behavior; include a description of the procedure you used to replicate the problem
    • feature - explain the functionality that you wish to add or see added
    • enhancement - explain the functionality you wish to improve or see improved, and what aspects of the application would be affected
    • tests - submit one or more unit tests, or a group of mutually dependant unit tests, per issue
    • refactor, documentation or i18n - briefly explain the changes and/or additions you want to introduce or see introduced
  • Specificity is not a requirement, but it is appreciated
    • Include the expected outcome of working on the issue, or an approximation
    • Declare some steps to be followed: if possible, try to divide your issue into a logical sequence of tasks
    • Indicate the use case you're expecting to cover, such as "clicking the login button when the user has not typed their password in"
  • Use markdown to your advantage
    • Adding some headings goes a long way in structuring your text; rich text structure makes it easier for everyone to read and follow up with your train of thought

Working on issues 🔬

  • If you want to to work on an issue, request that it is assigned to you beforehand.
  • If you are assigned to, and for some reason can't or don't want to go on with something, be it an issue or a pull request, please let me know. It's okay to stop and take breaks when necessary. But most importantly, transparency and honesty in these matters are appreciated.

Submitting pull requests ⚗️

  • Make sure you describe your changes in the CHANGELOG.md file
    • Try to keep it simple and concise.
    • Do not add excessively technical info about the changes, like filenames or line numbers.
      • If you need to do that, you can add comments within the GitHub web interface.
    • You can, and are encouraged to, give yourself authorship of your changes.