views:

112

answers:

5

I just installed trac for this project I'm working on, since it's turned out to be a bit bigger than I anticipated. I've added a bunch of tickets with my clients requests which come in the form of emails, phone calls, and meetings. I've also added some stuff I know needs to be done/fixed but they haven't specifically requested. Should I grant them access to trac so they can submit the tickets themselves so I don't have to keep translating (words into tickets) for them? They're very non-technical, so I'm not sure how well it would work; they might open tickets and not provide enough detail, or get confused by all the different fields.

If your answer is "no", should I at least let them view the tickets, so they can see what I'm working on, what's been done, hasn't been done?

+6  A: 

My experience (rather small, though) shows that allowing non-technical people to create tickets directly just won't work. You'll finish up editing those tickets yourself and constantly asking for details anyway. If I were you, I'd choose email for feedback and problem reporting.

However, it is a good idea to share existing tickets, read-only. Some people -- even non-technical ones -- are able to learn out of this how to create right tickets. Others would be happy to follow their particular problem while it's being solved.

hudolejev
+2  A: 

Hi Mark, is it just you supporting the customers or multiple people? If it is just you then make it easy for them, dont make them file tickets. Set up an email2trac gateway where a ticket would be filed automatically via email or simply take and digest their emails yourself and file tickets for them.

Allowing them to see tickets would be a good idea, I think, although Trac does not have a special customer portal capability (where certain internal comments could be hidden or per customer filters applied) so the developers will have to be careful what they write there and one customer will see another customer's tickets (sometimes it is not acceptable).

BTW, we're working on a personal productivity tool that helps developers manage project related emails, sounds like it could be useful in your case when interacting with the customers. Check it out if you get a chance: http://yoxel.com/personal-commitment-manager.html

Alexey
The PrivateTicketsPlugin allows you to make it so users can only see their own tickets: http://trac-hacks.org/wiki/PrivateTicketsPlugin
retracile
It's just me, supporting a husband/wife team.
Mark
+1  A: 

I used to communicate with a client via email and phone, and at some point I realized it was just too hard to keep track of things. I set up an account on Unfuddle (similar to Fogbugz but free), with just accounts for the two of us and it was immensely helpful.

When we first started, I did a lot of editing on new tickets, but it was still much better than keeping track of emails, and she figured out how to create tickets in the form I needed pretty quickly (I assume because now she can see how I keep track of what she's saying).

Anyway, if you're just using email now, it's not like it can get worse ;)

Brendan Long
+2  A: 

So much of software development is managing clients and their expectations. Giving them write access to your bug database may suggest to them that they are now directing and in control of the project more than they actually are. Add to that the inevitable questions that will follow ("How do I do X/Y/Z?") and it's a massive headache waiting to happen.

I would consider read-only access but only if the client was technical enough and experienced enough with software development to understand how these tools are used. Otherwise I would stick with much lower-tech but much simpler todos-in-a-text-file, which I find myself using more often than not.

@Brendan Long trust me, it can get much worse when you give people a false perception about how much fine-grained control they have on a project.

Shaggy Frog
+1  A: 

At my company, we're struggling to get good problem descriptions in tickets from a technical audience (system administrators, technical consultants etc), and more often than not it takes inquiries from our professional helpdesk before an issue is layed out clear enough for a developer to work on.

Thus, from many years of experience, I would clearly advise against letting all your customers open tickets (unless you can narrow them down to a technical audience) because it will not save you any work compared to e-mails.

Read access is a good idea (because people will still feel much more involved) - you just have to make sure that you do not have too many tickets (usually low prio bugs or requests) that remain in the same state for a long time because this will start to frustrate the person who submitted it (better to close such a ticket in a timely manner if you can't or do not want to work on it, this kind of honesty if usually more appreciated than letting a ticket open for years ,-).

ISW