Skip to content

Latest commit

 

History

History
98 lines (77 loc) · 3.73 KB

CONTRIBUTING.org

File metadata and controls

98 lines (77 loc) · 3.73 KB
Raw

Contribute to org-parser

First off, thank you for considering contributing to org-parser. It’s people like you that make org-parser such a great tool!

Did you find a bug or do you want to implement a new feature?

What do we consider a bug? A bug is when an existing feature is broken.

A feature request is to ask for change in an existing feature or to ask for a completely new feature.

Hence, if your request is about a feature that Emacs Org mode has, but org-parser lacks, this is a feature request, not a bug.

  • Ensure the bug or feature was not already reported by searching on GitHub under Issues.
  • Ensure that the the bug you want to report is not known behavior by reading the readme and the wiki.
  • If you’re unable to find an open issue addressing the problem, open a new one.
    • If you want to report a bug or request a feature, please use the “Bug report” or “Feature request” ticket and fill out the asked for metadata.
    • If your request is neither about a bug nor feature, please do open a blank issue.

How we work with issues

One of our quality goals is to keep the amount of issues manageable. This means that a single person has to be able to groom the backlog (review the open issues) in a reasonable amount of time.

These are the steps we take to ensure a high quality in the backlog:

  1. We only keep issues open on a longer term basis that fulfill one of the following criteria
    • Someone has committed to work on it or plausibly plans to do so in the future
    • It is a bug or regression
  2. If someone files a bug or feature request which is either not clear to the maintainers or is likely not a bug, but known and documented behavior, we ask a question or link to the documentation. We also add a ‘question’ label to the issue. If the issue creator does not respond to the question within 5 days, we close the issue. If she does choose to respond at some point, she can re-open the issue.

Development collaboration

We have good quality assurance and an established workflow. This is it:

  1. Open a new GitHub pull request
  2. Ensure the PR title and description clearly describes the problem and solution. Include the relevant issue number if applicable.
  3. New Branch in Git
  4. Naming: (feature|fix|chore)/issue-id/short-description
  5. Develop / Test locally until tests pass
  6. Create Pull Request on Github to master
    • Check that the tests also pass on CI
  7. Core Team: Merge to master, deploy and accept the Issue on Github

Definition of Done

An issue is done when:

  • Functionality has been implemented
  • Functionality has been verified
  • Surrounding main functionality has been regression tested
  • Code has been reviewed
    • Proper code style
    • Code has tests (acceptance tests for user visible changes, otherwise at least unit tests)
    • Follows clean code guidelines and architecture best practices
    • Code has been documented
  • Code has been merged
  • Tested on supported browsers

Clean code guidelines

  • Create small and highly cohesive modules
    • Avoid long modules
    • Extract modules to separate responsibilities
  • Create small methods or functions
    • Avoid long methods or functions
    • Extract methods or functions to separate responsibilities
    • Do one thing

Thanks! 🙏 🙇

org-parser Team

200ok llc and all contributors