Sprint Documentation

Introduction

Thank you for your interest in sprinting with the pyjanitor project!

The pyjanitor package has many places where your contributions can be valuable for the broader PyData community. We are hoping for contributions that fall into one of the four categories, in order of priority:

1. Documentation contributions.
2. Current function enhancements.
3. Test enhancements.
4. Other non-code enhancements (e.g. logo, social media, website)
5. New function contributions.

In particular, because it is psychologically much easier to contribute new functions than it is to improve documentation of existing ones, a pre-requisite for making a new function contribution is to first help us improve our docs. Doing so yields us a win-win proposition:

• you, the contributor, will have had a chance to go through the docs with a fine comb, and hence will have read through the docs properly to know what already has been contributed, and hence what doesn't need contributing;
• we, the project, will have better documentation that can be shared with other users;
• you, the contributor, will have at least two PRs to your name if you have a new function contribution: one for documentation of an existing function, and one for a new function.
• we, the project, will have our functions tested in life-like scenarios that are also documented
• you, the contributor, will likely hatch ideas for improving function behaviour.

What experience should I have?

We know that users of a tool often have the best opinions on how and why a tool should be improved. Hence, we hope that you are at least a pandas user who desires a nice API that wraps routine, multi-line, and repetitive code that you write.

Experience with git is a must, and you should have gone through the git workshop provided right at the beginning of the sprints. We use a simple workflow, usually called "GitFlow" in which you fork the repository, then in your fork, branch off from dev, and submit a pull request to make your contribution back to dev.

Contribution Types

Read on below for an elaboration on the kinds of contributions you could make under each of the four categories!

Documentation

The biggest sore point for documentation lie with examples. We need contributors to contribute life-like examples for how functions are used, and insert them into:

• Either function docstrings
• Or the examples directory as Jupyter notebooks.

Current Function Enhancements

Our users have had ideas for enhancing existing functions, basically based on a desired API that they would like. We hope that by making a docs contribution, you'll have ideas on how to enhance current functions.

Test Enhancements

We could use increased testing. This can be accomplished in generally one of two ways:

• Finding tests where we may have missed an edge case.
• Converting example-based tests to property-based tests with Hypothesis, where appropriate.

Testing enhancements means you'll probably be spending more time thinking than writing code. This is completely normal, and in fact good practice!

New Functions

This is last priority, not because we don't want new functions, but because we recognize that every new line of code is technical debt that needs to be maintained, and so we want to make sure that we have paid down the technical debt elsewhere before taking on new technical debt.

With that said, if you have a new idea that you want to contribute, please go ahead and contribute it! We just ask that you've made a contribution to our documentation first. Reasons have been stated above!