delve
delve copied to clipboard
go-delve
Internal Documentation
I've noticed the Internal Documentation remains empty. I'd like to contribute to it, as I see it as a great opportunity to know more about Delve and also Go internals.
I'm new here and I realize that understanding Delve's internals isn't an easy task (the TODO is assigned to its creator) but I just aim at getting the ball rolling contributing some minor PRs with whatever useful information I can provide.
I'm raising this issue to check if you think this is a doable task and see if any of the maintainers would be willing to provide me with some guidance of where to start, and answer some questions along the way (which I'll try to make as concrete as I can to take as little time from you as possible).
@schomatis you can absolutely submit a PR to provide this documentation, and I appreciate your interest in taking this on.
I would definitely be available for any questions you have regarding understanding the internals of Delve.
@derekparker Great, thanks. I'll start poking around and see what part of the code seems more accessible to me, unless you think there's a particularly good starting point.
@schomatis I suppose it depends a bit on what piques your interest the most and what part of the internals you'd like to document. If you are doing this also as a learning exercise for yourself it may help to start at the beginning and document how Delve builds, launches, and attaches to a process (and what that means). From there, there are any number of interesting things to document, including various Delve specific low-level features / functionality.
The double edged sword here is that the more detailed and specific the documentation is the harder it will be to maintain as the project is developed. I think there is a middle ground that will produce great, in depth documentation.
start at the beginning and document how Delve builds, launches, and attaches to a process (and what that means).
I'll try to start there and see where it takes me.
The double edged sword here is that the more detailed and specific the documentation is the harder it will be to maintain as the project is developed. I think there is a middle ground that will produce great, in depth documentation.
This is for me, by far, the most challenging aspect of writing this kind of documentation, which goes beyond the basic user guide, but aims at helping someone new (like me) delve into a project's internal workings (which change more rapidly than the user API).
I too believe there is a middle ground worth striving for (I don't think the best documentation is just commenting code, although that is the main part of it). I don't know a priori what is the correct balance, but it's worth thinking about it along the development of this documentation (I'm leaving PR #1091 open to discuss this and document the reached conclusions).