[Good First Issue]: document Hall of Fame auto-credit behavior in CONTRIBUTING.md

[ambicuity]

---

Welcome to New Grad Jobs! 🎓

This template creates a Good First Issue — a small, guided task that helps new
contributors learn the codebase and contribution workflow.

Good First Issues are pre-approved by the maintainer. A contributor can claim it
immediately by commenting /assign.

---

🆕 Newcomer Friendly

This is a Good First Issue — a guided, well-scoped task designed for contributors
who are new to this repository.

What you'll do

• ✅ Read a small part of the codebase
• ✅ Make a focused, well-defined change
• ✅ Write or extend a test
• ✅ Submit and merge a pull request

Support

The maintainer actively monitors Good First Issues and will respond to questions
within 24–48 hours.

Important

This issue does not require prior scraping or API experience.

• Basic Python and Git are sufficient
• You must be assigned before starting — comment /assign to claim this issue
• Read CONTRIBUTING.md
  before opening a PR

Note

⏱️ Typical time to complete: 30–90 minutes (once local setup is done)
🧩 Difficulty: Small, well-contained change
🎓 Best for: First-time contributors

🏁 When this issue is complete, you will have:

• ✅ A merged PR in a real open-source project
• ✅ Your name in the Contributors Hall of Fame
• ✅ Confidence to take on larger issues next

Important

📋 What makes a Good First Issue in this repo?

Often a good fit:

• Adding a missing company to config.yml (Greenhouse, Lever endpoint)
• Fixing a keyword in categorize_job() or get_company_tier()
• Correcting a typo or broken link in documentation
• Adding a test case for an existing, already-working function
• Small CSS/HTML improvements to docs/

Not a good fit for GFI:

• Changes to filter_jobs(), deduplicate_jobs(), or date parsing
• New scraping source integrations (Workday, Google Careers)
• Architectural changes to update_jobs.py

Those belong in Beginner, Intermediate, or Advanced issues.

👾 Task Description

Contributor docs currently conflict with workflow behavior for Hall of Fame credit:

• CONTRIBUTING.md says maintainers will add contributors manually
• .github/workflows/auto-thank.yml attempts automatic credit on merged PRs

This causes confusion when contributors expect immediate credit or when automation skips a case.

Please add a short, clear section in CONTRIBUTING.md that explains:

1. Which workflow handles contributor credit (auto-thank.yml)
2. When it triggers (PR is merged)
3. Common skip conditions (for example bot authors)
4. What to do if credit did not appear (open a comment / maintainer follow-up)

Keep this concise and contributor-friendly.

Area touched:

• CONTRIBUTING.md
• (Reference only) .github/workflows/auto-thank.yml

✅ Acceptance Criteria

• CONTRIBUTING.md includes a clear "Hall of Fame credit" section aligned with current workflow behavior
• New section references .github/workflows/auto-thank.yml as the source of truth
• Instructions include a simple troubleshooting path if auto-credit does not run
• Existing docs still pass repository checks (pre-commit/markdown checks if configured)
• PR is linked to this issue with Fixes #<number>
• PR title follows Conventional Commits format