I couldn't name any specific guides from the top of my head. And it really depends on how much time you're willing to invest.
If you want to deep dive into a new project, this is what I would recommend in general:

Pick any small to medium sized pull request
Find out why the pull request was created. What problem does it address? Usually there is an issue linked that explains it, or the body of the pull request explains it. If you can't figure out why the pull request is needed in the first place, that might already be a feedback you could give as a reviewer.
Once you understand the goal of the PR, go through the code and try to answer the following questions for yourself:
- How does each changed line contribute to the goal?
- Do I understand what each change does?
- Do I understand what the different files/modules/components changed in the PR do and how they interact?
To answer all the questions above, you might already need to dive deep into the project code and read a lot of it. This part might take a lot of time and effort to work through but will get easier the more familiar you are with the project.
Once you understand the code side, you might want to look into testing the code on your local machine. There are many approaches to this, but what I usually do is one or more of the following steps:
- Fist, make sure you can step-by-step debug Golang code in your IDE. Depending on which IDE you use, find a tutorial for that using Google. I for example use GoLand by JetBrains which is great (and not super expensive IMO).
- See if there are unit tests covering the changed areas. Try to run these unit tests locally and step through the code to see how it behaves at run time. Do you understand how the changes in the PR have an impact on the unit tests? Were the tests updated accordingly in the PR? If not, that might be a good feedback.
- See if there are interation tests (see the itest/ directory) that cover the changes in the PR? If yes, try to run and understand them. Same question as above, do the integration tests sufficiently cover the changes in the PR?
- Finally, you might want to manually test things in a local regtest setup where you create a small Lightning Network with a couple of nodes on your local machine. A great starting point for that is here: https://github.com/lightningnetwork/lnd/tree/master/docker
Now that you are fairly familiar with all the code in the PR, do you see anything that needs to be updated in the documentation?

I think that should get you started. Since you very likely will have questions, a good place to hang out and ask those questions probably is our community Slack server: https://lightning.engineering/slack.html

EDIT: Oh, and one very important resource I forgot to mention is our documentation: https://docs.lightning.engineering/

[feature]: give payment hash in subscribehtlcevents #7165

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions