科技爱好者周刊每周五整理值得分享的文章、软件和资源，开发者可用公开 GitHub Issue 推荐或自荐，让中文科技读者从当期正文进入原内容。
打开《科技爱好者周刊》第 404 期，你会看到科技动态、文章、工具、AI 项目和资源。工具条目通常只有几句中文介绍，随后给出官网或 GitHub 仓库。部分条目还会标注投稿人的 GitHub 账号，并链接到原投稿 Issue。读者从这段短介绍判断是否继续阅读、下载或试用。
仓库 README（在新标签页打开） 对周刊的公开说明很简短：记录每周值得分享的科技内容，每周五发布，欢迎通过 Issue 投稿文章、软件和资源。这里适合有公开原文、官网或仓库的内容。开源工具、可用软件、技术文章和实用资源都可以考虑。只提供候补名单、必须登录后才能看懂的页面，或主要依赖无法核验宣传数字的项目，应先把公开页面补完整。
Issue 负责送达，周刊正文才表示收录
ruanyf/weekly 的 Issues（在新标签页打开） 是公开投稿入口。创建 Issue 后，标题、正文、账号和链接都会公开。测试账号、私有下载地址、未公开价格和个人联系方式不应放进投稿。
Issue 带编号并出现在仓库列表，只能证明投稿已经送达。README 和公开仓库页面没有承诺固定审核时间、逐条回复或排入某一期。内容名称和链接出现在某期周刊正文后，才能确认已经收录。
open 和 closed 也不是录用结果。本次核验时，第 404 期（在新标签页打开） 引用了五条投稿 Issue，包括屏译、TurboOCR、light-ocr、Oh My HuggingFace 和 pi-auto-approval。这五条 Issue 当时都仍为 open。
因此，Issue 没关闭不代表尚未处理。遇到 closed 状态，也不要在没有回复说明时自行解释为拒稿。
先判断原内容是否经得起一句话介绍
第 404 期把屏译概括为“开源安卓应用，实时屏幕翻译工具”，把 Oh My HuggingFace 概括为“非官方的 Hugging Face 开源跨平台客户端”。投稿正文可以很长，进入周刊的介绍仍可能只有一两句。准备时先找出一个能由公开页面证明的具体用途，不必堆叠功能清单。
先写清谁会用、解决什么问题，再补一两个会影响选择的事实。例如，“在 Android 屏幕上识别外语文字并覆盖译文”比“新一代 AI 效率平台”更容易判断。若卖点是本地处理、无需注册、支持某个系统或采用开源协议，官网或仓库必须能找到相同说明。
README 没有排除商业软件，也没有公布更细的录用标准。本站建议按技术读者能否直接理解和使用来判断。只有销售口号、优惠活动或品牌新闻的页面，即使能够创建 Issue，也很难给周刊提供可核验的文章、软件或资源。
读者最终打开的是原链接
投稿前，用未登录窗口打开准备提交的原文、官网或仓库。检查首页、演示、下载和注册是否可用。开源项目还应核对 README、安装步骤、许可证和最小示例。文章应当直达完整正文，不要只给作者主页、社交媒体预告或需要申请权限的文档。
再到 Issues 搜索产品名、仓库名和域名，并搜索往期周刊。若同一内容已经有投稿，优先在原 Issue 补充版本变化或遗漏事实。无法编辑他人的投稿时，可以在原讨论中说明自己与项目的关系。改标题后重复创建 Issue 只会留下两份公开记录，不能证明内容更适合收录。
README 没有规定投稿格式
官方 README 只要求“提交 issue”，没有公布字符限制或固定字段。截至本次核验，公开仓库也没有专用的 Issue 模板目录。登录后的具体编辑界面仍以 GitHub 当时显示为准。
本站建议标题写清内容类型、名称和用途，例如 【开源自荐】项目名：在终端比较两个 JSON 文件。正文无需复制整份 README，可以准备：
- 官网、原文、在线演示或仓库的直接链接；
- 一句话用途，以及最可能需要它的人；
- 一到两个可以从原链接核验的特点；
- 支持平台、价格、登录要求、开源协议或主要依赖；
- 你是作者、开发者，还是推荐他人的内容。
这些是本站的写作建议，不是仓库公布的必填字段。截图也没有公开的必填要求。界面或输出结果确实有助于理解时，可以放一张当前版本的图片。性能、准确率、用户数量和排名应附公开来源与测试条件。无法证明的数据应从投稿中删除。
登录 GitHub，提交后检查公开页面
未登录时打开 新建 Issue 页面（在新标签页打开），GitHub 会跳转到登录页。登录后按照页面实际显示填写标题和正文，检查链接与图片，再提交 Issue。
看到带编号的公开 Issue，并能从仓库 Issues 列表找到它，说明投稿已经送达。如果页面仍停在登录页、编辑器或错误提示，不要连续点击或另建一条。先检查账号状态，以及内容是否已经成功提交。
提交后发现链接、价格或平台信息错误，可以编辑原 Issue。仓库没有公布催稿方式。没有新事实时，不要回复“顶一下”、反复留言催促或另建 Issue。
收录后维护周刊指向的页面
内容出现在周刊后，核对名称、简介和链接。第 404 期为五条投稿附上了 GitHub 账号和原 Issue 链接，但 README 没有保证每条收录内容都会采用这种署名形式。
接下来应维护周刊实际链接到的原页面。修正 README、安装步骤和下载地址。仓库迁移时保留旧地址跳转，文章改址时提供重定向，产品停止维护时也在原页面说明。往期周刊会继续留在仓库，失效链接会影响后来查阅的读者。
从最近一期到公开 Issue，再到正文收录，行动顺序如下：
- 阅读最近几期的文章、工具和资源栏目，确认自己的内容与周刊主题接近。
- 搜索现有 Issues 和往期正文，避免重复投稿。
- 检查公开链接，写出一句用途和一两个可以立即核验的事实。
- 登录 GitHub 创建 Issue，看到带编号的公开页面后停止重复提交。
- 入选后核对当期介绍，并持续维护原文、官网或仓库。