惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

U
Unit 42
T
The Blog of Author Tim Ferriss
H
Help Net Security
博客园 - 叶小钗
云风的 BLOG
云风的 BLOG
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
D
DataBreaches.Net
博客园 - 聂微东
A
About on SuperTechFans
大猫的无限游戏
大猫的无限游戏
P
Proofpoint News Feed
Martin Fowler
Martin Fowler
博客园 - 【当耐特】
S
SegmentFault 最新的问题
Blog — PlanetScale
Blog — PlanetScale
酷 壳 – CoolShell
酷 壳 – CoolShell
G
Google Developers Blog
I
InfoQ
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
GbyAI
GbyAI
B
Blog
Engineering at Meta
Engineering at Meta
V
V2EX
Hugging Face - Blog
Hugging Face - Blog

Hacker News - Newest: "AI"

AI can't read an investor deck AI as an attorney? Student uses ChatGPT, Gemini to sue UW over alleged racial discrimination Hacking MCP Servers in AI Systems – The Rug Pull: Tool Changes After Approval GitHub - MeepCastana/KubeezCut: Free Web based video editor Can AI judge journalism? A Thiel-backed startup says yes, even if it risks chilling whistleblowers Coming soon: 10 Things That Matter in AI Right Now DARPA built an AI to fact-check enemy weapons claims What explains heterogeneity in AI adoption? When AI Meets Muscle: Context-Aware Electrical Stimulation Promises a New Way to Guide Human Movements - Department of Computer Science AI Changed How We Build. It Did Not Change What Matters. Linux rules on using AI-generated code - Copilot is OK, but humans must take 'full responsibility for the… Meta spins up AI version of Mark Zuckerberg to engage with employees Code Mode: Let Your AI Write Programs, Not Just Call Tools | TanStack Blog GitHub - Delavalom/graft: Go framework for building AI agents. Type-safe tools, multi-provider (OpenAI, Anthropic, Gemini, Bedrock), zero vendor SDKs. India's TCS tops estimates, says new AI models did not dent services demand Gen Z's fading AI hype Strong feeling: we are in a folded AI reality GitHub - machinarii/total-recall-catalog: A reference catalog of latest knowledge retrieval, memory & RAG systems GitHub - mensfeld/code-on-incus: Give each AI agent its own isolated machine with root, Docker, and systemd. Active defense detects and stops threats automatically.. Quantization, LoRA, and the 8% Problem: Benchmarking Local LLMs for Production AI Iran war: We spoke to the man making Lego-style AI videos that experts say are powerful propaganda Powell, Bessent discussed Anthropic's Mythos AI cyber threat with major U.S. banks GitHub - immartian/bellamem: Persistent belief-graph memory for AI agents. Retrieves decisive context by importance — not recency, not RAG, not /compact. recursive-mode: The Repo-Native Operating System for AI Engineering After the attack on Sam Altman's home, will AI CEO's go on the offensive? The biggest advance in AI since the LLM Opus 4.6 vs GPT 5.4 One Prompt Unity World Generation Test “AI polls” are fake polls Client Challenge Can AI be a 'child of God'? Inside Anthropic's meeting with Christian leaders
GitHub - omkar-foss/noslop-oss: A checklist of no-slop co...
omkar-foss · 2026-06-27 · via Hacker News - Newest: "AI"

A checklist of no-slop contribution best practices when using AI (or not) in open source projects.

These days there are so many AI-generated repos and PRs without clear ownership, often referred to as "AI slop". AI use is a reason for the slop, but some cases it's not the only reason. Many new, genuine (human) contributors are simply unfamiliar with open source workflows and project expectations, and AI tools can sometimes amplify those gaps. It results in their contributions getting lost among the noise and getting ignored by maintainers.

This checklist focuses on best practices that help contributors build trust and submit high-quality contributions, whether they use AI or not. It's a checklist for becoming the kind of contributor maintainers enjoy reviewing!

Index

  • Checklist
    • 0. Contribute with purpose
    • 1. Understand the project well
    • 2. Engage with the project community
    • 3. Set up your project environment thoroughly
    • 4. Understand the project's AI policies
    • 5. Use AI as your tool, not as your replacement
    • 6. Test, validate and document
    • 7. Choose the right issue
    • 8. Starting to work on an issue
    • 9. Communicate early and often
    • 10. Submitting your contribution
    • 11. Follow up
    • 12. What NOT to Do
  • Note to project maintainers
  • Contributing
  • Recommended articles & guides
  • Closing thoughts
  • LICENSE
  • AI Disclosure

Checklist

Follow these guidelines to become a high quality, no-slop OSS contributor! 🌟

☐ 0. Contribute with purpose

  • Contribute with the goal of creating value for the project, whether you're learning, solving a problem, or giving back to the community.
  • Focus on making meaningful contributions rather than optimizing for visibility or metrics.
  • Compete with your own progress, not with others. Choose collaboration over competition.

☐ 1. Understand the project well

  • Read the project's readme, contributing, and code of conduct files.
  • Study the project's goals, architecture, and tech stack.
  • Explore existing issues, discussions, and pull requests to grasp community priorities.
  • Read recent pull requests to understand the project's coding style, review expectations, and current development priorities.
  • Check for project-specific guidelines (e.g., design docs, roadmaps, or architecture decisions).

☐ 2. Engage with the project community

  • If appropriate for the project's community, introduce yourself in its public communication channels (Slack, Discord, mailing lists, etc).

    Example: Hi! I'm [Name], and I'd like to contribute to [Project]. I'm particularly interested in [specific area].

  • Ask relevant questions in public forums, and not privately to avoid duplicating discussions.
    • Before asking a question, spend a few minutes searching existing issues, discussions, and documentation.
  • Read first, contribute later i.e. observe community discussions before jumping in.
  • Follow the project's communication norms (e.g., response times, tone, meeting schedules).

☐ 3. Set up your project environment thoroughly

  • Fork the repository and clone it locally.
  • Set up the development environment exactly as documented in the project.
  • Install dependencies and verify the project runs locally.
  • Set up pre-commit hooks, linters, or formatters if recommended.

☐ 4. Understand the project's AI policies

  • Check if the project has AI contribution policies (e.g. AI disclosure requirements).
  • If the project doesn't mention AI usage, avoid assuming it's acceptable. Consider asking maintainers if disclosure or other expectations aren't clear.
  • Preferably disclose AI usage in your PR/issue irrespective of whether the project's AI policy demands it.

☐ 5. Use AI as your tool, not as your replacement

  • Use AI to:
    • Brainstorm ideas or generate draft code snippets.
    • Automate repetitive tasks (e.g., formatting, testing scaffolding).
    • Document complex processes (e.g., setup instructions, troubleshooting).
  • Never submit AI-generated code without:
    • Reviewing it line-by-line.
    • Testing it thoroughly.
    • Modifying it to fit the project's style.
  • Make sure you can explain every change you submit, whether it was written by you or assisted by AI.

☐ 6. Test, validate and document

  • Run the project's test suite and ensure no errors.
  • Write new tests for your changes.
  • Manually verify your changes work as intended.
  • If using AI-generated tests, review them carefully for edge cases.
  • Update documentation, examples, or changelog entries if your changes affect users.

☐ 7. Choose the right issue

  • Start small with:
    • Bug fixes.
    • Documentation improvements.
    • Test additions.
    • Small feature implementations (labeled "good first issue").
  • Avoid large or ambiguous changes until you're deeply familiar with the project.
  • Check for "help wanted" or "needs review" labels in the issue tracker.

☐ 8. Starting to work on an issue

  • Before raising a PR for an issue, check if there's one or more existing PRs for it. In case of existing PRs:
    • If any of those PRs are actively being updated, don't pick the issue as it could lead to duplicate effort. Find another issue to work on.
    • If all those PRs are inactive, then you could pick up the issue after confirming with maintainers.
  • Comment on the issue and confirm with the maintainers before starting work to avoid duplication.

Example: "I'd like to work on this. May I pick this up? I plan to implement it like this: [your brief plan]."

☐ 9. Communicate early and often

  • For larger changes, ask for feedback on your proposed approach before opening a PR.
  • Be prepared for your proposed solution to be declined. Not every good idea aligns with a project's roadmap.
  • Document your thought process in the issue/PR.
  • Be responsive to feedback and iterate.

☐ 10. Submitting your contribution

  • If the project has a pull request template, follow it thoroughly.
  • Keep your pull request focused on a single logical change whenever possible.
  • Create a new branch for your changes (e.g., fix/issue-123).
  • Write clear, descriptive commit messages.
    • Follow the project's conventions (e.g., Fix #123: [description]).
    • If you used AI tools and if project encourages commit-level AI disclosure, use the project's preferred format (e.g. Assisted-by or Co-authored-by).
    • If project recommends DCO sign-off, provide one in your commits using Signed-off-by.

Example DCO sign-off along with AI disclosure with Assisted-By in commit:

Improve error handling in user authentication module

- Added custom error classes for authentication failures
- Implemented retry logic for transient failures
- Updated tests to cover new error scenarios

Assisted-by: GitHub Copilot (for new error scenario tests)
Signed-off-by: Your Name <youremail@address.here>
  • Include references to relevant issues in your PR description.
  • In the PR description:
    • Disclose AI usage (e.g., "This PR includes AI-assisted code generation for [specific part]").
    • Explain your process and reasoning.
    • Link to any related discussions or issues.

☐ 11. Follow up

  • Monitor your PR for feedback and be ready to make changes.
  • Give the reviewers time to respond, avoid repeatedly asking for updates (e.g. every few hours).
  • Thank reviewers for their time and feedback.
  • If your PR is closed, ask for feedback on how to improve, so you can learn from your mistakes.
  • Celebrate your contribution, appreciate any help you received from other community members; open source is a community effort!

☐ 12. What NOT to do

  • Do not submit AI-generated code without reviewing, understanding, and testing it.
  • Do not ignore community guidelines or communication norms.
  • Do not submit large changes without prior discussion and approval.
  • Do not spam the issue tracker or PR queue with low-quality contributions.
  • Do not rely on AI in place of understanding the codebase or engaging with the community.

Note to project maintainers

Projects are welcome to adopt this checklist as NOSLOP.md, incorporate parts of it into CONTRIBUTING.md, or simply share this repository with contributors.

Contributing

Feel free to raise a PR in case you'd like to add something. Refer to the checklist above for contribution guidelines. All contributions should abide by this code of conduct.

Recommended articles & guides

Closing thoughts

Open source succeeds through people as much as code. Building trust, communicating clearly, and collaborating well are just as important as writing software.

License

CC0 Public domain. This work is free of known copyright restrictions.

AI Disclosure

This checklist has been reviewed with assistance from ChatGPT to improve tone and grammar consistency. All suggestions were manually reviewed before being incorporated.