ManualIntroductionCN

Up: UserManualCN --- Next: ManualRequirementsCN

---

Welcome to Request Tracker(RT), your new favorite ticketing system. This introductory chapter will explain what ticketing is and what RT is. If you're already familiar with RT, you can skip ahead to another chapter.

欢迎光临 Request Tracker(RT)，您最喜爱的新票务系统。这个介绍章节将解释票务是什么和 RT 是什么。如果您已经很熟悉RT，您可以跳到其他章节。

关于票务

When people say "ticketing," they're talking about buying a stub of paper that gets them into an event. Our type of ticketing is a way for organizations to keep track of their to-do lists, who is working on which tasks, what's already been done, and when tasks were completed. You will also hear the phrase "trouble ticketing" bandied about, though there does not have to be a problem for ticketing to be useful. The current common phrase seems to be "issue tracking".

当人们说“票务”的时候，他们正在聊关于买一张可以让他们进入一个项目的单据。我们的票务的种类是团队持续跟踪他们的任务列表的一个手段，谁正在做哪个任务，什么已经做好，和任务什么时候完成。您大概也听过“trouble ticketing”这种说法，虽然没有必须有一个有用的票务的问题。当前通常的说法似乎是“事务跟踪”。

Ticketing can make life easier for many people and departments in an organization -- basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs and answering customer service requests.

票务能让一个组织里的很多人和部门的生活变得更简单——起码是那些需要跟踪一揽子任务的人。并且它可用于各种任务，像修复软件错误和回答用户服务请求。

Since tickets are detailed records, you might not want to bother using it for one-off events ("Buy Bob in HR a going-away present.") You also shouldn't use it for tasks that are too broad ("Save world") or too granular ("Go to phone." "Pick up phone" "Lift finger." "Dial '9.'")

由于申请单（tickets）是详细的记录，您可能不想麻烦地为一次性事务而使用它（“给 HR 的 Bob 买一个离别礼物”）。您也不应该为太广泛（“拯救地球”）或者太细化（“到电话跟前”“拿起电话”“左手指”“拨9”）的任务而用它。

关于 RT

RT is a ticketing system for small- to medium-sized organizations. It is available under the terms of the GNU General Public License (GPL), so it doesn't cost anything to set up and use. We'll get into the technical features later, but for now, let's look at how RT might work:

RT是一个给中小型组织的票务系统。它在 GNU 的 General Public License(GPL) 条款下是可用的，因此它免费安装和使用。我们会在后面进入技术细节，但是现在，让我们看 RT 会如何工作：

• Billy has a problem with his Bananamaster 3000, so he sends email to help@example.com
• RT records the new issue in its database and sends Billy an electronic "ticket stub" containing the new ticket's ID number and, ideally, some helpful information. He can refer to the ticket stub if he needs to send another email later.
• RT forwards Billy's email to a set of staff members.
• One of the staff members, Jane, is the company's Bananamaster expert. So Jane takes over Billy's issue and drafts a reply to Billy, which RT automatically records and forwards to him.
• Billy is a happy customer; Jane resolves the issue and heads down to the pub for a pint.

• Billy 就他的 Bananamaster 3000有一个问题，因而他发送一个电邮到help@example.com
• RT记录该新问题在它的数据库并发送给 Billy 一个电子的包括该新申请单的ID号码和，理论上，一些有用的信息的“单据”。如果他以后需要发送另外的电子邮件，他可以关联该单据。
• RT 转发 Billy 的电子邮件给一伙职员。
• 其中一个职员，Jane，是公司的 Bananamaster 专家。因此 Jane 接管 Billy 的问题并起草一个回复给 Billy，RT自动地记录并转发给他。
• Billy 是一个幸福的用户；Jane 解决了问题并跑到酒吧喝了一杯。

This workflow is flexible, can be customized for your organization, and need not involve bananas.

这个工作流是灵活的，能为您的组织进行定制，并且不需要涉及香蕉。

RT概念

There are some words and phrases you should understand in the context of RT before you begin. See RTGlossary for more definitions.

在您开始前，您应该理解在 RT 背景下的一些单词和短语。参见 RTGlossaryCN 获得更多的描述。

A Ticket is the central object in RT, the thing that needs to get done. Tickets have metadata attached to them such as an owner, status, and queue - we'll get to all that in a minute.

在RT中，申请单TicketCN 是最重要的对象，这个必须清楚。申请单有依附于它们的元数据，例如承办人、状态和队列——我们马上都会聊到。

A Queue is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. For instance, you might have the right to create, delete, and comment on tickets in the Foo queue, but only the right to comment on tickets in the Bar queue.

队列QueueCN是RT的首要的管理的领域；它使得事情有条理。像名字所述，它是一排等待被工作的申请单，另一方面它也，有一点，申请单的范畴。例如，您可能在Foo队列中有创建、删除和注释(comment)申请单的权利，但是在 Bar 队列里只有注释的权利。

A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include when the ticket was created, how it has changed, and any comments about it or replies to it. Like real history, ticket history cannot be changed (at least not without messing up the space-time continuum), so be aware that any comments you make about a ticket are permanent.

申请单的历史听起来像是：一个申请单发生的一切。申请单历史的方方面面可能包括申请单什么时候被创建，如何改变，和任何关于它的注释或者回复。如同真实的历史，申请单的历史不能被改变（至少不能弄乱时空的连续性），因此要明白您对一个申请单的任何注释都是永久的。

Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff not visible to the requestor. This is useful when you want to be tactful but still convey important information, like, "This requestor is an investor, so be nice" or "This user's request mentioned his 'PC' but he really has a Mac."

申请单更新可以采取两种形式之一。回复是一个公开的请求者可以看到的评论。注释是一个对请求者不可见的给员工的隐秘的摘记。当您想赢得好感但是仍传递重要的信息时是有用的，如，“这个请求者是一个投资人，因此做好点”或者“这个用户的请求说他的‘PC’但是他实际上有一个 Mac。”

Priority, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer. The difference between 20. 50, and 75 may vary from organization to organization, but there should be an organizational policy or every ticket will get rated 99 by anxious users. ManualAdministration contains a useful model for setting organizational policy for priority.

优先级，一个申请单有多重要，用从0到99的数字表示，在此99是最高优先级。通过设置最终优先级，当一个申请单的到期日临近，您可以让它的优先级升高或者降低。从一个组织到另一个组织，20、50和75之间的差异可能不同，但是应该有一个组织的策略或者每个申请单都会由于焦急的用户而获得固定的99。ManualAdministrationCN 包括一个有用的设置组织优先级的策略的模型。

The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:

状态下拉式菜单提供几个分类每个申请单的选择。这是它们的含义：

• NEW: the ticket has just been created and hasn't been touched yet.
• OPEN: the ticket is getting worked on
• STALLED: due to circumstances beyond your control (waiting for the requestor to respond, waiting for the owner to return from Sri Lanka), the ticket isn't getting worked on right now. It will open again when someone adds a comment or reply.
• RESOLVED: hooray! Work on the ticket has been completed and is out of everyone's hair.
• REJECTED: the ticket is not the staff's problem and is not going to be resolved, but is, for some reason, worth recording in the system. For instance, if an employee asks approval for something ridiculous, you can reject the ticket, but it will stay in the database as evidence that the employee makes silly requests.
• DELETED: the ticket never should have been in the system (maybe it was spam, a list of passwords, etc) -- and is now being zapped for good.

• NEW: 申请单刚被创建并且还不能被接触到。
• OPEN: 申请单正在被工作。
• STALLED: 由于事情超出您的控制（等待请求者的回应，等待承办人从 Sri Lanka 回来），申请单现在不能被工作。当某人添加一个注释或者回复的时候，它会再次打开。
• RESOLVED: 万岁！处理的申请单已经被完成并每个人都不会烦了。
• REJECTED: 申请单不是员工的问题而且没有被解决，但是，由于某些原因，值得记录到系统里。例如，如果一个雇员要求批准某些荒谬的理由，您可以驳回该申请单，但是它会作为该雇员做了愚蠢的请求的证据留在数据库里。
• DELETED: 该申请单根本不应该在系统里（可能它是垃圾邮件，一个密码列表，等等）——并且现在最好干掉它。

A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:

一个 观察员 是对一个申请单有兴趣的某个人。当您查看一个申请单的时候，您会在“People”下找到这些提交。一个申请单的观察员通常会收到回复给该申请单的所有电子邮件的副本。观察员也是收到注释副本的员工。有几种观察员的类型，或角色：

• OWNER: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket it worked on, it may be passed from one owner to another.
• REQUESTOR: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.
• CC: someone (or someones) who should get copies of any replies that go to the requestor. This might be the requestor's boss, sales rep, etc. This person will see the emails but doesn't necessarily have the right to work on the ticket.
• ADMINCC: a Cc or Ccs that also gets copies of comments and generally are allowed to work on the ticket.

• OWNER: 负责申请单及其解决方案的人。每个申请单可以只有一个承办人。当申请单被工作的时候，它可以从一个承办人传递给另一个。
• REQUESTOR: 为了做完某事而请求的个人或人群；是申请单的原因。请求人通常收到所有给该申请单的回复的副本，但是没有注释。
• CC: 应该收到任何发给请求者的 回复 某人（或某些人）。可能是请求人的老板，推销员，等。这个人会看到电子邮件但不必有工作在该申请单的权利。
• ADMINCC: 一个抄送人或抄送人们，也收到 注释 的副本，并通常被允许工作在该申请单上。

We're hedging with words like "generally" and "necessarily" because any role can be assigned any right.

我们用单词“通常地”和“必要地”限定是因为任何角色可以被指派任何权利。

You can also, as you work on a ticket, define its relationship to something. Relationships in RT can be ticket-to-ticket, but can also link tickets to external items like URLs or FedEx shipping numbers. For the sake of simplicity, we'll refer only to tickets in the following explanation of relationship types:

您也可以，当您工作在一个申请单的时候，定义它的关系到某事。在RT中，关系可以申请单到申请单，但也可以链接申请单到外部项目像 URLs 或 FedEx 运送编号。为了精简，我们将只让申请单涉及下列关系类型的说明：

• DEPENDS ON: the ticket can't be resolved unless another ticket is also resolved. The converse is depended on by.
• REFERS TO: the ticket doesn't need the other ticket, but it would sure be useful for you to look at it. The converse is referred to by.
• PARENT: a big, general ticket ("Move house.")
• CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")

• DEPENDS ON: 申请单不能被解决，除非其他的申请也被解决。相反的说法是 DEPENDS ON BY。
• REFERS TO: 申请单不需要其他申请单，但是它会在您查看它的时候有用。相反的说法是 REFERS TO BY。
• PARENT: 一个大的全面的申请单（“搬家”）。
• CHILD: 一个父项目的子项目（“雇佣搬运工”，“打包”，“吃匹萨”）。

CustomFields are, yes, database fields that your organization can make up according to its needs. For details, see the Custom Fields section in ManualAdministration. An example custom field might be Resolution: FIXED, WORKSFORME, WONTFIX, UPSTREAM, etc, etc... (If you think that example was stolen from Bugzilla, you have much to go on :-)

自定义域 CustomFieldCN 是，是的，数据库域，您的组织可以根据自己的需要。详情参见 ManualAdministrationCN 的自定义域章节。一个自定义域的例子可能是 解决方案 ：FIXED, WORKSFORME, WONTFIX, UPSTREAM, etc, etc... （如果您认为该例子是从 Bugzilla 偷来的，您随便吧。 :-)

Scrips are custom notifications that will automatically take Action X in response to Condition Y. You could have RT notify the Requestor when a ticket is resolved, for instance, or have RT page you when your boss submits a request. RT comes with many standard scrips, and you can define your own. For details, see the Scrips section in ManualAdministration. And no, we didn't misspell "scripts." We made up a new word. Try it, it's fun.

Scrips 是自定义的通知单，可以自动采取行动 X 对条件 Y 作出反应。例如，当一个申请单被解决，您可以用 RT 通知请求者，或者当您的老板转发一个请求的时候，RT会呼叫您。RT 带有很多标准的 scrips, 并且您可以定义您自己的。了解详细内容，参见 ManualAdministrationCN 的 Scrips 章节。我们并没有拼错 “scripts”。我们造了一个新词。试试吧，很好玩。

Now that you are (we hope) clear on the concepts, you're ready to start using RT.

现在，您已经清楚（我们希望）了概念，您准备好开始用 RT 。

---

Up: UserManualCN --- Next: ManualRequirementsCN