为更好促进gorpc框架及配套工具发展，我们欢迎所有对感兴趣的同学加入gorpc框架的体验、开发、维护中来，特别是那些愿意牺牲个人宝贵时间为框架完善作出努力的开发者。不管是提出有价值的issue、bugfix、文档完善、补充测试用例、编写demo，还是对前沿技术进行调研、提出新特性需求，都是我们乐于见到的。
当然我们更希望符合以下条件的开发者能够主动参与，分享所学所想：
- 对golang了解深刻，热爱技术、热爱钻研
- 知识面较广，对同类开源有研究或涉猎
- 追求完美，对代码精益求精
- 愿意了解掌握gorpc框架及工具源码
- 愿意贡献自己业余时间投入框架开发，在github保持活跃
我们希望通过开源来博采众长让它变得更好，希望我们的共同努力可以让“开发”变得更好。
本项目主要使用Issue进行交流沟通。
我们的基本协作方式基于github展开：
- 提出ISSUE
- 提ISSUE之前，请务必先搜索是否已经存在近似描述的ISSUE，如果已经存在可以在ISSUE下补充描述，请避免重复提相同ISSUE的问题；
- 新建ISSUE的时候，请根据问题类型选择ISSUE模板，如新特性、Bug、优化建议等，并根据模板内容填写信息，方便我们高效地进行协作；
- 解决ISSUE
- 首先需要Fork主仓库到自己的仓库中，并定期保持代码库更新；
- 当准备解决一个ISSUE前请务必确认是否ISSUE是否被开发者认领，考虑到大家可能提出不同的解决方案，方案探讨可以在同一个ISSUE下进行，避免重复处理同一个问题；
- 在决定将内容推送到本仓库时，请先拉取本仓库代码进行合并，并处理好冲突，同时确保相关文档与代码保持同步；
- 然后再将分支PR到主仓库的master分支，其中PR需要包含以下基本信息：
- 标题：本次PR的目的（做了什么工作，修复了什么问题）；
- 内容：如果必要的话，请给出对修复问题的描述，力求简短清晰；
-
项目维护人员在PR评论区进行评论，如果发现PR中有什么问题，请直接指出并尽量给出修正的方式，或者也可以直接进行修改；
-
提出该PR的人根据评论修正内容，然后将修改后的内容Merge到master分支中；
-
项目维护人员审核通过，合并PR到主仓库中；
- 代码提交时必须填写精炼的commit信息，遵循如下规范:
- commit信息构成
<type>(<scope>): <subject> (<BLANK LINE>) (<body>) 其中<subject>是必填信息，我们建议填写<type>以及影响的<scope>。<body>部分是可选的，如果有必要的话，用来详细描述本次做的修改。<body>前应留有空行。-
可选的包括:
- feat: 新功能
- fix: 修补bug
- doc: 文档
- refactor：重构(既不是新增功能，也不是修补bug)
- test：增加单元用例
- style: 格式化
-
请根据修改影响到的模块范围来确定，如：
- client
- server
- connpool
- logging
- interceptor
- tracing
- metrics
- ...
- cli
-
<subject>：subject是commit目的的剪短描述，力求精炼，最好不超过50个字符；
-
<body>：是对commit目的的详细描述，可以分成多行；
-
具体事例如下：
如果本次改动内容比较大，或者需要强调一下，可以在body中详细描述：doc(install): README增加安装指引feat: 新增Selector、、Registry接口 用于实现服务注册、发现... - 每次Pull Request应只解决一个问题，这样方便进行修改；
- 每次Pull Request应确保已经同步过主仓库代码、解决冲突，并自己在本地测试通过；
- 根据贡献者的活跃程度、对框架贡献熟悉程度，我们会筛选一部分开发者加入项目维护人员列表中来；
希望热爱开源并对gorpc感兴趣的同学一起加入进来，共同参与gorpc的相关建设，让“开发”变得更简单美好。