Or pretty much any open source project on github.
Start with downloading and compiling LND from scratch, if you haven’t already done so. A Linux system is probably easiest to get it to work on, but I have heard of people who run it on Windows too.
https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md is the procedure you are looking for.
Run this towards the testnet. Upgrade daily. Become familiar with git commands to pull changes, compile and install LND.
Now, start with creating a github user if you don’t already have one. Read the code, the structure of the project, understand how issues are handled and PRs are handled – in an organizational way.
Read https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md
Don’t worry at first if you don’t think you have the minimum coding skill sets. There’s still documentation to be written, fixed and clarified, and reading code will make you understand things better. Small bugs can be fixed even if you’re not that skilled coder.
Fork the LND project, to your own user! See https://guides.github.com/activities/forking/
Now, replace the working copy in the daily compile/upgrade workflow with your own project! Download and compile it, install and upgrade your testnet node with this.
Next step is to get changes from the main LND project incorporated into your own fork on a regular basis. You can follow the guide here: https://help.github.com/articles/configuring-a-remote-for-a-fork/
To keep your fork up to date, you can follow this guide: https://help.github.com/articles/syncing-a-fork/
To push this to your fork on github, you’ll do git push origin master
It is extremely important to use this fetch/merge method and not doing git pull from the upstream repository.
Now, work with this scheme for a couple of days, become familiar with the fetch/merge routine and pushing to your own repository.
Now you are ready to create your own changes in your fork. You’ll always want to keep the master branch free from your own changes and continuously synced with the upstream project.
Start with a really simple change. Fixing documentation errors or spelling errors is always a good exercise. You can also pick an issue labelled “beginner” from the github, if you feel like you are up to it!
Do
git branch your-branch-name
git checkout your-branch-name
Do the changes. For all files you have changed, you need to do git add file to make it be included when you want to create the commit. When you are finished, you can do “git commit -m “Descriptive message of your changes“. The convention is to use presens, i.e. “fix <something>” instead of “fixed <something>”. If doing code changes, it might be a good idea to at least make sure it compiles before doing the commit. It is possible to do several commits, but it’s not a good idea to have too many commits. Group changes that belong together at least, in the same commit. For more advanced usage, it’s possible to combine several commits into one at a later stage, but that’s beyond the scope of this article.
Push the changes to your github fork of the project: git push origin <branch-name>. The branch-name here should be the same as your own branch-name.
Now, work from that branch for a few days. Compile it, install it, run it on the testnet. Whenever there is changes on upstream, you will need to:
git fetch upstream master
git merge FETCH_HEAD
git checkout <your-branch>
git rebase master
The git rebase master command is, in effect, moving your changes to after the upstream changes. This will make sure that your changes are still valid, and you will have to manually resolve any conflicts. It’s a good idea to do this often, if you are working on a branch over time. At least do it before you create a pull request!
Now, you’ll need to push it to your fork on github again at least before creating the pull request.
Once you are satisifed that you want to contribute these changes to LND, go back to https://guides.github.com/activities/forking/ and create a pull request!
Be prepared for a discussion about your changes. If you need to do changes, you can continue working on it locally, then pushing it to origin. The PR will automatically be updated with the new changes you add. Remember fetch/merge to master, and rebase master on your own branch! You want your PR to “move” dynamically as the rest of the project moves on!
Confused? Just try it out. Everything up to creating the pull request affects noone but yourself, and even the pull request is harmless, as unless someone else approves (“merges”) it, it’s still just a request!
Last, but most important! Understand that even if you can contribute like this, noone is required to actually incorporate your changes. There is still people with “merge rights” that decides what goes into the code or not, eventually. Be humble, be ready to take on critism, and listen to more experienced people.
