[Show/Discussion] Visualization of the datadogpy codebase

[ivanmilevtues]

Requirements for Contributing to this repository

• Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• The pull request must only fix one issue, or add one feature, at the time.
• The pull request must update the test suite to demonstrate the changed functionality.
• After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

This PR includes diagrams which represent the codebase. The idea of these documents is to help new people get up-to-speed with the existing codebase. I believe that diagrams are the best way to get high-level knowledge of a codebase and then focus on the interesting part of the codebase for your concrete contribution, having the context of how that component interacts with the rest of the codebase

Description of the Change

High-level diagrams for the codebase. You can see how they render in github here: https://github.com/CodeBoarding/GeneratedOnBoardings/blob/main/datadogpy/on_boarding.md

The diagram is generated with the help of Static Analysis and LLMs.

Alternate Designs

Possible alteranatives are classic documentation, however we think that diagram first documentation is the best way for new comers to get up-to-speed.

Possible Drawbacks

The diagram is generated so as well as human docs it has to be reviewed :).
We are also working on automatic generation via github actions, but this is yet to be available.

Verification Process

Someone has to accept the diagrams and validate thier quality

Additional Notes

Usually I would open a discussion first, but it seems like they are not enabled for this repository, so that is why I opened a PR :)

We would love to hear your feedback on the diagrams and the idea in general.

Full disclosure: we're trying to turn this into a startup, but we're still in a very early stage and figuring out what will actually be useful for people.

Release Notes

It is not a feature so I guess just that such documentation exists.

Review checklist (to be filled by reviewers)

• Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
• PR title must be written as a CHANGELOG entry (see why)
• Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
• PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
• PR should not have do-not-merge/ label attached.
• If Applicable, issue must have kind/ and severity/ labels attached at least.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.
Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity.

[ivanmilevtues]

Thanks for approving @michaelcretzman. Is there a way to ask someone else to review the change as well. It seems like 2 reviews are required

[ivanmilevtues]

Hey, just dropped by to let you know that CodeBoarding is now also open-source: https://github.com/CodeBoarding/CodeBoarding

So if you are interested in getting more information on how this generation works you can find it there