Comments on: No more ticket migration http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/ The ins and outs, ups and downs of building a web community Thu, 19 Jun 2008 11:47:17 +0000 http://wordpress.com/ hourly 1 By: bizbob http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-13 bizbob Thu, 30 Aug 2007 22:02:51 +0000 http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-13 Toby and I have actually had some rather animated discussions about this "worksforme", but have found a fairly practical approach to the issue Gary describes. The workflow we have agreed on is that the developer sets the status as "worksforme" and closes the ticket BUT ensures that the reporter is notified, for example by being cc'd. This is the trigger for the reporter that the fix must be validated. If we agree with the fix, we make a note in the ticket and just leave it. If we are not satisfied, we re-open, comment and reassign the ticket to development. What we have discussed was who should close the ticket: the developer who thinks it's fixed or the reporter who can confirm it through testing. Based on Toby's referral to "established Trac practice", I decided to chose another battle. So, the developer who changes status to "worksforme" also closes the ticket. Toby and I have actually had some rather animated discussions about this “worksforme”, but have found a fairly practical approach to the issue Gary describes.

The workflow we have agreed on is that the developer sets the status as “worksforme” and closes the ticket BUT ensures that the reporter is notified, for example by being cc’d.

This is the trigger for the reporter that the fix must be validated. If we agree with the fix, we make a note in the ticket and just leave it. If we are not satisfied, we re-open, comment and reassign the ticket to development.

What we have discussed was who should close the ticket: the developer who thinks it’s fixed or the reporter who can confirm it through testing.

Based on Toby’s referral to “established Trac practice”, I decided to chose another battle. So, the developer who changes status to “worksforme” also closes the ticket.

]]> By: Gary Allen http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-12 Gary Allen Thu, 30 Aug 2007 07:46:03 +0000 http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-12 One thing that puzzles me with Trac is the lifecycle of a defect. I’m used to have more stages to run a defect through, e.g. to set it to “To test” after deploying at a dev server and then the tester or reporter must validate it and either return it or confirming it as Fixed and close it. In Trac the developer just says Fixed or worksforme after taking care of a bug and then the testers must find it and test it and re-open it if it still has problems. Maybe this is part of the agile movement that many Trac using project teams seems to be part of? One thing that puzzles me with Trac is the lifecycle of a defect. I’m used to have more stages to run a defect through, e.g. to set it to “To test” after deploying at a dev server and then the tester or reporter must validate it and either return it or confirming it as Fixed and close it. In Trac the developer just says Fixed or worksforme after taking care of a bug and then the testers must find it and test it and re-open it if it still has problems.

Maybe this is part of the agile movement that many Trac using project teams seems to be part of?

]]> By: bizbob http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-11 bizbob Wed, 29 Aug 2007 08:09:19 +0000 http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-11 It's great to have you by my side, Toby. It’s great to have you by my side, Toby.

]]> By: TechToby http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-10 TechToby Wed, 29 Aug 2007 07:59:43 +0000 http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-10 Yes, we’re actually using Gmail as a file system at the moment, but only as a second fallback in the backup process. The first is a regular file server storage. From there the files are PGP encrypted and sent over the network. It is more like “if one continent sinks, we have a second backup on another continent”. PGP on the file level together with using SSH for connecting to the online Subversion repository and SSL for Trac feel Pretty Safe. We will however drop the “GFS” part of the process when the files grow in size and we start mirroring the backups to another server. Yes, we’re actually using Gmail as a file system at the moment, but only as a second fallback in the backup process. The first is a regular file server storage. From there the files are PGP encrypted and sent over the network. It is more like “if one continent sinks, we have a second backup on another continent”.

PGP on the file level together with using SSH for connecting to the online Subversion repository and SSL for Trac feel Pretty Safe. We will however drop the “GFS” part of the process when the files grow in size and we start mirroring the backups to another server.

]]> By: Frozy http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-9 Frozy Wed, 29 Aug 2007 07:49:52 +0000 http://bizbob.wordpress.com/2007/08/27/no-more-ticket-migration/#comment-9 W00t! You're using Gmail as a file system for you backups? W00t! You’re using Gmail as a file system for you backups?

]]>