你是否工作中总会有一些对开源的项目不满意的地方？
你是否想把自己的 想法 放到社区里来提升自我价值？
你是否会发现，在自己想要参与开源的时候，无从下手？
工欲善其事必先利其器 - 了解开源。
开源基于以下几个核心概念：
1. 自由访问
开源的核心是源代码对所有人开放，任何人都可以查看、使用、修改和分发源代码。这种自由访问的原则使得开源软件能够被广泛传播和使用。
2. 共享和协作
开源鼓励共享和协作。开发者可以在开源项目中共享他们的代码，其他开发者可以基于这些代码进行改进或添加新的功能。这种协作方式使得开源项目能够快速发展和改进。
3. 透明度
开源项目的所有更改和决策都是公开的，这种透明度使得开源项目更加可信和可靠。开发者可以查看源代码的所有更改，了解项目的发展历程。
4. 社区驱动
开源项目通常由一个开发者社区驱动，社区成员可以参与到项目的各个方面，包括代码贡献、问题反馈、文档编写等。这种社区驱动的方式使得开源项目能够持续发展和改进。
开源协议？
开源协议是开源项目的法律基础（电子知识产权），它规定了如何使用、修改和分发源代码。以下是一些常见的开源协议及其主要区别：
1. MIT许可证：非常宽松，允许任何使用、修改和分发，只需要保留原始的版权声明和许可声明。
2. GNU通用公共许可证（GPL） ：要求任何发布的改进的源代码版本也必须是开源的，这被称为“病毒性”许可证。
3. Apache许可证：允许用户使用、修改和分发，但必须保留原始的版权声明和许可声明，同时如果修改了代码，必须在修改的文件中明确指出。
4. BSD许可证：非常宽松，类似于MIT许可证，但如果在产品中使用了BSD许可证的代码，需要在产品的文档中包含BSD许可证的内容。
前端的知名开源项目
以下是一些前端的知名开源项目：
1. React：由Facebook开发和维护的一个用于构建用户界面的JavaScript库，使用MIT许可证。
2. Vue.js：一个用于构建用户界面的JavaScript框架，使用MIT许可证。
3. Angular：由Google开发和维护的一个用于构建Web应用的平台，使用MIT许可证。
4. Bootstrap：最流行的HTML、CSS和JavaScript框架，用于开发响应式布局和移动设备优先的WEB项目，使用MIT许可证。
5. D3.js：一个JavaScript库，用于创建数据驱动的文档，使用BSD许可证。
开源协议使用规则
（原著：乌克兰程序员Paul Bagwell，翻译：阮一峰）
"闭源"是指软件的源代码不公开，用户只能获取到编译后的二进制版本，不能查看、修改或分发源代码。这与开源软件相对，开源软件的源代码是公开的，用户可以自由地查看、修改和分发源代码。
闭源软件的开发和维护通常由单一的公司或组织进行，他们拥有软件的全部知识产权。用户需要购买许可证才能使用闭源软件，而且通常不能自由地修改和分发软件。
常见的闭源软件包括Microsoft的Windows操作系统和Office办公套件，Adobe的Photoshop等
放置版权说明
copyleft copyright
Github 专门发布了一个网站 Choosing an OSS license doesn’t need to be scary 来帮助开源项目开发者。
- 我想要一个简单宽松的许可证建议： MIT 许可证。这是一个宽松的、简明扼要的许可证，只要用户在项目副本中包含了版权声明和许可声明，他们就可以拿你的代码做任何想做的事情，你也无需承担任何责任。使用该许可证的项目：jQuery、Rails
- 我比较关心专利建议： Apache许可证。这类似于 MIT 许可证，但它同时还包含了贡献者向用户提供专利授权相关的条款。使用该许可证的项目：Apache、SVN和NuGet
- 我关心项目的共享改进建议：GPL（ V2或 V3）许可证。这是一种 copyleft 许可证，要求修改项目代码的用户再次分发源码或二进制代码时，必须公布他的相关修改。V3版本与V2类似，但其进一步约束了在某些限制软件更改的硬件上的使用范围。使用该许可证的项目：Linux、Git
- 我的开源项目不是代码建议： Creative Commons。这是一个相对宽松的版权协议。它只保留几种了权利（some rights reserved）。使用者可以明确知道所有者的权利，不容易侵犯对方的版权，作品可以得到有效传播。作为作者，你可以选择以下1~4种权利组合:1) 署名（Attribution，简写为BY）：必须提到原作者。2) 非商业用途（Noncommercial，简写为NC）：不得用于盈利性目的。3) 禁止演绎（No Derivative Works，简写为ND）：不得修改原作品, 不得再创作。4) 相同方式共享（Share Alike，简写为SA）：允许修改原作品，但必须使用相同的许可证发布。
- 更多选择Licenses - ChooseALicense.com，这里提供了Apache/ GPL/ MIT/ Artistic/ Eclipse/ BSD/ LGPL/ Mozilla/ No License/ Public Domain Dedication 协议的适用情形、许可内容、禁止内容，及协议全文。
开源规范 -- antd
贡献者行为准则
www.contributor-covenant.org/version/1/4…
总结一下：
- 营造开放和受欢迎的环境，拒绝各种歧视！
- 尊重不同的观点和经历
- 专注于对社区最有帮助的事
- 团结社区其他成员
- 拒绝一切 色情，侮辱，贬损以及人身攻击
代码规范
参与开源时需要关注什么？
1. 命名规范：变量、函数、类、文件等的命名规范，包括驼峰命名、下划线命名等。
2. 缩进和空格：代码缩进的规范，以及空格的使用规范，如缩进长度、空格的使用等。
3. 注释规范：代码注释的规范，包括单行注释、多行注释的使用规范，以及注释的内容和格式。
4. 代码风格：代码的书写风格，包括代码块的格式、代码的对齐方式、代码的简洁性等。
5. 文件组织：前端项目文件的组织规范，包括目录结构、文件命名等。
6. 代码质量：代码的质量标准，包括避免重复代码、遵循最佳实践、性能优化等。
CodeReview
大家聊聊怎么cr？
不知道如何cr？
参与度？
请教一下！！！
命名规范
文档 规范
1. 项目介绍：包括项目的名称、描述、特点、用途等。
2. 安装和配置：详细说明如何安装和配置项目，包括依赖项的安装、环境配置等。
3. 快速开始：提供一个快速上手指南，介绍如何使用项目进行开发或集成到现有项目中。
4. 使用说明：详细介绍项目的各项功能和用法，包括API文档、组件说明等。
5. 示例和演示：提供示例代码和演示，帮助用户更好地理解项目的使用方法。
6. 贡献指南：说明如何参与项目的贡献，包括如何报告问题、提交改进建议、参与代码贡献等。
7. 版本历史：记录项目的版本历史和更新日志，包括每个版本的改动和更新内容。
8. 许可证信息：明确项目的开源许可证类型，以及使用和分发的规定。
9. 社区和支持：提供项目的社区支持信息，包括联系方式、社交媒体链接等。
版本控制规范
1. 选择版本控制系统：明确选择使用的版本控制系统，如Git，以及相应的使用规范。
2. 分支管理：规定分支的命名规范，如主分支、开发分支、特性分支等，以及分支的创建、合并和删除规范。
3. 提交信息规范：规定提交信息的格式和内容，包括清晰的描述提交的改动内容，避免不必要的提交，以及关联的Issue或任务编号。
4. 版本号规范：定义版本号的规范，如语义化版本号规范（Semantic Versioning），明确版本号的含义和更新规则。
5. 代码审查：规定代码审查的流程和标准，包括谁来进行审查、审查的频率和方式等。
6. 持续集成：规定持续集成的规范，包括自动化构建、测试和部署的流程和工具。
7. 发布流程：定义版本发布的流程和规范，包括如何打标签、生成发布文档、发布到仓库等。
NPM版本号
npm版本号的组成
一个完整的版本号，由三部分组成：主版本号（major）、次版本号(minor)、修订版本号(patch)，简称X.Y.Z，具体含义：
- 主版本号（major）：项目（包）做了大量的变更，与旧的版本存在一定的不兼容性等问题。
- 次版本号（minor）：做了少量的变更或向下做了兼容。
- 修订版本号（patch）：修复上一个版本的bug或向下做兼容。
版本号变更的一般规则：
- 版本号只升不降，不得在数字前面加0。例如不能是
1.01.0，应该是1.0.0。 - 当主版本号升级时，次版本号和修订版本号需要归零。例如
1.1.1->2.0.0。 - 当次版本号升级时，主版本号不变，修订版本号归零。例如
1.1.1->1.2.0。 - 当修订版本号升级时，主版本和次版本号都不变。例如
1.1.1->1.1.2。 - 一般第一个正式版本应为
1.0.0。 - 处于开发测试阶段的版本一般为
0.y.z，如果不发布，则默认为0.0.0，如果发布第一个测试版本则是0.1.0，如果修复第一个测试版本则是0.1.1，如果更新第二个测试版本则是0.2.0。
版本标识符（标签）
格式：Major.Minor.Patch-Identifier.1，其中Identifier就是代表标识符，和版本号之间使用-隔离，后面则是当前标识符的版本版本号，每升级一次则+1
| 标识符 | 含义 | 说明 |
|---|---|---|
| demo | demo版本 | 用于验证问题的版本 |
| dev | 开发版 | 多用于开发阶段，bug较多，功能不完善 |
| alpha | α版本 | 内部版本，测试用，代表当前可能有很大的变动 |
| beta | 测试版本（β版本） | 测试版本，代表版本已开始稳定，但是还有bug |
| stable | 稳定版本 | |
| latest | 最新版本 | 安装时不知道版本号时的默认安装最新版本 |
版本运算符
版本运算符一般是指定一定范围的版本号，主要有~、-、^、<、>等。
~ 版本号只指定主版本号或者次版本号，例如：
| 版本范围 | 匹配版本号 |
|---|---|
| ~2 | 2.Y 或者 2.0.0 ≤ V < 3.0.0 |
| ~2.1 | 2.1.Z 或者 2.1.0 ≤ V < 2.2.0 |
| ~2.1.1 | 2.1.1 ≤ V < 2.2.0 |
^ 版本号 匹配第一个非0版本号
| 版本范围 | 匹配版本号 |
|---|---|
| ^2.1.2 | 2.1.2 ≤ V < 3.0.0 |
| ^0.1.2 | 0.1.2 ≤ V < 0.2.0 |
| ^2.Y.Z | 2.0.0 ≤ V < 3.0.0 |
npm 安装包时，默认使用 ^ 匹配版本。
~ 与 ^ 对比
| 版本范围 | 匹配版本号 | 说明 |
|---|---|---|
| ~2.1.0 | 2.1.0 ≤ V < 2.2.0 | 主版本号和次版本号相同 |
| ^2.1.0 | 2.1.0 ≤ V < 3.0.0 | 主版本号相同 |
测试规范
1. 单元测试规范：定义单元测试的编写规范，包括测试用例的命名、结构、覆盖率要求等。
2. 集成测试规范：规定集成测试的范围和方式，包括与其他组件或服务的集成测试、UI测试等。
3. 端到端测试规范：定义端到端测试的规范，包括模拟用户行为、跨组件交互测试等。
4. 测试工具和框架：确定使用的测试工具和框架，如Jest、Mocha、Selenium等，并规定其使用规范。
5. 测试覆盖率要求：明确测试覆盖率的要求，包括单元测试覆盖率、集成测试覆盖率等。
6. 持续集成和持续部署：将测试纳入持续集成和持续部署流程，确保每次代码提交都能进行自动化测试。
7. 测试报告和反馈：规定测试报告的格式和内容，以及如何处理测试结果和反馈
发布规范
1. 版本号规范：定义版本号的规范，如语义化版本号规范（Semantic Versioning），明确版本号的含义和更新规则。
2. 发布流程：明确发布的流程和步骤，包括如何打标签、生成发布文档、发布到仓库等。
3. 发布频率：规定发布的频率和时机，如定期发布、根据功能完整度发布等。
4. 发布文档：规定发布文档的内容和格式，包括更新内容、改动说明、兼容性说明等。
5. 回滚策略：定义发布失败时的回滚策略，包括如何快速回滚到上一个稳定版本。
6. 版本管理：确定如何管理不同版本的发布，包括维护旧版本、废弃旧版本等。
7. 发布环境：规定发布的环境和条件，如测试环境、预发布环境、生产环境等。
如何参与开源
- 请仔细阅读你参与的开源项目的贡献指南
- 请关注你目前项目中的痛点，如果有时间，不要绕过他。
- 查看项目github仓库的issue。提出问题本身就是一种贡献。
- 试图了解你所使用开源项目的项目结构及设计思路，方便自己排查问题。
参考资料
开源协议： juejin.cn/post/684490…
npm版本：juejin.cn/post/722692…
chatGpt ：cursor
antdsign
