Skip to content

Latest commit

 

History

History
86 lines (63 loc) · 3.37 KB

contributing.md

File metadata and controls

86 lines (63 loc) · 3.37 KB
Raw

Gpredict Contribution Guidelines

Introduction

Thank you for considering contributing to Gpredict. Below you can find some brief guidelines for how to make your first contribution.

The most important thing to understand is that Gpredict is "old" software with the first release dating back to 2001. As a consequence, it contains a lot of legacy code and design choices that do not live up to what one would expect from modern desktop software. Therefore, the primary focus for the time being is fixing bugs and rewriting the parts that are causing poor user experience or difficulties in maintaining the software.

Contributions that add new features or functionality not currently on the roadmap have very low priority. The roadmap consists mostly of, in prioritized order:

  1. Issues included in a milestone
  2. Issues tagged with the labels bug, enhancement, feature, documents, and help wanted

How Can You Help?

The areas where I need most help with at the moment are:

  1. Testing and reporting bugs
  2. Fixing bugs
  3. Providing user support
  4. Packaging
  5. Website

Reporting Bugs

If you have found a new bug in Gpredict, please report it using the Gpredict issue tracker on GitHub. Please make sure to provide all the information that is necessary to reproduce the bug, including but not limited to:

  1. Your operating system.
  2. Which version of Gpredict and how it was installed.
  3. Steps required to trigger the bug.

Fixing Bugs

Bugfixes are always welcome and are a very good way for making your first contribution and they make a good first impression. However, before submitting a pull request, please ensure that:

  • Your changes are as small as possible and fix only one bug.
  • Your changes are well tested.
  • Your commits are atomic, i.e. complete and functional.
  • Write good commit messages and make sure to reference the issue you are fixing.
  • Avoid submitting merge commits; rebase your working branch instead.
  • If you have a series of commits where one commit fixes a previous one, squash them.
  • The pull request should cover only one topic, otherwise the review will be difficult and confusing.

Furthermore, until we get a formal coding style guide, please try to follow the coding style used in the surrounding code.

Providing User Support

We have a very nice user support forum hosted by Libre Space Foundation. Please help others who need technical support.

Packaging

I am doing my best to make Gpredict available on as many platforms as possible. While I can write platform independent code, I could definitely use some help with packaging and testing Gpredict on Windows and Mac OS X.

Website

I think that the existing website makes it very clear that I need help with creating a new website. Please let me know if you wish to help.

Thanks for reading this far 🙂

Alex, OZ9AEC