题目维护

从 Trac 迁移的文章

这是从旧校内 Wiki 迁移的文章，可能存在一些样式问题，您可以向 memset0 反馈。

原文章内容如下：

[[TracNav(TOC)]]

= 为什么要用这玩意 =

虽然我们都希望做题的时候代码能够一次写好，编译通过，提交AC。但无论你是怎样的牛，有多少的经验，也不可能次次做到。更不要是出题这么复杂的工作，虽然经过了自己的反复校验，组内的验证和修改，最后难免还会有问题。尤其是出题人，验题人和做题人看问题的角度和对题目的理解往往是不同的。题目有的时候需要加强数据，有的时候我们发现这道题可以出得更难/更有趣放到月赛去，更多的时候是题目描述有语法错误或模棱两可。往年对这些问题的修改主要依靠赛后组长更具大家比赛中反映的问题简单的修改一下，依然存在的问题可能由教练提醒修改，实在还有问题就只能再forum上发贴催。但forum因为内容多，且这类帖子很容易就沉下去了，效率不高，一个一个pm，发邮件太烦人，导致问题难以解决，或最后也没有解决，或者原本想要解决，最后却忘了。现在起，我们引入项目中对issue/bug的管理，以尝试一种更高效系统的办法来维护我们暑期集训所出的月赛备选题目。

你可能需要先看一下[wiki:TracTickets]和[wiki:TracWorkflow]，还需要了解一下[wiki:WikiFormatting]。

= 怎样发bug =

>> [[Image(open-ticket-demo.jpg)]]

注意不要把几个不同的bug发到同一个，因为他们可能有不同的优先级，而且可能不会同时fix。保持每个ticket有合适的粒度。

= 一般操作 =

1. 【OPEN】就是发一个bug，不一定要bug，任意合适的问题都可以，assign to你认为合适的人，也可以是你自己，由这个人执行【SWITCH】：

2. 【SWITCH】一个人收到了别人assign给自己的bug时，分析一下，通常可以回复(reply)你的看法，并做出如下操作
  a. 【Accept1】你认为这是一个bug，并准备修复，通常你还可以对细节做出修改，比如优先级等，然后执行【ACCEPT】
  b. 【Reassign1】你觉得这个问题应该交给一个更合适的人选，于是reassign给他，由他执行【SWITCH】
  c. 【Close1】这不是一个bug，或者这个bug已经发过了（重复/tooold），不存在这个bug（rpwt），或者根本无法修复（不搞了），那么请选择相应的resolve，这个bug将被close，执行【CLOSE】

3. 【CLOSE】close bug后通常把bug assign to发这个bug的人，又他来确定这个bug已经fix，那么才close，否则【REOPEN】

4. 【REOPEN】任何人觉得bug还不能close，那么reopen之，回复原因，并可以assign to合适的人，执行【SWITCH】

5. 【ACCEPT】那么这个bug应该进入修复阶段，也可以继续讨论，如果内容比较多的话，可以考虑再forum开一个楼专门讨论这个bug，把楼的链接贴过来就好了，否则会收到太多邮件
  a. 【Close2】bug修复好后进入【CLOSE】
  b. 【Other2】对其它情况执行，执行合适的操作

6. 【Other】规矩是死的，人是活的

其实回复就和大家再论坛里讨论问题差不多，唯一的区别就是对ticket那些状态的修改。所以关键就是理解并合理利用这些状态啦。


[wiki:TracWorkflow#TheDefaultTicketWorkflow]

= [wiki:预习作业] =
[wiki:预习作业]

为什么要用这玩意

虽然我们都希望做题的时候代码能够一次写好，编译通过，提交AC。但无论你是怎样的牛，有多少的经验，也不可能次次做到。更不要是出题这么复杂的工作，虽然经过了自己的反复校验，组内的验证和修改，最后难免还会有问题。尤其是出题人，验题人和做题人看问题的角度和对题目的理解往往是不同的。题目有的时候需要加强数据，有的时候我们发现这道题可以出得更难/更有趣放到月赛去，更多的时候是题目描述有语法错误或模棱两可。往年对这些问题的修改主要依靠赛后组长更具大家比赛中反映的问题简单的修改一下，依然存在的问题可能由教练提醒修改，实在还有问题就只能再forum上发贴催。但forum因为内容多，且这类帖子很容易就沉下去了，效率不高，一个一个pm，发邮件太烦人，导致问题难以解决，或最后也没有解决，或者原本想要解决，最后却忘了。现在起，我们引入项目中对issue/bug的管理，以尝试一种更高效系统的办法来维护我们暑期集训所出的月赛备选题目。

你可能需要先看一下TracTickets和TracWorkflow，还需要了解一下WikiFormatting。