第05课:项目在 GitHub

什么是项目 ?

  • 有用 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 Driven Development

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

所以, 面向自述的开发是好的:

  • 一个项目仓库的第一重要文件
  • 必须是 README.md
  • 自述文档的认真程度直接体现了项目自身的靠谱程度

在 GitHub 中的项目生命周期?

名字起的好,项目活的久

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

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

提问

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

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

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

评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符 “速评一下”
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页