CNBorn|我不是大牛

很早就听说过 Getting Real 这本书，但是开始认真阅读却是在启动自己的个人项目之后。赫然发现自己在项目中采取的一些原则和方法，原来早有类似的理论支持。当然，Getting Real 的理论更实际、也更加全面，毕竟是真正的经验之谈。此后这本书就成为了我时常阅读的材料之一。

刚开始翻阅 Getting Real 中文版的时候，发现它并没有翻译完整。而英文部分非常简单，也就没怎么在意。最近由于想要整理一些想法和知识，再次翻出Getting Real 这本书，突然觉得想为这本书做些什么。想到虽然官方的未完成版中文翻译阅读起来也没有太大的问题。但作为一个翻译版本，没有翻译完整总是让人感到遗憾。于是在网上寻找是否有未完成的中文部分的工作项目。发现了两个项目，其中一个架设在Google Groups的项目很久没有更新。而译言上关于这本书的项目却十分出色，翻译工作更是已几近完成。只是不知为什么没有能够最终进行修订、和已有的中文翻译整合。于是决定自己来做这项工作

事实上这并不是一个非常复杂的工作，剩下的翻译工作已经很少，而修订工作需要的，更多的是耐心和专注。主要修订一些明显需要优化的地方，如将"《一个实用编程者》"这样的翻译，改为大家认可度更高的"《程序员修炼之道》"等。

而目前我最关注的还是版权问题。由于这本书并不是CC授权，所以用Wiki这种形式来进行翻译及校对工作并不适宜。这个中文版本中原有翻译者的署名会保留，同时他们的工作会在文档中进行详细的描述（见中文版最后的"整合中文版编后"段落）。而经由我以及未来可能由更多参与者所做的一些修订也会尽力详细列出。未来在整个翻译、校对工作进行到一个比较好的阶段的时候，我会开始联系37signals，尝试把这个工作作为最终的官方中文版发布。

在最近和朋友们的一些讨论中，我再次感觉到了让更多的人了解Getting Real的必要。有太多的Web活软件项目正在变得非常庞大，以至于他们被无数的小特性冲晕了头脑，使得把握一个产品最核心的方向这样本质的行为几乎变成了不可能。我觉得Getting Real里讲述到的一些东西，非常适合一些大公司用来作一些思考：为什么更大的机构在很多时候没有更高的效率？为什么他们的产品会被小公司打得落花流水？如何唤回他们曾经是小团队时的战斗力？很多此书中的观点，更像是在经历了软件和Web项目无比复杂化之后，一种清新的思想回归。得以让人们重新发现，在他们没有宽敞的办公室之前，那些满腹理想的小团队时期真正宝贵的核心竞争力所在。

点此查看完整的 Getting Real 中文版，对这个项目有任何的意见或建议，欢迎与我联系。

Bugzilla是一个经典的软件缺陷追踪工具，最初版本由Netscape开发，1998年遵循Mozilla Public License协议公开源代码。Bugzilla作为功能强大的Bug Tracking系统，在无数的商业/非商业组织和项目中得到广泛的应用。

Bugzilla 系统中默认的设计是可将所有的信息对任何人开放，但是针对用户应用需求的不同，可以针对不同产品设置不同的权限设定。可以适用于如：在一个大公司的多个软 件项目组，通过一个全公司的Bugzilla系统来追踪各个项目的Bug，各个组之间的人员并不能查看或编辑其它组的内容等类似情况。

事实上Bugzilla 网站上的手册里针对此部分有很详细的说明，但是我在使用中发现，互联网上还没有对此进行介绍的较为详细的文章，同时如果没有通过实际的例子来将设置方法加 以展示的话，整个设置和对照英文文档的过程还是让人感觉晦涩及难以理解。所以本篇文章将以Bugzilla系统应用中的实例来讲解下如何对不同产品的权限 进行设定。

（本篇文章的内容在Bugzilla 3.2,3.2.3中测试完成，Bugzilla后续版本可能会对此部分功能进行变更，请在使用及部署中注意）

本文目的与要求：

通过实例讲述在Bugzilla系统中如何针对用户应用需求的不同，针对不同产品设置不同的权限。

您需要对Bugzilla有简单的了解和部署经验，并且已经在开始使用Bugzilla。本文中不会针对个别选项、设置进行事无巨细的探讨，也不保证所讲述 的内容涉及到权限设置部分的各个方面。仅以一些实例，为各位Bugzilla用户在各自的应用中起到一些抛砖引玉的作用。

设置不同组权限设置的前提要求：

    首先需要完成Bugzilla里的分组设置。如可根据用户的不同分为"质量"、"前端"、"测试"等不同的用户组。用户可以同属为多个组。组的分类可以和 要提交问题的产品相关，如针对"质量"的问题，会有一个对应的"质量"人员组；也可以和问题不相关，如通常为了管理方便，我会创建一个"部门主管"组（可 查看所有记录）、以及"所有用户"组（通过通配符 .* 匹配所有用户，在使用中可简化一些设置）。以下的几个实例的解决方法，会遵循我在这里的用户组设计。

    如需设置组分类和产品分类相对应，可启用Bugzilla->管理->参数设置->组安全设置 中的makeproductgroups选项。启用此选项后，每创建一个新产品，系统均会自动在用户组中创建一个与此产品对应的用户组。

产品分组权限设置页面：

    无特殊说明，均在Bugzilla->管理->产品管理->产品页面->编辑组访问控制页面中

权限设计需求实例:

1. 每个用户都可以提交不同产品的Bug
   
2. 所有用户均可编辑问题/只有相应组的用户才能编辑相应的问题
3. 所有用户在提交问题时，均可选择此问题是否针对其它各个部门的人员可见
4. 产品严格分组，不同的产品组只能查看相应组的产品Bug信息 - 此范例来自 Bugzilla官方手册
5. 创建一个只读产品（此产品的相关信息只能查看，不能提交和修改）- 此范例来自 Bugzilla官方手册
   

问题1解决：

    选中"所有用户"组的Entry选项

问题1解决说明：
    
    Entry 选项决定了一个组的用户是否有权限可以针对一个产品提交问题。同时如果有至少一个组选择了Entry这个选项的话，那么其它没有选择的组均无法针对此产品提出问题


问题2解决：

    所有用户均可编辑问题：选中"所有用户"组的editbugs选项
    只有相应组的用户才能编辑相应的问题：依次编辑各个产品，选中相应组的Editbug选项

      
问题2解决说明：

    Editbug 以及 editbugs 两个选项的差别：

• 当有任何一个组选择了Editbug选项后，其它未选择的组均无法编辑此产品
• 如果有一个组选择了editbugs以后，该组即可编辑此产品的所有问题

问题3解决

    修改相应其他组的MemberControl、OtherControl权限

    这两个权限各有三个选项

    简单说明，
    一个组的MemberControl指操作中用户属于这个组时，
        Default指可以在界面上选择此组用户是否可查看此产品问题，并且默认此选项选中
        Mandatory指在界面上无法选择此组用户是否可查看此产品问题，但此问题设置为强制与此组用户相关
        Show指可以在界面上选择此组用户是否可查看此产品问题，并且默认此选项不选中
        N/A指与此组完全没有关系，无法访问

    一个组的MemberControl指操作中的用户不属于这个组时的情况，三个选项和上面的相同。


    举个例子

        倘若有一个"主管"用户组，可查看/编辑所有提交的信息（并且此设置不可能由其它用户或相关的Bug提交者所改变），权限可设置为

            主管 Mandatogy Mandatory editbugs

        倘若有一个问题，可能需要"质量"、"前端"组用户查看，但需要提交此问题的用户（所有用户，可以不是这两个组的成员）在提交时进行设置。同时还不需要让"程序"组的用户查看，那么权限可设置为

            质量 Shown Shown
            前端 Shown Shown
            程序 N/A N/A
            所有用户 Entry (或设置为 除"程序"组以外的其他组均可以Entry)

     针对问题三的情况，应该设置成为：

        对其他可能会与此问题相关的用户组，权限设置成为 Shown Shown
        这样在提交问题时，选项里就会出现"是否让一下组查看问题"的选项了。


问题4解决：(此问题可视作问题3里设置权限的例子的一个延续)

   

问题5解决：(此问题可视作问题3里设置权限的例子的一个延续)

        创建一个用户组，名为"只读"。将需要设置权限的产品设置为

        只读 Entry, N/A N/A, CanEdit

        简单说明
                Entry及CanEdit均为排他设置，只要确保"只读"组没有用户，即可实现无用户可提交和编辑此产品的Bug信息。

Mozilla官方手册中还有不少权限设置的实例，相信在读完以上部分以后，理解Mozilla的说明会更加方便一些。

本文的大多数内容均经过我的实验，但是仅供参考之用，我不能确定文章中的所有设置均正确并适应您的需求，总的来说，Bugzilla的设置，还需要在实践中加以揣摩。

在日后时间宽裕时可能会对此文章进行进一步补充。如对此文章由什么意见或纠正，欢迎留言或直接给我写信，我的邮箱是 我的英文ID@gmail.com

最后需要明确的是"产品"这个概念。我在工作中搭建的Bugzilla系统均不是应用于软件开发领域，而是对流程中的问题进行追踪。"产品"这个在 Bugzilla中的概念，可能在Bugzilla系统根据用户需求进行定制的过程中被其它文字替换。关于针对Bugzilla系统进行定制的更多信息， 欢迎查看这篇文章：OpenParty "有狐"，在此次活动中，我进行了一个"Bugzilla系统部署、定制"的演讲，具体的介绍幻灯片可以查看这里《Bugzilla @ Customization》。

作者：CNBorn，bugzilla-cn (Bugzilla中文本地化)项目组成员


主要参考文档

本文中Bugzilla的中文翻译均来自 bugzilla-cn (Bugzilla中文本地化项目)

Bugzilla官方文档中对于产品组权限部分的说明(Bugzilla 3.2) http://www.bugzilla.org/docs/3.2/en/html/products.html#product-group-controls

Bugzilla权限管理讨论，这个是我在中文互联网上发现的少见的关于此问题的帖子，只有2句话，总结得不错 http://topic.csdn.net/t/20061226/23/5258177.html

这次的OpenParty活动，内容异彩纷呈。更重要的是，有了豆瓣架构技术路线等QCon等会议上的精彩演讲，这次的OpenParty被大家戏称为"小QCon"

简单谈一下，认真聆听的两个Topic。

豆瓣技术架构演变，相信基本上这次来OpenParty的朋友基本也是冲着这个话题来的。开始自己还有些担心，这个毕竟是在需要门票才能参加的QCon上面 的王牌演讲，会完美地搬到免费的OpenParty来么？结果自然出乎我的意料，豆瓣的洪强宁大牛毫无保留，为我们带来了一场原汁原味的精彩讲演。至于为 什么这个演讲到哪里都会受到欢迎，我想一个最主要的原因是，这个说明从豆瓣最初的架构实例开始，直到现今豆瓣的架构，整个介绍没有任何枯燥的说教、概念， 对于任何对Web构建有一点经验的人员就可以很容易地明白和了解整个的框架结构，非常难能可贵。

豆瓣从上线到现在，随着用户的增长，期间出现的问题可以说覆盖了各种在网站架构需要扩展时所需要的问题，从I/O、CPU、架构到机房，这些实战的经验， 对于立志做Web的人来说，无比宝贵。从Lighttpd到Nginx，从Spread到rabbitMQ，从MogileFS到DoubanFS，期间 豆瓣实际上没有使用任何非常前沿甚至过激的技术，"使用熟悉的技术来解决问题"作为豆瓣的宗旨，可以感觉出整个团队对于技术把握的自信，很一种真真正正的 脚踏实地的感觉。

糖醋鼻子的"卡片机摄影"专题在上次的OpenParty上就已经十分期待，这次成功登录，终于如愿以偿。出乎我意料的 是，糖醋朋友的整个话题讲解，实际上完全不是局限于"卡片机"这个概念，而首先，从"摄影"这个活动最基本、没有人轻易想到的核心方面开始谈起，把摄影与 中国文化传统定义的琴棋书画统一起来，成为我们在新时代追求的文化元素之一。其间所包含的构图等原则更让我觉得糖醋在摄影这些基本功上的研究和努力非常值 得一般爱好摄影的朋友学习。这对于图片的修改一节，糖醋更是放出了很多非常精彩的图片修改，很多技巧非常简单，如剪裁、对比等，但是综合到之前提到的构图 等原则，就可以十分简单地作出一些让人震惊的效果，非常值得推崇。

期待糖醋同学可以早日放出介绍的slides，也欢迎大家到他的Google PicasaWeb上参观学习：http://picasaweb.google.com/zhmocean

离开的时候和OpenParty的组织者之一，icecloud聊了下OpenParty现在的情况。我认为现在OpenParty的状态非常的好，有着很高的知名度。但想起以前看cleverpig的 那篇文章，清楚这些都是由默默地为大家提供帮助的OpenParty组织者们，牺牲了无数的时间和经历做到的。我想在这里向他们致敬，同时在未来，尽可能 用自己力所能及的方式，来帮助OpenParty，就像上次我的Bugzilla演讲，以及这几次OpenParty的见闻文章这样。