文档教程【免费下载链接】awesome-roadmapsA curated list of roadmaps.项目地址https://gitcode.com/gh_mirrors/aw/awesome-roadmaps点击查看免费下载本文以仓库根目录的 contributing.md 为绝对准则完整解析 awesome-roadmaps 精选路线图列表的贡献流程与条目格式规范。读完你将掌握编辑 README.md → 提交 Pull Request的完整链路以及排序、命名、描述等八条硬性规则的判定标准并可直接对照仓库中的真实条目检查自己的提交是否合规。项目背景与贡献入口awesome-roadmaps 是一个精选路线图列表curated listREADME.md 本身就是产品它以十个分类收纳了软件开发各领域的高质量路线图资源——Programming Language、Web Development、Mobile Development、Infrastructure / Operations、Game Development、AI / Machine Learning / Data Science、Security、Miscellaneous、Tools Resources、Articles Books每个分类下列出若干条目每条由项目名称链接 一句话描述 徽章组成。README 在开头明确写道Contributions welcome. Add links through pull requests or create an issue to start a discussion.欢迎贡献通过 Pull Request 添加链接或创建 Issue 开启讨论。也就是说contributing.md 覆盖两条贡献入口直接编辑 README.md 并提交 Pull Request新增、删除、修改条目的主路径先创建 Issue 发起讨论确认需求合理后再落地修改。而 contributing.md 中列出的八条规则就是无论走哪条入口都必须遵守的格式契约。下面逐条拆解。核心流程一切修改都发生在 README.md贡献指南的第一条即定义了修改方式To add, remove, change:Edit theREADME.mdand then submit a pull request.新增、删除或修改编辑 README.md然后提交 Pull Request。这决定了整个仓库的协作模型README.md 是唯一的数据源contributing.md 是校验规则二者共同构成列表的维护机制。从仓库结构看除 README.md、contributing.md、LICENSE 和 assets/logo.svg 外没有其他内容文件因此贡献 改 README 文本就是全部工作。一次合规提交的完整链路可以概括为定位分类判断新资源属于 README 中哪个分类区块如语言类进 Programming Language运维类进 Infrastructure / Operations插入条目按下一节格式在对应分类的合适位置写入一行条目保持排序确保该分类仍按字母序排列规则二自查八条规则逐条核对本文提交前自检清单提交 PR描述改动动机等待维护者审阅合并。条目格式解剖一个条目 链接 描述 徽章contributing.md 对每个条目规定了严格的 Markdown 结构以仓库中真实的Node.js Developer Roadmap条目为例README.md- Node.js Developer Roadmap - Node.js developer roadmap covering fundamentals, tooling, and backend concepts.整个条目由四个要素组成组成要素规则来源说明-列表符号格式惯例每个条目是 README 无序列表中的一行项目名规则三、四每条目只有一个链接链接文本必须是项目名称-分隔符规则五链接与描述之间用空格-短横线-空格分隔描述文本规则六、七大写开头、句号结尾、清晰简洁、非推广需要特别说明的是徽章badge不属于贡献指南强制要求的内容它是当前仓库维护者追加的展示格式。README 对徽章语义有明确交代Year badges reflect the latest year explicitly shown by the upstream resource when available. Type badges indicate the current resource type or status.Year 徽章反映上游资源明确展示的最新年份Type 徽章标识资源类型或状态。新条目建议参考现有条目补充对应徽章但从贡献规则的角度看链接与描述格式才是合规模板的核心。八条规则详解与仓库实例对照规则一分类内条目按字母序排列Items of category should be sortedalphabetically.分类内的条目应按字母序排序。排序是维持列表可扫读性的关键。对照仓库实例验证README.mdProgramming Language 分类C Developer Roadmap→Go Developer Roadmap→Java Developer Roadmap→Node.js Developer Roadmap→PHP Developer Roadmap→Rust Web Developer Roadmap首字母严格按 C、G、J、N、P、R 升序Web Development 分类Angular Developer Roadmap→Angular Developer Roadmap (Alternative)→ASP.NET Core Developer Roadmap→Developer Roadmap→DevRoadmaps→ …… →Vue Developer Roadmap同名项目主条目在前、Alternative 变体在后Miscellaneous 分类从Awesome Quality Assurance Roadmap到University Degree Roadmap同样严格有序。实操建议插入新条目后可以借助sort等命令行工具对该分类的行做一次排序比对确认无错序。注意比较的是**链接文本项目显示名**的字母顺序而非描述文字。规则二每条目只保留一个链接Each item should be limited to one link.每个条目仅限一个链接。观察所有现有条目可以确认一行内只有一处 Markdown 链接项目名描述中不嵌入第二个链接。这样既保证列表整洁也避免同一条目指向多个跳转目标造成歧义。如果你想同时提供网站版与仓库版两个入口正确做法是遵循仓库惯例——如Platform Engineering Roadmap条目那样以徽章Format-Website/GitHub repo而非第二个超链接来标注附加形态。规则三链接文本必须使用项目名称The link should be the name of the project.链接应为项目的名称。链接文本要与所指向项目在社区中的正式名称完全一致。例如 Web Development 分类中的Developer Roadmap链接文本就是该项目自身的名字而不是点击这里查看更多之类的描述性短语。这条规则与规则七命名一致且正确共同保证了条目在视觉上即所见即所指。规则四链接与描述之间用短横线分隔The link and description are separated by a dash.链接与描述以短横线分隔。标准写法是- 项目名 - 描述短横线前后各有一个空格。这是条目格式的硬性视觉约定分隔符缺失或多余都会破坏 README 中所有条目的对齐一致性。规则五描述以大写字母开头、以句号结尾The description starts with an uppercase character and ends with a period.描述以大写字符开头以句号结尾。对照真实条目README.mdJava developer roadmap with a current visual learning plan and practice topics.—— 以大写 J 开头、以句号结尾Free developer career roadmaps with 17 paths, 800 topics, and 1700 curated resources. PWA with offline support.—— 首字母大写、句号收尾且允许用句号分隔的两句话组成描述。这条规则是可机器校验的典型首字符应为大写字母A-Z末尾字符必须是英文句号.而不是冒号、省略号或无标点。规则六描述要清晰、简洁、非推广The description should be clear, concise, and non-promotional.描述应清晰、简洁且无推广性质。从现有条目可以总结出三条判别经验说清是什么C learning roadmap with articles, visual maps, and supporting resources.直接交代内容形态路线图、配套文章与可视地图不空谈价值控制长度大多数描述控制在 1025 个单词内一行内完整呈现避免溢出到多行禁用推广词现有条目中看不到 best#1most popular必学 等营销式表达描述始终陈述事实而非推销项目。规则七命名一致且正确Consistent and correct naming. For example,Node.js, notNodeJSornode.js.命名一致且正确。例如Node.js而非NodeJS或node.js。这是最容易在提交时翻车的细节。贡献指南专门给出反例Node.js是规范写法NodeJS缩写不完整、node.js小写开头都不合格。仓库中的同类实例还包括ASP.NET CoreREADME.md、Vue.js、C、PHP等——都保持了官方的大小写与符号形态。判断标准很简单以项目官方文档/仓库的规范写法为准链接文本、描述中的名称应与之一致。提交前的自检清单把 contributing.md 的八条规则固化成一份可逐项勾选的清单提交 PR 前过一遍改动是否仅发生在 README.md新增 / 删除 / 修改都改这里所在分类是否仍按字母序排列该条目是否只包含一个链接链接文本是否为项目名称链接与描述之间是否为-空格短横线空格分隔描述是否以大写字母开头、以句号结尾描述是否清晰、简洁、无推广词项目命名如Node.js、ASP.NET Core是否与官方写法一致任何一项不满足都会增加 PR 被要求修改request changes的概率。徽章格式速览可选但建议补充虽然不是 contributing.md 的强制项但当前 README 的所有条目都附带徽章了解其语法有助于新条目与现有风格统一。典型写法来自 README.md 的真实条目- Example Roadmap - Example roadmap covering fundamentals and tooling. img altYear 2026 src徽章图片地址 altYear 2026 img altGitHub repo src徽章图片地址徽章语义按 README 的说明理解即可Year 徽章仅在上游资源明确展示年份时添加因此部分条目如Android Developer Roadmap (Alternative)没有 Year 徽章Type/Status 徽章标识资源形态如Format-Course、Format-Book、Format-Website、Status-Archived。若上游项目不标注年份不要自行杜撰年份徽章。常见问题新增一个现有分类之外的路线图怎么办从 README 结构看Contents 目录与正文分类区块一一对应。若要新增分类需同时在 Contents 目录与正文中新增对应区块并保持新增区块的位置与现有分类的字母序一致更稳妥的做法是先创建 Issue 与维护者确认分类归属。只是想修改已有条目的描述或年份徽章流程一样吗一样。任何add / remove / change都走编辑 README.md 提交 PR的流程改多改少规则不变。描述必须用英文吗contributing.md 未强制规定语言但仓库现有条目含 Articles Books 分类的描述统一使用英文建议沿用这一惯例以保持列表一致性。提交前想先讨论可以直接创建 Issue 说明意图README 也明确欢迎这种方式create an issue to start a discussion讨论定稿后再改 README 提交 PR能减少往返成本。小结awesome-roadmaps 的贡献门槛不高但约束明确改 README、按字母序、单链接、项目名作链接文本、短横线分隔、大写开头句号结尾、描述非推广、命名规范——八条规则共同保证了这份精选列表在持续扩充时仍保持可扫读、可检索、可机器校验的质量基线。下次你发现一条值得收录的软件开发路线图时对照本文的自检清单改一行 README 提交 PR 即可。赞分享文档教程【免费下载链接】awesome-roadmapsA curated list of roadmaps.项目地址https://gitcode.com/gh_mirrors/aw/awesome-roadmaps点击查看免费下载相关推荐如何为Awesome Roadmaps贡献高质量的路线图完整贡献指南如何为Awesome Roadmaps贡献高质量的路线图完整贡献指南 Awesome Roadmaps是一个精心策划的路线图资源集合专注于为开发者和学文档教程awesomo 贡献指南如何为「按语言分类的开源项目精选列表」提交高质量条目awesomo 贡献指南如何为「按语言分类的开源项目精选列表」提交高质量条目 awesomo 是一个面向开源社区的项目精选仓库它按编程语言将「有趣、活跃、值文档awesome-shodan-queries 贡献指南如何为 Shodan 搜索查询列表提交高质量条目awesome shodan queries 贡献指南如何为 Shodan 搜索查询列表提交高质量条目 本文是 awesome shodan queries网络安全教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考