PushFish - Contributing Guide
Welcome to PushFish!
Interested in working on the PushFish server API, the PushFish Android app, or other PushFish infrastructure? Awesome! This guide will get you started.
Typical usage of PushFish does not involve a single piece of software, but several interacting components.
If you want to contribute to PushFish, there’s definitely something for you! The first step is to figure out what project to work on.
Core Protocol Components
|Component||Language (Toolset)||What Is It|
|PushFish-api||Python||The Python code that powers the API itself, using MQTT.|
|PushFish-Py||Python||A Python client API for PushFish. It sends Push notifications from Python scripts, and can be used to connect any command line application to PushFish!|
|PushFish-Connectors||Python||Allows users to listen for PushFish messages via TCP and websockets.|
|Application||Language (Toolset)||What Is It|
|PushFish-Android||Java||The Android app that connects to the PushFish API server and MQTT.|
|Site||Language (Toolset)||What Is It|
A group of passionate, volunteer geeks are working to make PushFish awesome. Join us!
How To Contribute Code
- Join the Community. By joining our Slack, you can interact with other developers when you have questions, ideas, or problems.
- Get set up. Each repo has a
README.mdfile with clear instructions on how to get the repo up and running properly. Thanks, Repository Standards!
- Find something to work on. All actively developed repositories should have issues tagged “Good First Issues” specifically for new contributors. You are also welcome to work on something not currently filed if you have your own idea. Additionally, all repositories have contact information for the maintainer if you have trouble finding an issue to work on.
- Abide coding and commit standards. Any specific information necessary to know in this regard should be in the project
- Commit early and ask questions. Is an issue confusing? Please comment and say so! Not sure if you’ve got the right approach? Commit your code and we’ll give feedback. Certain you’re doing everything right? Commit it anyway. Once you commit, open a pull request. We encourage work-in-progress commits to let us know you’re working on something and to facilitate feedback.
- Accept feedback and finish. Most pull requests are reviewed within two business days. Once the repository maintainer has approved your contribution, it will get merged and you’ll get a huge thank you!.
Web and application designers are requested to be able to work directly on CSS in the project they’d be contributing to. Please follow the Coding instructions for any website or application you want to improve.
Most written content, and especially all technical writing, is checked into source control. To improve content we’ve written or add new content:
- Identify which website or application it is in (see the overview).
- Search for a quoted phrase of the content you want to change (or use the same technique to identify the folder to create a new document in).
- Edit the content via the GitLab interface and submit it as a pull request.
If you want to contribute without getting directly into the code, one of the best ways you can contribute is testing.
A number of our code bases (PushFish-api, PushFish-Py, PushFish-Android) go through regular release cycles where new versions are shipped every several weeks. Testing pre-release versions is a great way to help us identify issues and ship bug-free code.
Ways to Test
- “Watch” the repo on GitLab. You will receive an email with release notes whenever a release candidate is out and you can raise an issue.
- Join the #early-testing channel in our Slack.
- For the hardcore, run master from source and/or the latest builds from GitLab.
Opening well-specified issues against release candidates or master builds is extremely useful in helping us create quality software.
Note: Please do not use important data when testing. If using release candidates and especially master builds, back up your database and be cautious. While a substantial bug, like one that caused loss of data, you perform testing at your own risk.
If you’re about to raise an issue because you’ve found a problem with PushFish, or you’d like to request a new feature, or for any other reason, please read this first.
Reporting a Bug
A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful - thank you! Guidelines for bug reports:
- Identify the correct repo. See ecosystem overview. While it’s okay if you get this wrong, it’s a big help to us if you get it right.
- Check if the issue exists. Please do a quick search to see if the issue has been reported (or fixed), including closed tickets.
- Follow the instructions - When you open an issue inside of GitLab, each repo contains a template for how to create a good bug report. Santa loves people who follow it.
Well-specified bug reports save developers lots of time and are appreciated.
Feature requests are welcome. Before you submit one be sure to:
- Identify the correct repo. See ecosystem overview.
- Use the GitLab Issues search and check the feature hasn’t already been requested. Be sure to include closed tickets.
- Consider whether it’s feasible for us to tackle this feature in the next 6-12 months. The PushFish team is currently stretched thin just adding basic functionality. If this is a nice to have rather than a need, it is probably more clutter than helpful.
- Make a strong case to convince the project’s leaders of the merits of this feature. Please provide as much detail and context as possible. This means explaining the use case and why it is likely to be common.
Discussion and Help
Sometimes, you may have a problem but an issue isn’t appropriate (or you’re not sure if it’s a real issue).