On Sat Jul 02 09:00:35 2016, [email protected] wrote: > I have compiled a list of problems with RT. > > I wrote this while annoyed, so it's a bit snippy, and I apologize for > the tone, but I figure that a list of actionable issues is more > constructive than just me going “aaaa I want to use something else” > and mst encouraged me to post it for that purpose. > > * If you are not logged in and you press “Comment” or “Reply” buttons, > you will see this: “For issues related to this RT instance (aka > "perlbug"), please contact perlbug-admin at perl.org ”. Well, that's > not user-friendly at all. It should probably say that you should > either create an account or write an email.
Definitely a usability nit that we should document, and perhaps we can ask the perl.org RT admins if there's a a workaround. Note: I hear some harsh talk about dealing with the RT admins on the IRC channel. I would recommend that we have a standard practice for this sort of thing, which is probably: open an RT in our own queue describing the issue. Pick someone to be the single POC for the issue with the volunteer admins, they can open the ticket and report progress. I do this unofficially now for some case. > * Some people are experiencing account problems. I have tried to > reproduce it but failed, but people still get it from time to time. > The solution is to write to an admin, but the answer does not come as > fast. There should be no such problem in the first place. Any solution we use is going to be volunteer run. The volunteers at rt.perl.org have always been very helpful and as prompt as possible when I ask questions, or try to followup on behalf of someone who has been having trouble. The most recent problem has been fixed, as far as I know, there is no one experiencing issues. > * Frequent CSRF errors without any good reason. Sure, that's not > critical, but it is very annoying. Specifics, please, and open tickets about this if it's not already open. (one's already open. I haven't yet followed through with the rt.perl.org admins to see if it's easily fixable) > * No way to edit your ticket or comment. While this may be beneficial > from one point of view, I'd much rather have the ability to edit stuff > (I often do mistakes, I want to be able to fix those. Github is not > that great because there's no edit history, but even without edit > history it is probably better). For example, this comment could have > been an editable list of issues with RT, but instead I will be writing > new comments in order to add some items (or mark something as solved). In my opinion, edits sans history is so much worse. If anyone can edit things to say whatever they want whenever they want, that's bad. Better, IMO, to have to reply with a comment. This is an issue with any number of free & paid ticketing solutions. (In JIRA, for example, some people are given the permission to edit any comment, even ones not their own, which makes figuring out what's going on a PITA) And if you need to continually be reworking your ticket, I suggest what we've adopted at $dayjob; use a wiki or other document to gather your thoughts, and once you've locked down the problem/request/description, *then* open a ticket. ticket systems are meant to track work, not have design discussions. This obviously is only helpful on the big edits. > * Tickets are created by default in perl5 queue, and it seems like > there's no way to change the default. People have already created > issues in the wrong queue, and I think that one day I will do that too > (I've already been 1 click away from that several times). While this > is not a big issue, there should not be such problem in the first > place. The recommended way to open tickets is using the rakudobug at perl.org email address; this defaults to the P6 queue. If you're opening them some other way, you can change your default queue in the menu. I don't know what you're referring to here, though. > * No git integration of any sort. I think that I'd love to see at > least clickable links to git commits. Agreed. > * No markup. Well, there is something if you write an email, I guess, > but if you're submitting a ticket/comment from the web interface then > there's no easy way to do that. Are HTML tags supported? No idea. > After 100+ tickets reported I don't know. There's no preview. And I > can't test things because there's no way to edit your tickets… Ideally > I'd love to see markdown or creole support (or anything else, as long > as it is clearly stated that it is supported) I'm not an RT expert, but perhaps this is available in a newer version and/or is a configurable option. I believe as is, no, it's plain text. > * What's the difference between “Reply” and “Comment”? Is it explained > anywhere? Is it possible to explain it somewhere so it will be obvious > for people who write a comment for the first time? Reply is sent to the original requestor. Comment is only put on the ticket. As for documenting it, absolutely, let's start a "How to manage tickets for Perl 6" doc somewhere. I'll put a page in https://github.com/rakudo/rakudo/wiki/ to start. > * Is there any way to have clickable tags? I know that I can create a > search query of any complexity that can solve this issue, but let's > agree that it is less than awesome. The tag should be clickable (e.g. > click on “testneeded” and see other tickets that are tagged this way, > also only in the same queue). That's kinda one of the basics that I am > expecting from a issue tracking system. I'm not an RT expert. Perhaps this is available in a newer version and/or is a configurable option. > * Constant spam. Maybe there is a way to get less spam on RT? I don't > mind deleting it from time to time, but before I was able to do that > it was pretty annoying (what if some 6 year old clicks on it, right?). As someone who is in the queues fairly often, I don't think this claim holds up. There is -some- spam, sure, but nothing like what we saw on parrot's trac instance, for example. And any bugadmin can kill it by hitting the big red "S" in the menu bar. If you've been doing this before I get to any of it, thank you! > * No progress. These issues were there for years, but I see nothing > that will give me hope that it will be better in the future. If > there's any progress, can we make it more transparent? The lack of progress on old tickets has little to do with the ticketing system they are in. What sort of information are you looking for? I regularly ping the IRC chat with summary information on tickets; Tell me what you're looking for, I'm happy to provide it. -- Will "Coke" Coleda
