Skip to content
This repository has been archived by the owner on Sep 4, 2024. It is now read-only.

Latest commit

 

History

History
42 lines (25 loc) · 3.38 KB

CONTRIBUTING.md

File metadata and controls

42 lines (25 loc) · 3.38 KB
Raw

Introduction

Contributions Welcome

Thank you for considering contributing to this repo!

We encourage all contributions

We welcome any kind of contribution. You can improve documentation, triage bugs, write tutorials, fix small and large mistakes, add features, or refactor the whole shebang.

Philosophy

  1. unintrusive: fedcal's goal is to be a seamless integration on top of pandas. We can't always make it that way, especially at first, but we will aim to continually iterate and improve. We can also abandon any API feature while we're still in alpha/beta. After that, decisions will be harder.

  2. optimal over standard solutions: Fedcal will be snappy and responsive, and we'll implement any reasonable change that will make fedcal faster, better, or make the code more readable or easier to maintain. We won't worry about dependencies in the process -- what's the point of Python's rich ecosystem if we don't use it for all it's worth?

  3. avoid mission creep: If a proposed feature isn't related to time or analysis of data from, about, or influenced by the U.S. Government, then it doesn't belong in fedcal. That doesn't mean we can't add features that improve ease of analysis; we should do that because it aligns with our mission to democratize data.

  4. ownership @pseudomagi wrote the first version of fedcal and established its mission, but fedcal, like the data it seeks to analyze, should belong to anyone... especially those putting the work in to make it better.

Ground Rules

Responsibilities

  • Code snobs need not apply. Everyone starts somewhere; experienced contributors should help, guide, and mentor others (including @pseudomagi) if you know a better, cleaner, way.
  • Ensure cross-platform compatibility for every change that's accepted. Windows, Mac, Debian & Ubuntu Linux.
  • Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
  • Keep feature versions as small as possible, preferably one new feature per version.
  • Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. See the Python Community Code of Conduct.

Your First Contribution

If you've never contributed to a project before, this guide should help you get started: How to Contribute to an Open Source Project on GitHub.

All contributions big and small start with an issue. Use the provided templates in .github/ISSUE_TEMPLATES/. Clearly explain what the problem or proposed feature is, and how you think it should work. Any contribution is welcome -- it doesn't have to be code. You can improve the docs, readme, etc.

  1. If you want to suggest a major overhaul, fork the code, make your changes, and when you're happy with them, submit a pull request with the issue number.
  2. For smaller changes, work in a branch and submit a pull request referencing the issue number when ready.

Please use the provided pull request template in the .github folder for all PRs.

The maintainer(s) will regularly review pull requests and approve them after review. 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.