High-level diagram of the python-slack-sdk

[ivanmilevtues]

Summary

Generated documentation to help new developers to get to know the python-slack-sdk (from the stand point of contributors).

Let me know what is your opinion on the generated diagrams, do they fit in your existing process of on-boarding people to new codebases?

Any feedback is more than welcome!

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.

Testing

This is pure documentation contribution, so no testing is needed!

Category

• [ ] slack_sdk.web.WebClient (sync/async) (Web API client)
• [ ] slack_sdk.webhook.WebhookClient (sync/async) (Incoming Webhook, response_url sender)
• [ ] slack_sdk.socket_mode (Socket Mode client)
• [ ] slack_sdk.signature (Request Signature Verifier)
• [ ] slack_sdk.oauth (OAuth Flow Utilities)
• [ ] slack_sdk.models (UI component builders)
• [ ] slack_sdk.scim (SCIM API client)
• [ ] slack_sdk.audit_logs (Audit Logs API client)
• [ ] slack_sdk.rtm_v2 (RTM client)
• [x] /docs (Documents)
• [x] /tutorial (PythOnBoardingBot tutorial)
• [ ] tests/integration_tests (Automated tests for this library)

Requirements

• [x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• [x] I've read and agree to the Code of Conduct.
• [x] I've run python3 -m venv .venv && source .venv/bin/activate && ./scripts/run_validation.sh after making the changes.

[salesforce-cla[bot]]

Thanks for the contribution! Before we can merge this, we need @ivanmilevtues to sign the Salesforce Inc. Contributor License Agreement.

[ivanmilevtues]

I signed the CLA, however the label is still on the PR. Can someone take a look?

[zimeg]

Hey @ivanmilevtues! 👋 This is so interesting - thanks for sharing 📚 ✨

I haven't reviewed all of the docs for correctness at this time, but I'm hesitant to include generated documentation for contributors as markdown when inline reference can serve similar purpose with a better chance of being updated with related edits?

I am so curious about what others think and am wondering aloud if these notes could be generated as needed instead? 🤖

[ivanmilevtues]

Thanks for the response @zimeg! I think the inline references are awesome further they are something that most repo's don't have. However we strive to give an overview of the project structure and allow newcomers to grasp the main components and how they interact with each other - I personally really like looking at diagrams rather than reading docs :).

I would love to see what the community thinks on this idea in general. So thank you for putting the discussion and docs labels <3

[WilliamBergamin]

I side with @zimeg here, I am also hesitant to include more generated documentation in this project 🤔 I also think we should keep our dependencies to a minimum in order to help maintainers in their work

[ivanmilevtues]

@WilliamBergamin, I understand your point and if you think it is not the place for it. Just on the maintainers side, we are just finishing our GitHub action which will keep the docs automatically up-to-date. Lmk how that sounds to you!

[ivanmilevtues]

@zimeg and @WilliamBergamin wanted to update you that CodeBoarding is open-source now: https://github.com/CodeBoarding/CodeBoarding You can take a look on the whole generation process if interested :)