本文共 1480 字，大约阅读时间需要 4 分钟。

什么是项目 ？

• 有用 item 的
• 有用 project 的
• 也有用 case 的
• 但是， 从 MVP 原则来看， 可以称为项目的事物和社区非常接近：
  • 有相对固定的目标
  • 由相对固定的成员
  • 在相对固定的场所
  • 进行相对固定的嗯哼
• 好吧翻译过来，就是：
  • 有明确的目标
  • 通过具体的人
  • 持续协同努力
  • 最终完成可完成的那什么……

应该包含什么？

~ 和开源社区一样

基础建设也是相通的：

• repo. ~ 代码仓库追踪工作物件
• issue ~ 追踪行为
• wiki ~ 积累内部知识
• mailling-list ~ 勾陈所有外部注意力
  • GitHub 中可以通过仓库配置，简洁的关联指定的外部列表
  • 完成这一古老的沟通渠道贯通！

问题是以上资源的关系？

(No.0) 微信/Teletram/邮件/电话 任何沟通场景中     ^ \    |  +- 触发策划/创想/改进点/文案/任务    |     |       |     +- (No.1) 在issue 或是列表中具体描述     ^      \    |        +- 审核完毕后(直接增补，或是评注确认)主动认领开工    |           |    ^           +- (No.2) 本地调试通过后， push 到 仓库    |              |- 在列表中回复对应线索， 给出 commitlog 链接    |              |- 微信/telegram 中提醒    |             /    +-----<------+

是的， 一个必须越来越快的循环……

核心要素是什么？

生产力的核心要素永远是人!

GitHub 组织开源/闭源项目也一样， 和矿工一样， 只有高素质的成员， 才可能发挥 GitHub 精心制备好的各种功能

• Git 都不会的成员， 删除仓库是分分钟钟的事儿
• Markdown 都不会的成员， 弄乱 issue/wiki 是分分钟钟的事儿
• 编程都不会的成员， 改乱代码， 简直就是宿命！
• ……

所以， 可能真正的现实是：

• 在 GitHub 中作什么不重要
• 要命的是和谁一起作
• 这可能也是绝大多数项目都是单人项目的原因吧……
• 当然， 这也是 GitHub 开创性的发明了 Pull-Request 协同模式的一个动因：
  • 世界上靠谱的好人如此少
  • 与其通过权限来控制准入
  • 不如通过代码来自我证明靠谱程度

GitHub 对项目的理解

~

说不清楚的说明没想明白写不清楚的一定无法开发

所以， 面向自述的开发是好的：

• 一个项目仓库的第一重要文件
• 必须是 README.md
• 自述文档的认真程度直接体现了项目自身的靠谱程度
  • 一个完备的自述文档至少应该包含
    • 综述
    • 安装
    • 运行
    • 文档/案例/……链接
    • 参考资料
    • 许可证
  • 以及：
    • 在 RDD 文化培育下发展形成的
    • 徽章 图标…….

在 GitHub 中的项目生命周期？

名字起的好，项目活的久

当然， 最要紧的是你的项目至少吻合两个条件：

有趣有用有种

• 如果三个都吻合， 那简直了…… star 积累的速度一定快过你的 push 次数
• 进入 awesome 的速度也一定非常快
• 然后接盘侠也排队来
• 那么项目就可以永生了……

提问

~ 是的， GitQ 不是单向灌输， 双向交流才真诚

• 在 GitHub 中不合适组织哪种项目？
• 项目协同中还有什么必要功能是 GitHub 还不支持的？
• 如果你来增强 GitHub ，最想要的那个项目支持功能是什么？

欢迎大家来我的读者圈评论作答或提问交流 ~

转载地址：https://blog.csdn.net/zoomquiet/article/details/108729661 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！