Update README.md

[gmaciolek]

JIRA Ticket:
BB2-1472

User Story or Bug Summary:

Polish the GitHub SDK repo and readme docs related to Node & Python SDKs. Proof-read and check styling.

What Does This PR Do?

Revise readme to improve organization of information, make instructions more concise and clear, add sections commonly included in readme files (Prerequisites, About, Help and Support), and apply DASG content style guide-based changes.

What Should Reviewers Watch For?

If you're reviewing this PR, please check these things, in particular:
Please review carefully that my edits didn't compromise the accuracy of the information. I tried to simplify the sentence structure in a few places, but I might have gone too far.

• Is the information accurate?
• Is the information clearly communicated?
• Is any critical information missing?
• Is any trivial information or information that might be better addressed in a separate documented included?

Question for reviewers

From Rachel: "I think we need to add some language here about liability in terms of security issues. This should be language that is everywhere for the SDK."

She gave the following example text from AB2D: It is important to note that the AB2D team does not regularly maintain the sample clients. Additionally, a best-effort was made to ensure the clients are secure but they have not undergone comprehensive formal security testing. Each user/organization is responsible for conducting their own review and testing prior to implementation.

Is there some equivalent text we could add to a new security section for both SDK readmes?

What Security Implications Does This PR Have?

none

I have gone through and verified that...:

I'm not sure that this checklist is directly applicable to a documentation-specific type of PR, but I'll check off what seems relevant. Let me know if there's anything else I should verify.

• This PR is reasonably limited in scope, to help ensure that:
  1. It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
  2. There isn't too much of a burden on reviewers.
  3. Any problems it causes have a small "blast radius".
  4. It'll be easier to rollback if that becomes necessary.
• I have named this PR and its branch such that they'll be automatically be linked to the (most) relevant Jira issue, per: https://confluence.atlassian.com/adminjiracloud/integrating-with-development-tools-776636216.html.
• This PR includes any required documentation changes, including README updates and changelog / release notes entries.
• All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
• All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
• Reviews are requested from both:
  • At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
  • Any relevant engineers on other projects (e.g. BFD, SLS, etc.).
• Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.
  • Please review the standards every few months to ensure you're familiar with them.

[ajshred]

Looks good Gretchen! Thank you!!!

[gmaciolek]

@ajshred do you have any thoughts on Rachel's comment?

From Rachel: "I think we need to add some language here about liability in terms of security issues. This should be language that is everywhere for the SDK."

She gave the following example text from AB2D: It is important to note that the AB2D team does not regularly maintain the sample clients. Additionally, a best-effort was made to ensure the clients are secure but they have not undergone comprehensive formal security testing. Each user/organization is responsible for conducting their own review and testing prior to implementation.

Is there some equivalent text we could add to a new security section for both SDK readmes?

[ajshred]

@ajshred do you have any thoughts on Rachel's comment?

From Rachel: "I think we need to add some language here about liability in terms of security issues. This should be language that is everywhere for the SDK."

She gave the following example text from AB2D: It is important to note that the AB2D team does not regularly maintain the sample clients. Additionally, a best-effort was made to ensure the clients are secure but they have not undergone comprehensive formal security testing. Each user/organization is responsible for conducting their own review and testing prior to implementation.

Is there some equivalent text we could add to a new security section for both SDK readmes?

Hmmm. We do test our sample apps and SDKs. We also monitor them for vulnerabilities. And we have strategies for updating them. I'm not sure this same thing applies with the SDKs. These are tools we are releasing and intend to support. Is she saying we should supply some statement that relieves us of that liability?

[dtisza1]

@gmaciolek I added the prerequisites section. Copied it from the Node SDK as is.

Still reviewing...

[dtisza1]

@gmaciolek I noticed some issues with some of the code block formatting.

I committed some fixes. I think they are all looking good.