Skip to content

Latest commit

 

History

History
76 lines (57 loc) · 5.04 KB

CONTRIBUTING.md

File metadata and controls

76 lines (57 loc) · 5.04 KB

Introduction

Thank you for considering contributing to Moody!

By following these guidelines you are demonstrating your good intentions and vibes to the maintainers, and you are making the open source community possible. In return, the maintainers should respond to issues, changes, and pull requests in a similar manner.

We are open to many contributions, in particular bug reports and documentation improvements are examples of helpful contributions that are essential to the growth of the project. Feature additions are also very welcome, as it is harder to accommodate feature requests promptly.

Explain contributions you are NOT looking for (if any).

Contributions of feature additions must be in-line with the objectives and intended scope for the project as understood by the project maintainers. Smaller feature additions are prefered over larger conglomeration as they will be easier to review individually. In short: Be excellent to each other 🎸🎸🎸

Ground Rules

Set expectations for behavior (yours, and theirs).

The most important rule is that communications must be respectful and considerate to all parties. Contributers must respect that the maintainers are people too, and maintainers must also be considerate in return. Users new to open source may want to consult this blog post to gain a perspective of open source volunteering from the maintainers' perspective.

Other Responsibilities

  • Test your code before making the pull request
  • add tests for new functions, and fix tests that break from your changes (not by commenting them out)
  • try to keep things platform neutral
  • Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
  • Don't add any classes to the codebase unless absolutely needed. Err on the side of using functions.
  • Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. See the Python Community Code of Conduct.

Your First Contribution

Unsure where to begin contributing to Moody? You can start by looking through the current beginner and help-wanted issues. If non are present ask in the gitter or #tools room in the http://openplanetary.co/ slack. Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub. At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first! If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.

How to submit a pull request

Here is the general process for making a code contribution to Moody. Moody is MIT licensed and as such all contributions must be made with the same license.

  1. Create your own fork of the project
  2. Do the changes in your fork
  3. If you like the change and think the project could use it:
    • Be sure you have followed the code style for the project.
    • Send a pull request that should be a single commit on to the master branch with a detailed commit message.

Commit messages should start with a title line followed by a newline followed by a markdown formatted list of changes.

How to report a bug

Security

Security is scarry and hard to do correctly. If you find an issue please fix it and submit a PR asap with an explaination of what happened.

How to file a bug report.

When filing an issue, make sure to answer these five questions:

  1. What version of Python are you using (including minor number)?
  2. What operating system and processor architecture are you using?
  3. What did you do?
  4. What did you expect to see?
  5. What did you see instead?

How to suggest a feature or enhancement

The Moody philosophy is to build a simple to use CLI around the Mars ODE rest api, mainly for downloading files. That being said if a more general pythonic api is created over time that is also a cool thing to do.

Feature requests should generally be aligned with that goal. Platform compatibility is also a goal for the project with the exception of the Windows platform as the Ubuntu Userspace for windows should largely make that just work. That being said, if it is easy to directly support windows then that should be done.

Code review process

The core team will review Pull Requests as they are posted and make suggestions in comments on the PR. In general, comments made by the maintainers should be followed (but can be contested), and a PR might not be merged if changes suggested by the maintainers are not resolved. PRs that are inactive after two weeks or so will be closed, but can be reopened once activity resumes.

Community

Moody should have a gitter room soon, and the maintainers likely hang out on the http://openplanetary.co/ slack.