Contributing
Jump to our community guidelines
The pySYD
team
Our community continues to grow! See below to find out how you can help ☺
Contributors
Main author: Ashley Chontos (email | website)
All contributors (listed alphabetically):
Ashley Chontos (@ashleychontos)
Sam Grayson (@charmoniumQ)
Daniel Huber (@danxhuber)
Maryum Sayeed (@MaryumSayeed)
Pavadol Yamsiri (@pavyamsiri)
Important
pySYD
was initially the Python
translation of the IDL
-based asteroseismology
pipeline SYD
, which was written by my PhD advisor, Dan Huber, during his PhD in
Sydney (hence the name). Therefore none of this would have been possible without his
i) years of hard work during his PhD as well as ii) years of patience during my PhD ☺
~A very special shoutout to Dan~
Collaborators
We have many amazing collaborators that have helped with the development of the software, especially with the
improvements that have been implemented – which have ultimately made pySYD
more user-friendly. Many
thanks to our collaborators!
pySYD
collaborators:
Tim Bedding
Marc Hon
Dennis Stello
Community guidelines
For most (if not all) questions/concerns, checking our discussions forum is a great place to start in case things have already been brought up and/or addressed.
If you would like to contribute, here are the guidelines we ask you to follow:
Contributing code
Question or problem
→ Do you have a general question that is not directly related to software functionality?
Please visit our relevant thread first to see if your question has already been asked. You can also help us keep this space up-to-date, linking topics/issues to relevant threads and adding appropriate tags whenever/wherever possible. This is not only helpful to us but also helpful for the community! Once we have enough data points, we will establish a forum for frequently asked questions (FAQ).
Warning
Please do not open issues for general support questions as we want to preserve them for bug reports and new feature requests ONLY. Therefore to save everyone time, we will be systematically closing all issues that do not follow these guidelines.
If this still does not work for you and you would like to chat with someone in real-time, please contact Ashley to set up a chat or zoom meeting.
Issues & bugs
→ Are you reporting a bug?
If the code crashes or you find a bug, please search the issue tracker first to make sure the problem (i.e. issue) does not already exist. If and only if you do this but still don’t find anything, feel free to submit an issue. And, if you’re really brave, you can submit an issue along with a pull request fix.
Ideally we would love to resolve all issues immediately but before fixing a bug, we first to need reproduce and confirm it. There is a template of the required information when you submit an issue, but generally we ask that you:
clearly and concisely explain the issue or bug
provide any relevant data so that we can reproduce the error
information on the software and operating system
You can file new issues by filling out our bug report template.
New features
→ Have an idea for a new feature or functionality?
Request
If you come up with an idea for a new feature that you’d like to see implemented in
pySYD
but do not plan to do this yourself, you can submit an issue with our
feature request template.
We welcome any and all ideas!
Direct implementation
However, if you come up with a brilliant idea that you’d like to take a stab at – Please first consider what kind of change it is:
For a Major Feature, first open an issue and outline your proposal so that it can be discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
Any smaller or Minor Features can be crafted and directly submitted as a pull request. However, before you submit a pull request, please see our style guide to facilitate and expedite the merge process.
Contributing code
→ Do you want to contribute code?
We would love for you to contribute to pySYD
and make it even better than it is today!
Style guide
** A good rule of thumb is to try to make your code blend in with the surrounding code.
Code
4 spaces for indentation (i.e. no tabs please)
80 character line length
commas last
declare variables in the outermost scope that they are used
camelCase for variables in JavaScript and for classes/objects in Python
snake_case for variables in Python
Docstrings
Coding Rules
To ensure consistency throughout the source code, keep these rules in mind as you are working:
All features or bug fixes must be tested by one or more specs (unit-tests).
We follow [Google’s JavaScript Style Guide][js-style-guide].