docs: Extend CONTRIBUTING.md with code guidelines

[jlaportebot]

Extends CONTRIBUTING.md with comprehensive code guidelines for contributors, including:

• Code style and formatting standards
• Testing requirements and patterns
• Documentation expectations
• Commit message conventions
• Code review guidelines

Addresses feedback from maintainers on the initial submission.

[jlaportebot]

CLA Fix Summary

Closed PR #4299 (and #4202) due to CLA check failures caused by:

1. 2867 commits in the PR history — git filter-branch accidentally rewrote the entire repo history instead of just the PR branch
2. Mixed email addresses — Author was jlaportebot@users.noreply.github.com but Committer was jlaportebot@gmail.com (CLA only signed for the noreply email)
3. Invalid Co-authored-by trailer in original commit: Co-authored-by: review feedback from google/go-github maintainers (missing email in angle brackets)

What I did to fix:

• Reset branch to upstream/master (clean base)
• Cherry-picked the CONTRIBUTING.md changes as a single commit
• Set both Author and Committer to jlaportebot@users.noreply.github.com (the email with signed Google CLA)
• Removed the problematic Co-authored-by trailer

Result: PR #4339 now has 1 commit with clean CLA verification ✅

The CONTRIBUTING.md content is identical to what was in #4299 — all reviewer feedback incorporated (alexandear, stevehipwell, gmlewis). Ready for review!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.50%. Comparing base (4b55679) to head (ed1e6bf).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4339   +/-   ##
=======================================
  Coverage   97.50%   97.50%           
=======================================
  Files         193      193           
  Lines       19451    19451           
=======================================
  Hits        18965    18965           
  Misses        269      269           
  Partials      217      217           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gmlewis]

One nit, otherwise LGTM.

[gmlewis]

In my opinion, these changes to the code sections are a regression and the new formatting looks worse than the original. I think that the changes to the new lines 174-185 should be reverted.

[jlaportebot]

I've addressed the nit from the review - reverted the code formatting changes in the Code Comments examples to match the original style with tabs and // ... comments. The review was on the previous commit (130d1aa) and this is now on the new commit (ed1e6bf). The CLA check passes and all checks are green. Ready for re-review!

[gmlewis]

Thank you, @jlaportebot!
LGTM.

cc: @stevehipwell - @alexandear - @Not-Dhananjay-Mishra

[stevehipwell]

LGTM

I do still think that using the Repository struct in the example for a response object is unclear as it's two most significant fields (ID & Name) are pointers when they are required and by the coding standards logic should not be.

[gmlewis]

I do still think that using the Repository struct in the example for a response object is unclear as it's two most significant fields (ID & Name) are pointers when they are required and by the coding standards logic should not be.

This is an orthogonal issue. I believe it was originally done this way because, depending upon the endpoint where either *Repository or []*Repository was being returned, they were emperically found to not be populated by the GitHub server, and therefore were made pointers so that the client could more easily figure out if the JSON response actually included these fields.

Feel free to file a separate issue so that someone can investigate if this is no longer the case in any of the DotCom or current or legacy Enterprise versions of GitHub so that they can be changed.

[stevehipwell]

This is an orthogonal issue. I believe it was originally done this way because, depending upon the endpoint where either *Repository or []*Repository was being returned, they were emperically found to not be populated by the GitHub server, and therefore were made pointers so that the client could more easily figure out if the JSON response actually included these fields.

Feel free to file a separate issue so that someone can investigate if this is no longer the case in any of the DotCom or current or legacy Enterprise versions of GitHub so that they can be changed.

@gmlewis I was very careful not to say that the Repository implementation wasn't correct, just that it made the example confusing compared to uisng a type where the identity fields weren't pointers.