Skip to content

Latest commit

 

History

History
58 lines (47 loc) · 5.93 KB

CONTRIBUTING.md

File metadata and controls

58 lines (47 loc) · 5.93 KB
Raw

Contributing to OpenHatch

Yay! Its great that you want to contribute to the OpenHatch.org website. We look forward to receiving your contributions in code, feature requests and bug reports. Here are pointers and guidelines that we feel you should follow before creating your pull request, bug report or feature request.

Code Contributors Guide

OpenHatch.org has created good documentation for anyone who may want to hack on the website and to help new developers get up to speed. This contributor's guide is available Here

Pull Requests

How we handle code contributions is well explained in this page. The steps to be followed by both Contributors and Reviewers are nicely documented.

Feature Requests And Bug Reports

All feature requests and bug reports are created as new issues on the issue tracker. Before creating a new issue, please consider reading through the list of open issues to be sure they haven't already been raised. In case you find that one has already been raised, feel free to add a comment to it.

Creating Bug Reports

You've found an error on the site? The community is here to help. Go ahead and create a new bug report if it there isn't one for it already. We'd love it if you would also:

  • Label the issue with priority pri:bug (see the section on Issue Labels) or mention it as a bug in the issue comments.
  • Add a screenshot of your browser
  • Tell us what web browser you were using and the version of the browser (You would find this under the "About" section of your browser's Help e.g. Help->About Firefox)
  • Tell us what OS you're using
  • If you can, add labels letting us know where you think the issue would be, for example, CSS or JavaScript etc.

Bug reports for developer documentation are also tracked in the same issue tracker.

Creating Feature Requests

If there's a feature you'd like to see in the OpenHatch.org website, go ahead an create a feature request. To do that, simply:

  • Click on the New Issue button
  • Detail the feature in the new issue
  • Label the issue with priority a pri:feature (or mention that it is a feature request in the issue comments).

The community will work and take things forward.

Issue Labels

The issue tracker for oh-mainline (the github repository which maintains the code) primarily makes use of the below labels:

  • Priority:
    • pri:bug A bug on the website
    • pri:urgent A bug that needs urgent attention by the core developers
    • pri:critical A bug that needs to be fixed on priority and who's fix is critical to the smooth functioning of the website
    • pri:feature A feature request for the website
    • pri:wish A feature request for the website
  • Status:
    • stat:chatting: The issue is being discussed by members of the community
    • stat:deferred: The issue is being postponed, so don’t work on this issue.
    • stat:needs-decision: A question has been raised and a decision needs to be made before progress on the issue can continue.
    • stat:needs-review: A pull request is created and the contribution needs to be reviewed
    • stat:reopened: An issue that is being inspected again.
    • stat:resolved: Issues that have been fixed.
    • stat:unread: No maintainer has read this issue, so check before working on it
  • Components:
  • css: An issue related to a css file (the looks and description of a document)
  • documentation: Improving or creating the needed documentation.
  • missions: Issues related to training missions section on the openhatch site.
  • tests: Issues related to existing tests or demands for new ones.
  • usability: Issues related to the ease of use, in general.
  • Special Labels
  • bitesize: Small, self-contained issues that are good for new contributors. Warning: they may not be as bitesize as we thought, so please ask for help if you need it! Good questions to ask yourself or a community member include: "How will I know when the issue has been fixed?" "Where should I make my changes?" "Will I need to update documentation or tests?" "What tools or skills are needed to address this issue?"
  • mentor-available: Mentors are available for nearly every task if you ask around enough, but these tasks have a particular person who is enthusiastic about mentoring somone on that task. Mentors should leave a comment saying they want to mentor the task. Whoever assigns the label "mentor-available" is assumed to want to mentor.