30 KiB
Gitconomy Research社区文档规范指南
1. 前言
1.1 宗旨与目的
在人人都是研究员的Gitconomy开放研究社区中，让每一次Commit都能被社区快速阅读、复现、再创造。本指南统一文档风格、目录结构、元数据与提交流程，确保人类transclusion与 AI 都能无缝协作。
1.2 指南适用范围
本指南适用于所有向Gitconomy Research所有仓库提交的文档类内容，包括但不限于：
- 研究论文、报告解读
- 项目白皮书、技术文档
- 教程、工作流程指南
- 会议记录、社区治理提案
- README 文件
- 任何其他以 .md, .pdf, .txt 等格式存储的说明性文件。
1.3 指南规范指导思想
本部分旨在阐明本指南背后的“原因”，将文档定位为开源环境下开放研究流程中不可或缺的一环，而不仅仅是一项繁琐的任务。
在开放式研究的背景下，文档是建立信任和确保科学有效性的首要工具。它不仅是项目成果的说明书，更是研究过程透明度和可信度的载体。传统的开源软件文档侧重于可用性和功能实现，而开放式 研究 文档则必须将可复现性置于核心地位。一份高质量的文档，意味着研究成果是可被验证、可被信赖的，从而使其他研究者能够在此基础上进行验证和扩展 。因此，本社区的文档不仅要服务于代码的使用者，更要服务于科学的审查者。
一个成功的开源研究社区，其本质在于融合两种截然不同的文化：软件开发的敏捷迭代文化与学术研究的严谨验证文化。前者追求快速原型和功能交付，文档侧重于“快速上手”和API参考 ；后者则强调同行评审和结果验证，文档侧重于详尽的方法论、数据来源和理论依据。若无法有效弥合这两种文化的差异，社区将面临两种潜在的失败模式：其一，项目因缺乏严谨的方法学和数据文档而科学性不足，无法获得学术界的认可；其二，项目因文档过于晦涩、理论性过强而吓退潜在的社区贡献者，导致项目停滞不前。
因此，本指南的核心目标是建立一种混合文档模型。它既要提供顶级开源软件项目所具备的清晰、简洁的快速入门指南和用法示例 ，又要强制执行学术研究所需的严格的数据、代码和实验方法文档标准。这种模型的建立，旨在将文档本身作为澄清思路、帮助他人理解期望的工具 ，并最终将严谨的科学数据管理融入社区工作流程，使其成为迈向可复现研究的第一步 。通过这种方式，文档将成为连接敏捷协作与科学严谨性的桥梁，从而构成本社区独特的价值主张。
1.4 指南规范原则
Gitconomy Research开放研究社区文档规范的基本原则：
乐高原则——把文档拆成最小可复用单元（数据说明、方法描述、代码片段、思维笔记），像乐高一样随取随拼。AI友好——所有文档须同时满足“人类可读 + LLM 可解析”。使用显式标题、列表、代码围栏，避免隐式引用。一次写作、多处复用——任何文档块（如方法描述）应能在 README、论文、教学课件中无缝引用，借助 Markdown 的 transclusion 与变量替换实现。渐进式参与——提供不同复杂度的规范要求，让新手能够低门槛参与，同时为经验丰富的贡献者提供高级指南。可访问性优先——确保文档对各种设备、各种阅读需求的用户都友好，包括屏幕阅读器用户、色盲用户等。
2. 快速上手
2.1 快速参考清单
以下是提交文档前的基本检查清单，确保满足核心要求：
- 文件名使用小写字母，单词间使用连字符（-）分隔
- [ ] 文档使用Markdown格式（.md后缀）
- [ ] 文档包含清晰的标题（一级标题）
- [ ] 文档包含作者和日期信息（显式或隐式元数据）
- [ ] 标题层级正确（不跳级，如一级标题后直接使用三级标题）
- [ ] 内容结构清晰，使用适当的小标题划分
- [ ] 图片使用相对路径引用，并提供alt文本
- [ ] 代码块使用三个反引号标记，并指定语言
- [ ] 包含许可声明
- [ ] 参考文献格式统一
2.2 新手贡献路径
为帮助新加入社区的贡献者逐步掌握文档规范，我们提供以下渐进式参与路径：
| 路径 | 关注要点 | 主要参与方式 | |
|---|---|---|---|
| 1 | 入门级 | 关注基本格式和内容准确性 | - 使用现有模板创建文档 - 确保基本元数据完整 - 遵循基本Markdown语法 |
| 2 | 进阶级 | 提升文档结构和可读性 | - 优化内容组织和层次结构 - 添加适当的图表和视觉元素 - 完善引用和参考文献 |
| 3 | 专家级 | 实现文档的最佳实践 | - 创建可复用的文档组件 |
新手贡献者可以从以下简单任务开始：
- 修正现有文档中的拼写和格式错误
- 为现有文档添加示例或说明
- 翻译已有文档到其他语言
- 撰写简短的教程或指南
3. 目录规范
3.1 通用目录规范
所有Gitconomy Research仓库应遵循一致的顶层目录结构：
📁 repository-name/
├── 01-category-one/ # 第一类内容
├── 02-category-two/ # 第二类内容
├── 03-category-two/ # 第二类内容
│ ├── .scripts/ # 文档相关脚本
│ ├── templates/ # 文档模板
│ └── assets/ # 共享资源（图片等）
├── README.md # 项目概述
├── CONTRIBUTING.md # 贡献指南
└── 📄 LICENSE # 许可证文件
目录命名应遵循以下规则：
- 请使用小写字母
- 单词间使用中划线连字符（-）分隔
- 使用数字前缀给文件夹排序（如01-introduction/），方便 GitHub/GitCode Web 界面浏览
- 名称应简洁明了，反映内容主题
3.2 研究类文档
📁 research-topic/
├── 📁 01-papers/ # 完整论文或报
├── 📁 02-data/ # 研究数据
│ ├── raw/ # 原始数据
│ └── processed/ # 处理后的数据
├── 📁 03-methods/ # 研究方法描述
├── 📁 04-analysis/ # 分析代码和结果
├── 📁 05-assets/ # 图表和可视
└── 📄 README.md # 研究概述和导航
3.3 教育类文档
📁 education-topic/
├── 📁 01-introduction/ # 课程说明
├── 📁 02-syllabus/ # 教学大纲
├── 📁 03-lessons/ # 课程内容
│ ├── 📄 lesson-01.md
│ └── ...
├── 📁 04-exercises/ # 练习和实践项目
├── 📁 05-resources/ # 学习资源
└── 📄 README.md # 课程概述和导航
3.4 评论/思维类文档
📁 perspective-topic/
├── 📁 01-case-studies/ # 案例研究
├── 📁 02-references/ # 参考资料
├── 📄 README.md # 主题概述和导航
├── 📄 core-concepts.md # 核心概念阐述
└── 📄 pplications.md # 应用场景
5. 文档规范
5.1 文档命名规范
-
文件命名规则
文件命名应遵循以下规则：
- 使用小写字母（中文文件名除外）
- 单词间使用连字符（-）分隔
- 文件扩展名使用小写
- 包含版本信息时使用v1, v2等后缀
- 内容类型应该在文件名中体现
示例：
- 英文文档：contribution-guidelines.md, ai-collaboration-model-v2.md
- 中文文档：基于贡献即要素的社区角色重构思考.md
- 包含日期的文档：weekly-report-20250301.md
- 图片命名规则
- 使用描述性名称
- 指明图片类型或用途
- 多语言文档命名
多语言文档应在文件名中添加语言代码：
- 使用ISO 639-1两字母语言代码
- 语言代码置于文件名末尾，扩展名之前
- 使用连字符分隔语言代码
示例：
- 英文版：contribution-guidelines-en.md
- 中文版：contribution-guidelines-zh.md
对于主要使用中文的文档，可以使用中文文件名，并在其他语言版本中添加相应语言代码：
- 中文原版：研究方法.md
- 英文翻译版：研究方法-en.md
- 版本号规范
文档版本号应遵循语义化版本控制（Semantic Versioning）规范：
- 格式为：主版本号.次版本号.修订号（例如：1.2.3）
- 主版本号：不兼容的内容变更
- 次版本号：向后兼容的功能性新增
- 修订号：向后兼容的问题修正
在文件名或元数据中表示版本时：
- 文件名中使用简化版本：document-name-v1.md, document-name-v2.md
- 元数据中使用完整版本号：version: 1.2.3
5.2 文档格式规范
5.2.1 Markdown基本规范
所有文档应使用 Markdown 格式编写，遵循以下规范：
- 标题层级
- 文档标题使用一级标题（# 标题）
- 主要章节使用二级标题（## 章节）
- 子章节使用三级标题（### 子章节）
- 最多使用到四级标题（#### 小节）
正确示例：
# 文档标题
## 第一章
### 1.1 小节
### 1.2 小节
## 第二章
错误示例：
# 文档标题
### 1.1 小节（跳过了二级标题）
- 列表格式
- 无序列表使用连字符（-）
- 有序列表使用数字加点（1.）
- 列表缩进使用两个空格
示例：
- 第一项
- 第二项
- 子项A
- 子项B
- 第三项
1. 第一步
2. 第二步
1. 子步骤1
2. 子步骤2
3. 第三步
- 代码块
- 使用三个反引号标记代码块
- 指定语言类型以启用语法高亮
示例：
def example_function():
return "This is a code example"
- 表格
- 使用标准Markdown表格语法
- 表格前后留一空行
- 表头与内容之间必须有分隔行
- 尽量保持列对齐以提高可读性
示例
| 列名1 | 列名2 | 列名3 |
|---|---|---|
| 数据1 | 数据2 | 数据3 |
| 数据1 | 数据2 | 数据3 |
- 链接与图片
- 使用相对路径引用仓库内图片
- 外部链接应提供完整URL，包括https://前缀
- 提供清晰的alt 文本，兼顾无障碍与 LLM 理解。
示例：
[相关文档](../docs/related-document.md)
<https://gitconomy.org/>
5.2.2 元数据规范
对于较长的研究文档或文章，建议在 Markdown 文件顶部添加 YAML Front Matter 来提供元数据，便于管理和检索。元数据可以采用显式或隐式方式：
- 显式元数据（推荐用于正式研究文档）
文档开头使用YAML格式的元数据块：
示例：
---
title: 文档标题
author: 作者名称
date: YYYY-MM-DD
version: x.y.z
category: [研究/思想/教育]
tags: [标签1, 标签2]
---
必填字段：
title: 文档标题author: 主要作者date: 创建或最后修改日期version: 文档版本
可选字段：
category: 文档类别tags: 相关标签contributors: 其他贡献者license: 许可证类型language: 文档语言original_link: 原文链接（适用于翻译文档）summary: 简短摘要
- 隐式元数据（适用于简短文档或非正式贡献）
在文档正文中自然融入必要信息：
示例：
# 文档标题
作者：作者名称 | 日期：YYYY-MM-DD | 版本：x.y.z
[文档正文开始...]
对于简短或临时性文档，甚至可以只在文档标题下方添加作者和日期信息：
示例：
# 文档标题
作者：作者名称
日期：YYYY-MM-DD
[文档正文开始...]
无论采用哪种方式，都应确保包含基本的作者和日期信息，以便追踪文档来源和版本。
5.3 内容组织规范
- 基本结构
研究类文档应包含以下基本结构：
1. 标题：清晰表达文档主题
2. 摘要：不超过200字，概述核心内容和贡献
3. 引言：背景、目的和研究问题
4. 正文：结构清晰，使用多级标题划分逻辑段
5. 结论：总结要点，指出局限性和未来工作
6. 参考文献：引用所有参考的外部资料
7. 附录（可选）：额外材料、数据或代码
教育类文档应包含：
1. 标题：课程或教程名称
2 .学习目标：完成后预期获得的能力
3. 先决条件：所需的基础知识
4. 内容：分步骤或模块组织的教学内容
5. 练习：巩固学习的活动
6. 进阶资源：深入学习的参考资料
评论/思维类文档应包含：
1. 标题：观点或思考的主题
2. 核心主张：主要观点概述
3. 论证：支持主张的理由和证据
4. 应用：思想的实际应用场景
5. 参考文献：相关研究和资料
- 内容模块化
遵循"乐高原则"，将文档内容模块化：
- 每个模块应有明确的标题
- 相关内容应组织在一起
- 避免过长的段落（超过10行）
- 使用列表和表格组织复杂信息
- 通过小标题创建清晰的内容结构
5.4 图表与多媒体规范
好的，这是您提供内容的Markdown表格格式：
| 类别 | 具体要求 |
|---|---|
| 图片规范 |
|
| 图表要求 |
|
| 多媒体内容 |
|
| 可访问性要求 |
|
示例：
*图1：该图展示了Gitconomy社区研究框架，包含三个核心组件：知识生产、价值分配和治理机制。*
5.5 参考文献与引用
- 引用格式
- 学术引用使用APA格式
- 引用应在文档末尾的"参考文献"部分列出
- 引用编号在正文中使用方括号标注，如[1]
示例（正文中）：
根据最新研究[1]，开放研究模式能显著提高知识传播效率。Smith等人[2]进一步指出...
示例（参考文献部分）：
## 参考文献
[1] Johnson, A., & Williams, B. (2023). Open Research Paradigms. *Journal of Open Science*, 45(2), 112-128.
[2] Smith, C., Jones, D., & Brown, E. (2024). Knowledge Sharing in Digital Commons. *Digital Collaboration Review*, 12(4), 78-92. https://doi.org/10.1234/dcr.2024.123
- 脚注使用
对于解释性内容或次要信息，可使用脚注：
这是正文内容[^1]，包含需要额外解释的概念。
[^1]: 这是脚注内容，提供额外解释或参考信息。
- 术语引用
- 首次出现的专业术语应提供简短解释或脚注
- 考虑在文档末尾添加术语表
- 保持术语使用的一致性，避免同一概念使用不同表述
5.6. 许可说明
Gitconomy Research社区采用以下许可方式：
- 文档许可
所有文档内容采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 (CC BY-NC-SA 4.0)进行许可。这意味着您可以：
- 共享：复制、发行、展示和表演本作品
- 演绎：修改、转换或以本作品为基础进行创作
但须遵守以下条件：
- 署名：必须提供原作者的署名
- 非商业性使用：不得将本作品用于商业目的
- 相同方式共享：如果您改变、转换本作品或以本作品为基础进行创作，您只能使用与本作品相同或兼容的许可协议发布您的贡献
- 代码许可
所有代码（包括代码示例、脚本）采用MIT许可证进行许可。这是一个宽松的软件许可证，只要保留版权和许可声明，允许任何人以任何方式使用代码。
- 数据许可
研究数据采用开放数据共享 (ODbL)许可，允许自由共享、修改和使用数据，但要求保持开放并归功于原始贡献者。
6. 写作风格指南
6.1 语言与表达
- 清晰性与简洁性
- 使用主动语态：强制要求使用主动语态，以增强清晰度和直接性。例如，使用"该脚本处理数据…“而非"数据被该脚本处理…”。
- 使用简洁句式：提倡使用简短、清晰的句子。避免冗长、复杂的从句结构。
- 术语一致性：保持术语使用的统一性，避免使用同一概念的不同表述。
- 正式性与专业性
- 保持适度的正式性，避免过于口语化的表达
- 避免使用缩写词（除非已经解释）
- 使用精确的技术术语，避免模糊表述
- 避免使用情感化或主观评价性语言
6.2 结构化写作
好的，这是您提供内容的Markdown表格格式：
| 类别 | 具体要求 |
|---|---|
| 段落组织 |
|
| 章节划分 |
|
| 内容流程 |
|
6.3 视觉化沟通
- 展示而非描述
**"Show, don’t tell"**是本社区文档的核心原则之一。应优先使用视觉元素来传达信息。
- 对于多维度信息，使用表格呈现
- 对于流程或关系，使用流程图或关系图
- 对于数据趋势，使用图表
- 对于用户界面，使用截图或GIF动图
- 视觉元素规范
- 所有视觉元素都应有编号和标题
- 在正文中引用视觉元素（如"如图1所示"）
- 提供足够的上下文，确保视觉元素可独立理解
- 确保视觉元素与文本内容紧密相关
- 命令行展示
对于命令行操作，使用代码块并添加注释：
# 安装依赖包
pip install -r requirements.txt
# 运行分析脚本
python analyze.py --input data.csv --output results.json
6.4 可访问性考虑
好的，这是您提供内容的Markdown表格格式：
| 类别 | 具体要求 |
|---|---|
| 文本可访问性 |
|
| 色彩使用 |
|
| 屏幕阅读器支持 |
|
| 多设备适配 |
|
7. AI辅助写作
7.1 AI工具使用指南
AI工具可以显著提高文档创作效率，但应当谨慎使用并确保内容质量。
推荐的AI辅助场景：
- 草稿生成和构思发散
- 文本润色和语法检查
- 内容摘要和关键点提取
- 格式转换和规范化
- 专业术语解释和简化
使用建议：
- 将AI视为协作工具，而非完全替代人工创作
- 始终审核AI生成的内容，确保准确性和相关性
- 提供具体、详细的提示（prompt），获取更精准的结果
- 保持文档风格一致，避免AI生成部分与人工部分风格差异明显
8.2 提示词（Prompt）模板库
以下是常用的AI辅助写作prompt模板，可用于常见文档创作任务：
- 文档结构生成
请为一篇关于[主题]的研究文档创建详细的结构大纲，包括以下部分：
1. 引言（背景、目的、研究问题）
2. 文献综述
3. 研究方法
4. 数据分析
5. 研究结果
6. 讨论
7. 结论
- 内容润色与格式化
请帮我润色以下文本，使其更加清晰、简洁，并符合学术写作风格。同时，请将内容格式化为Markdown格式，使用适当的标题层级、列表和强调。
[粘贴需要润色的文本]
- 术语解释生成
请为以下专业术语创建简明的解释，适合在文档中首次提及时使用。每个解释不超过30字：
1. [术语1]
2. [术语2]
3. [术语3]
7.3 AI辅助的最佳实践
- 提示工程技巧
- 使用明确、具体的指令
- 提供上下文和目标受众信息
- 指定输出格式（如Markdown）
- 分步骤提问，逐步完善内容
- 要求AI提供多个备选方案
- 审核与质量控制
- 核实AI生成的事实和数据
- 检查逻辑连贯性和论证有效性
- 确保内容与主题相关，不偏离焦点
- 维持一致的术语使用和写作风格
- 检查AI是否理解了特定领域的专业知识
- 透明度和诚信
- 在适当情况下注明内容由AI辅助生成
- 不使用AI生成虚假研究结果或数据
- 保持人类的创造性思维和批判性思考
- 遵循相关伦理准则和最佳实践
8. Git工作规范
8.1 分支管理规范
Gitconomy Research社区采用基于功能分支的Git工作流程，确保代码和文档的高质量和可追踪性。
- 分支命名规范
主分支：main或master，保持稳定可用状态开发分支：develop，集成已完成但未发布的功能功能分支：feature/简短描述，用于开发新功能或文档修复分支：fix/简短描述，用于修复错误文档分支：docs/简短描述，专门用于文档更新发布分支：release/版本号，准备发布的版本热修复分支：hotfix/简短描述，用于紧急修复生产环境问题
- 分支工作流程
1. 从最新的main或develop分支创建功能分支
2. 在功能分支上进行开发和提交
3. 定期将主分支合并到功能分支，保持同步
4. 完成后，创建Pull Request请求合并
5. 通过代码审核后，合并到主分支
6. 合并后删除功能分支
8.2 提交（Commit）信息规范
- 提交信息
提交信息应遵循以下格式：
- 类型(范围): 简短描述
- 详细描述（可选）
- 相关问题（可选）
类型包括：
docs：文档更新feat：新功能fix：错误修复refactor:：代码重构（不改变功能）style：格式调整（不影响代码功能）test：测试相关chore：构建过程或辅助工具的变动
范围（可选）
指明本次提交影响的范围，如：
core：核心模块ui：用户界面api：API接口intro：介绍文档all：全局变更
描述
- 使用命令式语气（如"添加功能"而非"添加了功能"）
- 简洁明了（不超过50个字符） -不以句号结尾
示例：
docs(readme): 更新安装说明
- 添加Windows系统安装步骤
- 更新依赖库版本要求
- 修复格式错误
Closes #123
- Pull Request格式规范
提交Pull Request应遵循以下格式：
- 标题： 清晰描述PR目的，如 [Docs] Add Eclipse Attack Research。
- 描述：
- 简要说明本次提交的内容和目的。
- 关联相关 Issue（如有），例如 Closes #123。
- 勾选检查项（见下文PR模板）。
Pull Request模板：
## 变更类型
<!-- 请勾选一项 -->
- [ ] 新研究论文/报告
- [ ] 新教程/指南
- [ ] 文档内容修正/更新
- [ ] 文档结构优化
- [ ] 其他（请注明）________________
## 描述
<!-- 详细描述本次提交的目的和主要内容。 -->
## 相关 Issue
<!-- 关联本次PR旨在解决的Issue，例如 Closes #123 -->
Closes #
## 检查清单 (Checklist)
<!-- 请在提交前确保完成以下事项 -->
- [ ] 我已阅读并同意遵守《文档贡献指南》。
- [ ] 我对文档进行了拼写和语法检查。
- [ ] 我使用了建议的文件命名规则和目录结构。
- [ ] 我的文档结构清晰，包含了摘要、正文和参考文献等必要部分。
- [ ] 我引用了所有参考的资料和来源。
审核过程：
- 提交PR：贡献者创建PR并填写模板
- 自动化检查：运行文档格式和链接检查
- 同行评审：至少一名维护者进行代码审核
- 反馈修改：根据审核意见进行修改
- 批准合并：符合要求后由维护者批准并合并
8.3 代码审核标准
- 文档审核要点
准确性：内容是否准确、最新完整性：是否包含所有必要信息结构：组织是否清晰、逻辑风格：是否符合写作风格指南格式：是否遵循Markdown规范可读性：是否易于理解和阅读一致性：是否与现有文档保持一致
- 技术内容审核
代码示例：是否正确、最佳实践、可运行技术描述：是否准确、清晰安全性：是否包含敏感信息性能：建议的做法是否高效
- 审核反馈指南
- 提供具体、建设性的反馈
- 区分必须修改的问题和建议性改进
- 指出问题的同时提供解决方案
- 保持礼貌和尊重，关注内容而非人
10. 工具与资源
10.1 推荐工具
作为一个开放研究社区，Gitconomy Research鼓励使用开源工具进行文档创作和研究工作。开源工具通常具有以下优势：
- 透明性：源代码公开，工作原理可查验，符合开放研究的透明性原则
- 可持续性：不依赖单一商业实体，降低工具突然停止支持的风险
- 可定制性：可根据特定需求进行修改和扩展
- 知识共享：促进社区协作和知识累积
- 可访问性：通常免费使用，降低参与门槛
- 格式开放：减少数据锁定，提高长期可访问性
我们建议优先考虑开源替代方案，特别是在核心工作流程中。然而，我们也理解在某些情况下，专有工具可能提供必要的功能或便利性。因此，本指南中的工具推荐包含了开源和专有选项，最终选择应基于个人需求、工作流程和具体情况。无论选择何种工具，我们鼓励将数据保存为开放格式（如Markdown、CSV、JSON等），确保内容的长期可访问性和可迁移性。
- Markdown编辑器
- Joplin：开源笔记和待办事项应用，支持Markdown、加密和同步
- Obsidian：知识管理与Markdown编辑
- Zettlr：开源的学术写作Markdown编辑器
- Jupyter Lab：交互式开发环境，支持Markdown单元格与代码混合编辑，特别适合数据科学和计算研究文档
- VS Code（配合Markdown All in One插件）
- 图表与图形工具
- Mermaid：通过代码创建图表
- Draw.io：免费的图表绘制工具
- Excalidraw：手绘风格图表工具
- Canva：设计与图形创作平台
- Inkscape：开源矢量图形编辑器
- GIMP：开源图像编辑软件
- 质量检查工具
- Grammarly：语法和拼写检查
- Hemingway Editor：可读性分析
- markdownlint：Markdown格式检查
- Vale：可定制的文档风格检查
- 协作与版本控制
10.2 模板库
Gitconomy Research提供以下文档模板，便于创建标准化内容：
- 研究文档模板
- 教育文档模板
- 社区文档模板
（陆续更新中）
11. 文档规范指南总结
遵循此指南将有助于：
- 提高协作效率： 统一的格式和结构让其他成员更容易阅读、理解和维护文档。
- 保证内容质量： 通过规范化的流程，确保提交的文档清晰、准确、有价值。
- 维持仓库整洁： 良好的文件组织方式使仓库结构清晰，便于导航和管理。
- 展现社区专业性： 统一的规范体现了社区的严谨性和专业性，吸引更多优秀的贡献者。
最后，感谢你花时间阅读本指南并为Gitconomy Research社区做出贡献！你的每一份努力都帮助我们共同构建一个更强大、更专业的开源研究社区。
12. 附录： 术语表
以下是Gitconomy Research社区常用术语的标准定义：
| 术语 | 定义 |
|---|---|
| 开放研究 | 强调研究过程和结果公开透明，允许他人访问、验证和构建的研究方法。 |
| 可复现性 | 使用相同的数据和方法能够获得相同或类似结果的特性。 |
| 数据溯源 | 记录和追踪数据来源、处理步骤和转换过程的完整历史。 |
| 同行评审 | 由同领域专家对研究成果进行严格评估的过程。 |
| 版本控制 | 跟踪和管理文件变更的系统，允许回溯历史版本。 |
| 知识共享 | 主动分享研究发现、方法和数据，促进科学进步的实践。 |
| 混合文档模型 | 结合软件开发的敏捷文档和学术研究的严谨性的文档方法。 |
| 乐高原则 | 将文档拆分为最小可复用单元，便于组合和重用的方法。 |
| 元数据 | 描述数据的数据，如创建时间、作者、版本等。 |
许可声明
本文档采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 (CC BY-NC-SA 4.0) 进行许可。