Conversation
WalkthroughAdds community and contribution documentation plus GitHub issue/PR templates. Introduces CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md, two issue templates, and a PR template. README.md gains a Contributing section with links and a commands placeholder. No code or API changes. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (13)
README.md (1)
40-44: Good additions; tighten phrasing and make links resilient.
- Consider absolute repo-root links to avoid breakage when README is viewed outside GitHub (e.g., pkg.go.dev). Also add a short “Questions?” pointer.
-### Contributing -- See [CONTRIBUTING.md](./CONTRIBUTING.md) -- Please follow our [Code of Conduct](./CODE_OF_CONDUCT.md) -- Security issues: see [SECURITY.md](./SECURITY.md) +### Contributing +- See [CONTRIBUTING.md](/CONTRIBUTING.md) +- Please follow our [Code of Conduct](/CODE_OF_CONDUCT.md) +- Security issues: see [SECURITY.md](/SECURITY.md) +- Questions or ideas? Open a [discussion](https://github.com/zhravan/golearn/discussions) or [issue](https://github.com/zhravan/golearn/issues).If Discussions aren’t enabled, drop that bullet, or I can adjust the wording.
.github/ISSUE_TEMPLATE/bug_report.md (2)
24-29: Ask for exact versions with a copy-pastable command.Add a field for the CLI version and suggest how to capture it.
### Environment - -- OS: -- Go version: -- GoLearn version: + - OS: + - Go version: + - GoLearn version (output of `golearn --version`):Please confirm the binary prints a version with
golearn --version(orversion). If it uses a different flag, I’ll update the template accordingly.
13-19: Prompt for minimal, reproducible steps.Small tweak to nudge high-signal repros and attach logs.
-### To Reproduce - -Steps to reproduce the behavior: - -1. Command(s) run -2. Output +### To Reproduce +Provide minimal steps and exact commands: +1. Commands run +2. Expected vs actual output +3. Relevant logs (use `--verbose` if available) and redacted configIf the CLI supports a
--verbose/--debugflag, we can reference it explicitly.SECURITY.md (2)
8-13: Unify and harden the reporting channel.Security contact here (
security@example.com) differs from the Code of Conduct address. Use a single, monitored alias and mention GitHub Security Advisories. Add timeline expectations.-## Reporting a vulnerability -- Email: security@example.com -- Please include steps to reproduce and any PoC code if available -- Do not open public issues for security problems +## Reporting a vulnerability +- Email: <mrshravankumarb@gmail.com> <!-- or a project alias like security@your-domain --> +- You may also use GitHub Security Advisories (Private report) on this repo. +- Include steps to reproduce and any PoC code if available. +- Do not open public issues for security problems. + +Timeline: we acknowledge within 72 hours, provide an initial assessment within 7 days, and coordinate a fix and disclosure window (typically 30–90 days).If you have or plan a project alias (e.g., security@…), I can update both SECURITY.md and CODE_OF_CONDUCT.md to match.
5-7: Clarify support window.“Latest minor release” can be ambiguous. Consider a small table or SemVer note.
## Supported versions -We generally support the latest minor release of the CLI. +We generally support the latest minor release (SemVer) of the CLI. + +Examples: +- 1.6.x: supported +- 1.5.x and earlier: unsupported.github/PULL_REQUEST_TEMPLATE.md (2)
5-10: Add breaking-change and security-impact prompts.These two prompts reduce surprises post-merge.
## Checklist - - [ ] Tests pass: `make verify` or `golearn verify <slug>` - [ ] Docs updated (README/CONTRIBUTING) if needed - [ ] No large new dependencies + - [ ] Breaking changes documented (flags, config, output) + - [ ] Security impact considered (auth, secrets, file paths)
15-17: Encourage precise linking to issues.Nudge authors to use auto-closing syntax and multiple references.
-## Related issues - -Fixes # +## Related issues +Fixes #<id> <!-- or closes/resolves --> +Related: #<id>, #<id>.github/ISSUE_TEMPLATE/feature_request.md (1)
9-23: Capture acceptance criteria and scope.Adds success criteria and out-of-scope to align expectations.
### Proposal - Describe the solution you'd like. ### Alternatives - Describe alternatives you've considered. +### Acceptance criteria +How we’ll know this is done (clear, testable). + +### Out of scope +Anything explicitly not included. + ### Additional context - Add any other context or screenshots.CODE_OF_CONDUCT.md (1)
21-27: Use a project alias and add scope/enforcement guidelines snippets.Personal inboxes don’t scale; also consider Contributor Covenant 2.1 “Enforcement Guidelines” section.
-Report unacceptable behavior to the maintainers at: <mrshravankumarb@gmail.com>. +Report unacceptable behavior to: <conduct@your-domain> (or the primary project contact). + +## Scope +This Code of Conduct applies within all project spaces and when an individual is officially representing the project. + +## Enforcement Guidelines +Community leaders will follow a reasonable, documented process for determining consequences for any action they deem in violation of this Code of Conduct (see Contributor Covenant v2.1 for examples).If you prefer to keep a single contact for both CoC and security, say so and I’ll align both files.
CONTRIBUTING.md (4)
14-28: Addgo toolchainnote and a tip for local paths.Small tweaks to reduce friction for new contributors.
## Development setup @@ -# Build the CLI -make build # or: go build ./cmd/golearn +# Build the CLI (Go 1.22+; optionally pin with `go toolchain use go1.22.x`) +make build # or: go build ./cmd/golearn @@ -# Initialize embedded exercises into a workspace +# Initialize embedded exercises into a workspace mkdir -p /tmp/golearn-ws && cd /tmp/golearn-ws -/path/to/bin/golearn init +~/path/to/golearn/bin/golearn init # adjust path per your setup
39-45: Suggest adding lint/static analysis guidance (lightweight).Keeps the binary lean while catching bugs early.
## Code style @@ -- Match existing formatting; run `gofmt` and `go vet` +- Match existing formatting; run `gofmt` and `go vet` +- Optionally run `staticcheck` or `golangci-lint` locally before PRs
48-52: Encourage conventional commit messages.Improves changelog generation and searchability.
1. Create a feature branch -2. Make focused commits with descriptive messages +2. Make focused commits with descriptive messages (e.g., Conventional Commits) 3. Ensure `make build` and `make verify` pass 4. Open a PR with a clear title and description (screenshots welcome)
55-59: Call out schema/validation for catalog.yaml (if available).If you have a validator, reference it; otherwise ignore.
- Provide hints in `internal/exercises/catalog.yaml` + - Validate `catalog.yaml` format before committing (add a `make catalog-validate` target if helpful)I can add a lightweight
make catalog-validatetarget if there’s a schema/tool you prefer.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
.github/ISSUE_TEMPLATE/bug_report.md(1 hunks).github/ISSUE_TEMPLATE/feature_request.md(1 hunks).github/PULL_REQUEST_TEMPLATE.md(1 hunks)CODE_OF_CONDUCT.md(1 hunks)CONTRIBUTING.md(1 hunks)README.md(1 hunks)SECURITY.md(1 hunks)
🔇 Additional comments (2)
CONTRIBUTING.md (2)
66-69: Nice touch including solution verification.This is clear and actionable.
32-37: Makefile 'build' and 'verify' targets exist and match CONTRIBUTING.md.
No changes required.
1 participant
Summary by CodeRabbit
New Features
Documentation
Chores
Tests
Bug Fixes