Skip to content

Latest commit

 

History

History
65 lines (37 loc) · 4.38 KB

Contributing.md

File metadata and controls

65 lines (37 loc) · 4.38 KB

Contributing to this project

Code contributions are welcomed!

Developer process & workflows

This document stablish the process and workflows as per github and gitflow good practices (in some cases simplified and relaxed), if in doubt please take a peek here or here

This practices must appear so "elite" or "cathedral style" at first, but believe me you will thanks me for teaching you this if you pretend to work for a bigger project or a professional soft company. At the end and with the time you will see how easy is to pin-point any info from the entangle of branches, issues, travis, etc.

At first we will be easy with this but people, please catch the (git)flow ASAP.

It's all about issues!

Yes, it's all about issues, every change must have a reference issue in which the dev team can debate about, and branches that name the user and issue it's working on.

So if you need to do a change, fix something or add a new feature, please open an issue for it. Once you have a issue number to work with, create a branch from latest develop in YOUR own fork and name it user_t#_short_description_of_issue, for example: stdevPavelmc_t8_travis_integration where the "t8" is the issue number

Commits

All commits comments must start with "Refs #8, ...." where in this case the #8 refers to the issue you are working on, why? see it here in action

Hover the mouse over the name, number and comments of the commit d4a19cd github does a great job by linking all together, this is possible because we mentioned the issue in the branch name and also in the commit comment.

Pull request

Pull request are intentions to merge some code into the main tree, you can open a pull request of your local work at any time, the only condition is that you have pushed at least a commit for an issue.

In fact it's a recommended practice, open an issue, analyze, make your first commit and open the pull request ride away; in this way changes will be picked by travis and CI/CD will fire to tell you if your changes are good o broke something. (If I setup a travis workflow in the future...)

As a general rule a pull request must end with a comment on which you mentions @stdevPavelmc and estate that the pull request is ready to review & merge.

The merge action by the repo owner (@stdevPavelmc) will automatically close the corresponding pull request and the issue just by adding a comment like this to the comment of the merge "Closing issue #8..." github will do the magic and will (if travis build is a success) close the PR and the matching issue, all in just one place.

Community recognition

Yes, just by sharing the existance of this project you will be giving it a community recognition; share the link of proyect with your experiences in your social media networks, mention it to other hams, etc. It will be appreciated.

Hardware, Parts and other Ham goods via direct delivery...

If by chance you have a planed trip to Cuba (or a relative o a close known person of trust) and you remember about me; and by chance you can donate a old/unused HT, a Raspberry or any other electronics goods, please contact me and I will give you precise instructions on how to make it trough custom.

That kind of thing are really hard to get here.

Monetary contributions

This is free software and you can use it without charges, but if you want to express your gratitude in monetary form here is how:

Top my cell phone up!

That will allow me to stay online to develop & improve it, my cell number is: (+53) 53 847 819, You can donate the amount you want.

Tip: my service provider has promotions almost every other week that will duplicate any amount in excess of USD $20.00!

Thank you very much in advance!