Skip to content

COMMUNITY_SITE_ROADMAP.md

Latest commit

 

History

History
235 lines (164 loc) · 5.92 KB

COMMUNITY_SITE_ROADMAP.md

File metadata and controls

235 lines (164 loc) · 5.92 KB

社区官网能力扩展路线

背景

NotionNext 现在非常适合做个人博客、作品集、知识库和轻内容站点，但如果要承接“社区官网”场景，会很快碰到几个结构性短板：

  1. 单作者模型过强
    当前很多主题和 SEO 元数据默认围绕 AUTHOR、AVATAR、BIO 这一组单人字段展开。
  2. 组织信息与内容信息没有分层
    社区成员、活动、报名表、招募信息、内容文章，都会被当作普通页面/文章处理，缺少清晰的数据角色区分。
  3. 表单与活动闭环能力薄弱
    可以展示活动，但缺少发布活动、收集报名、展示成员、回显状态的统一方案。
  4. 多人展示能力不足
    缺少成员列表、头像预览、成员 bio、角色标签、社交链接、成员详情页等常见社区模块。

这意味着：NotionNext 目前更像“博客模板集合”，而不是“内容驱动的社区官网框架”。

适用场景

这个方向适合：

  • 开源社区官网
  • 校园组织官网
  • 创作者社区主页
  • DAO / 社群主页
  • 沙龙 / meetup 组织官网
  • 有活动、成员、内容、招募四类信息的轻运营站点

当前能力与缺口

已有基础

  • 有统一数据层：lib/db/SiteDataApi.js
  • 有主题层可消费统一 props
  • 有部分“团队区块”雏形，例如 starter 的 Team 组件
  • 有配置驱动和 Notion Config 机制
  • 有路由与静态生成能力，适合做目录页和详情页

主要缺口

1. 成员管理

缺少：

  • 成员集合的数据模型
  • 成员头像列表 / 卡片墙
  • 成员 bio / role / social links
  • 成员详情页
  • 成员与内容的关联关系

2. 社区内容分层

建议把现有内容至少拆成四类：

  • Post: 普通内容文章
  • Member: 社区成员
  • Event: 活动
  • Page: 静态说明页

实现时，Member / Event 应与现有 Notion 页面 type 约定、lib/db/SiteDataApi.js 的数据契约，以及主题 props 与路由的既有模式对齐，避免与文章/页面流程硬分叉。

如果继续全部混在 Post/Page 里，后续主题、搜索、SEO、列表页、导航、侧边栏都会越来越难维护。

3. 活动发布与展示

缺少：

  • 活动列表页
  • 活动详情页
  • 时间 / 地点 / 报名截止时间 / 状态字段
  • 已结束 / 进行中 / 即将开始 的状态管理
  • 活动与表单链接的标准化展示

4. 表单收集

缺少：

  • 报名入口字段
  • 外部表单嵌入 / 跳转规范
  • 表单型页面的 UI 约定
  • 收集结果的接入说明

这里不一定要求 NotionNext 自己做完整后端，更现实的做法是：

  • 先支持 外部表单链接 / 嵌入
  • 再考虑接入 Airtable / Notion Form / Tally / 飞书表单 / 自建 API

5. 多人作者展示

当前 AUTHOR / AVATAR / BIO 基本是单人站点思路。社区官网更需要：

  • 页面级作者卡片
  • 多作者/多维护者
  • 成员头像预览
  • 成员简介与职责
  • 内容作者与组织成员分离

建议的数据模型

Member

建议最小字段：

  • slug
  • name
  • avatar
  • bio
  • role
  • tags
  • socialLinks
  • joinedDate
  • status
  • featured

Event

建议最小字段：

  • slug
  • title
  • summary
  • cover
  • startDate
  • endDate
  • location
  • eventStatus
  • registrationUrl
  • registrationEmbedUrl
  • organizer
  • speakers
  • featured

Post

保留现有文章模型，但建议额外支持：

  • authors（数组）
  • relatedMembers
  • relatedEvents

推荐的功能拆分顺序

Phase 1: 社区展示基础能力

目标：先能“看起来像社区官网”。

建议 PR：

  1. 成员集合支持

    • 在数据层识别 Member
    • 提供 allMembers
    • 支持成员详情页基础路由

  2. 成员卡片列表组件

    • 头像
    • 名称
    • bio
    • role
    • 社交链接

  3. 活动集合支持

    • 在数据层识别 Event
    • 提供 allEvents
    • 活动列表/详情页基础能力

Phase 2: 社区运营能力

目标：先能“发活动、收报名、展示组织”。

建议 PR：

  1. 活动状态字段规范

    • upcoming
    • ongoing
    • ended
    • cancelled

  2. 报名入口能力

    • registrationUrl
    • registrationEmbedUrl
    • registrationNote

  3. 内容与组织信息分层

    • 导航、搜索、站点地图里区分 Post / Member / Event / Page

Phase 3: 社区内容协作能力

目标：先能“多人协作发布内容”。

建议 PR：

  1. 多作者支持

    • authors 数组
    • 作者卡片
    • 作者链接到成员页

  2. 内容关联

    • 文章关联成员
    • 文章关联活动
    • 成员页回显内容贡献

建议优先发起的 Issue

最值得先提的不是“大而全社区系统”，而是以下 3 类高价值 issue：

  1. 支持 Member / Event 内容类型

    • 这是所有社区场景的底座
    • 技术上最适合先从数据层做

  2. 支持多作者与成员资料卡

    • 对博客、团队站、社区站都有价值
    • 复用面最大，最容易获得上游接受

  3. 支持活动页与报名入口字段

    • 功能边界清晰
    • 很适合拆成渐进式 PR

建议的 MVP Issue 文案方向

可以把问题描述成：

NotionNext 目前对个人博客支持很好，但对社区官网/组织官网场景支持不足。建议在数据层与主题契约中增加 Member / Event 类型，以及成员资料卡、多作者、活动报名入口等基础能力，让项目不仅适合单作者博客，也适合多人社区站点。

这个表述的好处是：

  • 不会显得需求过散
  • 不是只替一个特定站点定制
  • 更像“框架通用能力增强”

文档化建议

本文档可作为该方向的总览路线图。若后续落地实现，建议再补充更细的设计文档，例如：

  • docs/COMMUNITY_SITE_SCHEMA.md（字段与数据契约）
  • docs/COMMUNITY_SITE_EXAMPLES.md（主题与 Notion 配置示例）