|
|
Please read [Frontdesk best practices](https://gitlab.torproject.org/tpo/community/team/-/issues/7) before reading this. Request Tracker (RT) has a multitude of features and one can easily feel lost navigating through them. With this ticket, I aim to document some optimal ways of using the RT to our advantage:
|
|
|
|
|
|
1. On the Request Tracker, by default, for every frontdesk ticket you 'Take' the responses to it end up in your inbox. This is nice since you get pinged on your email when the user has responded **but** this also means all of the conversation now resides unencrypted with your email service provider. Consider disabling this and use your 'User Profile' -- [https://rt.torproject.org/User/Summary.html?id=\[your-unique-user-id-on-rt\]](https://rt.torproject.org/User/Summary.html?id=%5Byour-unique-user-id-on-rt%5D) -- to track tickets you need to respond to.
|
|
|
2. It is okay to top post but if the thread is too long or there are too many queries to respond to, consider bottom posting (i.e. reply quoting the queries one by one aka inline).
|
|
|
3. If the message thread is too long and you're seeing: 'message is too long to display', there are some ways you can still see the message: (1) Click on 'Download (untitled)' to open it in a new browser tab -- doesn't look pretty if the email is not plain text and is heavy on html, (2) Click on reply and you should see the message in the response box (nice formatting and easier to read but be aware that you're now actually writing the response!)
|
|
|
4. Articles are a great way to create templates for FAQs but I would not recommend adding your signature to the article because it might be extra work for the other folks working on RT to edit it out.
|
|
|
5. Add as much information about the Article in it's title. Highly **not** recommended to fill the description column. The description gets written with the email if you choose to use the article and you will have to manually remove it every time.
|
|
|
6. If you're opening a ticket on our gitlab instance w.r.t any query raised on the frontdesk, do point the user to that ticket. This could help the user to respond directly on that ticket if they want (also, that means less work for folks on RT! yaay!)
|
|
|
7. Since I had trouble finding this: to mark any particular ticket as spam, go to 'Basics' > 'Queue' to 'Spam' > 'Save changes'.
|
|
|
8. Some email clients scan all of the URLs in the body of the email. So when the user reads the email the links can be transformed into long strings like
|
|
|
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftorproject.org%2F&data=01%7C01%7CLangbeinFC%40c%7C0a332dbe008d679455a9c%7Cbdb74b3095684856bdbf06759778fcbc%7C1&sdata=B8QMlN4Mz%2Bq0lVkNypUu%2B0BYsN0mv2k4%3D&reserved=0. So it's a good idea to describe what the URLs that we are sharing is leading to when writing the email.
|
|
|
|
|
|
Preparing Reports:
|
|
|
|
|
|
1. Request Tracker has cool graphs to track: 'Tickets created over a certain date range', 'Tickets resolved in a certain date range', 'Tickets resolved by the owner'. All of them available under 'Reports'. The titles are quite self-explanatory and can be extensively used to track your work and prepare reports at the end of each month. |
|
|
\ No newline at end of file |