什么是项目 ?
- 有用 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 文化培育下发展形成的
- Shields.io: Quality metadata badges for open source projects
- 徽章 图标…….
- 一个完备的自述文档至少应该包含
在 GitHub 中的项目生命周期?
名字起的好,项目活的久
当然, 最要紧的是你的项目至少吻合两个条件:
有趣
有用
有种
- 如果三个都吻合, 那简直了…… star 积累的速度一定快过你的 push 次数
- 进入 awesome 的速度也一定非常快
- 然后接盘侠也排队来
- 那么项目就可以永生了……
提问
~ 是的, GitQ 不是单向灌输, 双向交流才真诚
- 在 GitHub 中不合适组织哪种项目?
- 项目协同中还有什么必要功能是 GitHub 还不支持的?
- 如果你来增强 GitHub ,最想要的那个项目支持功能是什么?
欢迎大家来我的读者圈评论作答或提问交流 ~