# Contribution Checklist ✅ ## Problem Map 3.0 Troubleshooting Atlas ## Minimum checklist for community fix contributions Quick links: - [Back to Templates Hub](./README.md) - [Back to Community Fix Lab](../community/README.md) - [Back to Official Fixes](../official/README.md) - [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md) - [Back to Atlas Hub](../../README.md) - [Open Fix Recipe Template](./fix-recipe-template.md) - [Open Prompt Template](./prompt-template.md) - [Open Colab Template](./colab-template.md) - [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt) --- Use this checklist before submitting any contribution to the community fixes layer. If the **Templates Hub** helps you choose the right template, this page helps you check whether the contribution is actually ready to submit 📌 The goal is simple: > make contributions easier to review, easier to reuse, and less likely to become chaos --- ## Quick start 🚀 Use this page in the following order: 1. scan the **Checklist quick map** 2. do the **30-second self-check** 3. fix any obvious gaps 4. run the full checklist section by section 5. make sure the **Minimum submit format** is complete before submission If you only do three things first, do these: 1. identify the main family 2. explain how to use the artifact 3. state the expected result That alone will prevent a lot of weak submissions. --- ## Checklist quick map 🗂️ | Section | What it checks | |---|---| | Basic contribution identity | naming, purpose, audience | | Atlas routing context | family fit, broken invariant, route-first discipline | | Contribution scope | one clear problem, not a vague dump | | Artifact clarity | what is included and how to use it | | Reproducibility | whether someone else can run or inspect it | | Repair logic quality | whether it supports a real first move | | Misrepair awareness | whether it warns against a tempting wrong move | | WFGY bridge discipline | whether deeper exploration stays in the right place | | File hygiene | filenames, placement, reviewability | | Writing quality | clarity, explanation, usability | | Honesty check | limits, incompleteness, non-overclaiming | | Minimum submit format | the minimum fields a reviewer should be able to find | --- ## 30-second self-check ⚡ If you are in a hurry, ask: 1. What family is this for? 2. What does this artifact actually do? 3. How do I run or use it? 4. What result should I expect? 5. What wrong first move does it help avoid? If you cannot answer these quickly, the contribution probably needs another pass. --- ## Minimum submit format 📦 Before submitting, make sure your contribution includes at least: - title - artifact type - primary family - broken invariant - short problem description - short usage instructions - expected output or outcome - one misrepair warning - limitations or notes If these are missing, the contribution is usually too hard to review. --- ## 1. Basic contribution identity - [ ] I gave the contribution a clear name. - [ ] I know which folder it belongs in. - [ ] I can explain in one sentence what this contribution does. - [ ] I can explain who this contribution is for. --- ## 2. Atlas routing context - [ ] I identified the main related family. - [ ] I identified a secondary family if it is genuinely relevant. - [ ] I can explain why this contribution belongs to that family region. - [ ] I did not skip routing and jump straight into implementation. Minimum expected routing context usually includes: - primary family - secondary family if relevant - broken invariant - best current fit or nearest fit --- ## 3. Contribution scope - [ ] This contribution solves one clear problem, not five vague ones. - [ ] The scope is small enough to review. - [ ] I did not dump unrelated files together. - [ ] I can explain what this contribution does not cover. Good scope examples: - one Colab demo - one JSON fixture pair - one prompt pack - one workflow repair recipe - one reproduction pack --- ## 4. Artifact clarity - [ ] I stated what artifact type this is. - [ ] I included the files needed to use it. - [ ] I gave short usage instructions. - [ ] I described the expected result. Common artifact types: - Colab notebook - JSON input / output fixture - prompt template - workflow recipe - benchmark rerun - reproduction pack --- ## 5. Reproducibility - [ ] I explained how to run or use this contribution. - [ ] I listed any required inputs, dependencies, or assumptions. - [ ] I stated what output or behavior should be expected. - [ ] I noted any parts that are partial, unstable, or still experimental. A contribution does not need to be perfect, but it should be honest. --- ## 6. Repair logic quality - [ ] I explained what first repair move this contribution supports. - [ ] I avoided pretending this is a universal solution. - [ ] I did not confuse deeper WFGY exploration with the official first repair move. - [ ] I can explain when this contribution should not be used. This is important because a useful fix asset should help people avoid wrong first moves, not just generate more output. --- ## 7. Misrepair awareness - [ ] I stated at least one common wrong first move to avoid. - [ ] I explained why that wrong move is tempting. - [ ] I kept the contribution aligned with route-first repair discipline. This helps community assets stay consistent with: - [Family Fix Surface v1](../official/family-fix-surface-v1.md) - [Misrepair Patterns v1](../official/misrepair-patterns-v1.md) --- ## 8. WFGY bridge discipline If the contribution uses WFGY 3.0 or a related deeper pack: - [ ] I explained what the atlas routing was first. - [ ] I explained what the first repair move was first. - [ ] I explained what the deeper WFGY step added. - [ ] I did not present deeper exploration as if routing were optional. Short version: - atlas first - first repair second - deeper WFGY exploration third --- ## 9. File hygiene - [ ] File names are readable. - [ ] The folder placement makes sense. - [ ] The files are not mixed with unrelated junk. - [ ] The contribution can be reviewed without guessing what is important. Please do not submit giant unstructured dumps. --- ## 10. Writing quality - [ ] The contribution is readable. - [ ] The important parts are easy to find. - [ ] I did not write only vague theory without use instructions. - [ ] I did not write only raw implementation without explanation. The best contributions are practical and legible. --- ## 11. Honesty check - [ ] I clearly marked any unstable or incomplete parts. - [ ] I did not exaggerate what this contribution proves. - [ ] I did not imply official status if this is still community work. - [ ] I did not claim universal applicability without evidence. This project grows better when contributors are strong and honest at the same time. --- ## 12. Maintainer review principles Passing this checklist does not guarantee merge. Maintainers may still check: - relevance - clarity - duplication - usefulness - routing accuracy - review cost - long-term maintainability This checklist is a minimum gate, not the final decision. --- ## Next steps ✨ After this page, most readers continue with: 1. [Open Fix Recipe Template](./fix-recipe-template.md) 2. [Open Prompt Template](./prompt-template.md) 3. [Back to Templates Hub](./README.md) 4. [Back to Community Fix Lab](../community/README.md) If you want to return to the broader product surface: - [Back to Official Fixes](../official/README.md) - [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md) - [Back to Atlas Hub](../../README.md) If this checklist helps your workflow, consider: - [starring the WFGY repo](https://github.com/onestardao/WFGY) - opening an issue - submitting one small clean contribution 🌱 --- ## One-line version **A good community contribution is small, clear, routed, usable, and honest about limits.** --- ## Closing note ✨ The goal of this checklist is not to slow contributors down. The goal is to help the fix ecosystem grow without turning into a pile of random files.