|
| 1 | +# NotionNext 愿景与路线图 |
| 2 | + |
| 3 | +NotionNext 的长期目标,不是把 Notion 简单包装成另一个博客模板,而是让它成为一个稳定、可演进、可由社区共同维护的内容发布系统。 |
| 4 | + |
| 5 | +Notion 负责内容生产、资料整理和团队协作;NotionNext 负责公开访问、主题展示、SEO、部署、性能和长期运营。两者连接得越自然,站长需要手工维护的地方就越少,内容也越容易持续沉淀。 |
| 6 | + |
| 7 | +## 5.0 方向 |
| 8 | + |
| 9 | +5.0 不应只是“多几个功能”的版本。它更应该回答一个问题:一个普通站长如何在不被 Git、部署平台和 Notion 数据结构反复打断的情况下,长期维护自己的站点? |
| 10 | + |
| 11 | +围绕这个目标,后续路线会优先关注这些方向。 |
| 12 | + |
| 13 | +### 1. 降低使用门槛 |
| 14 | + |
| 15 | +NotionNext 仍然是开源项目,但部署、升级、排错不能只服务熟悉工程流程的人。未来需要继续减少这些摩擦: |
| 16 | + |
| 17 | +- 更清楚的升级路径,降低分支、Fork、Pull Request 带来的理解成本。 |
| 18 | +- 更稳定的构建和缓存策略,减少“代码已经更新但网站仍是旧状态”的困惑。 |
| 19 | +- 更友好的错误提示和自检工具,让站长能先判断是配置问题、缓存问题还是代码问题。 |
| 20 | +- 更完整的文档,把常见真实场景沉淀成可复用的排查步骤。 |
| 21 | + |
| 22 | +### 2. 更完整地承接 Notion 数据库能力 |
| 23 | + |
| 24 | +Notion 的数据库、视图、筛选和排序是许多站长真正依赖的能力。NotionNext 应尽量理解这些结构,而不是要求用户额外维护大量重复标签。 |
| 25 | + |
| 26 | +近期已经开始补齐嵌入数据库视图筛选等兼容问题。长期可以继续推进: |
| 27 | + |
| 28 | +- 更稳定地读取 Notion 数据库视图筛选、排序和分组结果。 |
| 29 | +- 支持更多 Notion 属性类型和多条件组合。 |
| 30 | +- 降低“为了网站展示而重复造标签”的人工维护成本。 |
| 31 | +- 明确哪些 Notion 行为可以可靠支持,哪些需要降级或文档说明。 |
| 32 | + |
| 33 | +### 3. 主题、版型和内容模块化 |
| 34 | + |
| 35 | +NotionNext 已经有多套主题,但长期维护的关键不是主题数量,而是主题之间能否共享稳定的基础能力。 |
| 36 | + |
| 37 | +后续可以逐步沉淀: |
| 38 | + |
| 39 | +- 更清晰的主题接口和配置边界。 |
| 40 | +- 可复用的文章卡片、列表、图库、导航、筛选页面等内容模块。 |
| 41 | +- 面向不同场景的版型能力,例如案例库、作品集、知识库、产品页和导航站。 |
| 42 | +- 更容易迁移和维护的主题文档、预览图与测试方式。 |
| 43 | + |
| 44 | +### 4. 更安全的升级体验 |
| 45 | + |
| 46 | +很多站长会在 Fork 后修改配置、样式或主题。项目需要承认这种现实,而不是假设所有人都只使用原始代码。 |
| 47 | + |
| 48 | +未来需要继续优化: |
| 49 | + |
| 50 | +- 把站长自定义配置和核心代码改动尽量分离。 |
| 51 | +- 让版本升级更容易判断哪些冲突必须人工处理。 |
| 52 | +- 对常见下游分支维护方式提供更明确的建议。 |
| 53 | +- 在 CI、测试和发布流程中尽早发现破坏性变更。 |
| 54 | + |
| 55 | +### 5. 让更多角色能参与 |
| 56 | + |
| 57 | +开源项目不只需要核心代码贡献者。NotionNext 的真实使用场景很多,站长、设计师、文档维护者、测试者都能帮助项目变好。 |
| 58 | + |
| 59 | +我们希望把任务拆得更小、更清楚,让不同经验的人都能找到入口。 |
| 60 | + |
| 61 | +## 可以如何参与 |
| 62 | + |
| 63 | +如果你还不熟悉代码,可以从这些事情开始: |
| 64 | + |
| 65 | +- 复现问题:提供网站链接、Notion 页面、分支名、部署平台和截图。 |
| 66 | +- 测试修复:在自己的站点或测试分支验证 PR 是否解决真实问题。 |
| 67 | +- 补充文档:把踩过的坑整理成教程、FAQ 或排查步骤。 |
| 68 | +- 改进体验:指出哪些概念、配置或升级流程对非开发者不友好。 |
| 69 | +- 贡献主题素材:补主题截图、使用说明、适用场景和配置示例。 |
| 70 | + |
| 71 | +如果你已经能改代码,可以优先关注: |
| 72 | + |
| 73 | +- Notion 数据结构兼容性和测试用例。 |
| 74 | +- 主题公共组件和版型模块。 |
| 75 | +- 构建、缓存、部署和升级稳定性。 |
| 76 | +- 文档站、CI、发布流程和维护工具。 |
| 77 | +- 带有 `good first issue` 或 `help wanted` 标签的问题。 |
| 78 | + |
| 79 | +## 近期适合拆分的任务 |
| 80 | + |
| 81 | +这些方向适合逐步拆成 Issue、Discussion 或 RFC: |
| 82 | + |
| 83 | +| 方向 | 可拆任务 | |
| 84 | +| --- | --- | |
| 85 | +| Notion 数据库能力 | 补齐视图筛选、排序、状态分组、多选、日期、关系属性等兼容测试 | |
| 86 | +| 图文卡片版型 | 为标签页、分类页或指定数据库视图提供稳定的卡片展示方案 | |
| 87 | +| 升级体验 | 梳理 Fork 用户如何同步上游、如何处理分支和部署缓存 | |
| 88 | +| 主题模块化 | 抽象文章卡片、列表、图库、筛选页等跨主题可复用组件 | |
| 89 | +| 文档维护 | 把真实用户反馈整理成 FAQ、排查手册和升级指南 | |
| 90 | +| 测试与 CI | 为关键数据格式、构建缓存、主题渲染补充小范围自动化验证 | |
| 91 | + |
| 92 | +## 协作原则 |
| 93 | + |
| 94 | +- 先讨论真实场景,再设计功能。 |
| 95 | +- 大改动先写 RFC,小修复保持 PR 小而清楚。 |
| 96 | +- 优先补测试和文档,减少后续维护成本。 |
| 97 | +- 允许非代码贡献存在价值,真实反馈本身就是项目路线的一部分。 |
| 98 | + |
| 99 | +NotionNext 的 5.0 不是某个人一次性完成的大版本,而是社区持续把复杂度收拢、把门槛降下来的过程。每一次可复现的问题、一次文档修正、一个小范围 PR,都会让后来的站长少踩一个坑。 |
0 commit comments