
肯塔基州路易斯维尔
Greg 是肯塔基州路易斯维尔的一位退休神经科医生,他对计算机和编程有着长期的兴趣,从 1960 年代的 Fortran IV 开始。当 Linux 和开源软件出现时,它激发了他学习更多知识,并最终做出贡献的承诺。他是 Scribus 团队的成员。
Greg 是肯塔基州路易斯维尔的一位退休神经科医生,他对计算机和编程有着长期的兴趣,从 1960 年代的 Fortran IV 开始。当 Linux 和开源软件出现时,它激发了他学习更多知识,并最终做出贡献的承诺。他是 Scribus 团队的成员。
作者评论
至少有两个受众需要文档来服务:新手和经验丰富的用户。第一组需要一个简单的 HOWTO 式结构,逐步完成一个过程。第二组需要更多的参考,更少的细节(或能够扫描大量材料的能力),以及多个入口点。
同时满足这两种需求并非不可能,但具有挑战性。有时您需要考虑创建多个版本的信息。拥有像链接一样的东西也很有帮助,其中提供了更多细节,但未包含在信息的主流中。
这些关于 README 的想法都很好,但可能高估了 README 的价值,期望它成为“统治一切的文档”。
项目应为用户提供多种信息入口途径——邮件列表、报告错误和提出功能请求的地方、做出贡献的地方,以及在任何官方文档编写和开发层级中上升的能力。与所有这些同样重要的是,甚至可能更重要的是,流程的心理学。用户应该得到问题的回复,并鼓励他们继续这样做。我不时尝试在邮件列表中做的一件事是消除海报之间粗鲁的语言(通常是无意的)。