Some people have recently voiced valid concerns and complaints about how improvements are managed, organized, and discussed here on Discogs (http://www.discogs.com/forums/topic?topic_id=101510#1337462 , http://help.discogs.com/ticket/1672 , http://www.discogs.com/forums/topic?topic_id=101510#1337622 ) . Since Teo and myself have been discussing almost exactly the same things earlier this month, and have made some progress with the management of these aspects, it is time to review where we are at with it.
The strongest criticism is that the ticketing system is hard to use, and opaque to most users. At the beginning of the month, some of you may have noticed that we went through all the tickets and either gave them a Milestone (a date that they were to be completed by), or closed them as dupes or won’t fixes, or indeed just delt with the issues. As an outcome of this, the ticket numbers have been reduced from around 400 to a bit over 100 ( http://help.discogs.com/report/1?sort=modified&asc=0 ), which is a much more manageable number.
It is now possible to view the tickets on the roadmap http://help.discogs.com/roadmap http://help.discogs.com/query?status=new&status=assigned&status=reopened&milestone=2006-06%20%28June%29 and get a good overview on what will be worked on every month. Because this is split into about 30 or under tickets per month, it should now be reasonably easy for everyone to get a handle on what is going on.
We are now committed to trying to run the ticket system efficiently and in an organized way. All tickets that we don’t think will get resolved this year have been milestoned for January 2007, when we will probably review them and put them in a timeline for 2007. New ticket’s are reviewed on a daily basis as they come in http://help.discogs.com/report/12 , and will usually be milestoned, resolved, or rejected that day.
We did consider some type of forum system to tie into this, but frankly all that this would give us is yet another place to check for discussions etc, when in fact, most ‘good points’ should be put into the ticket system as appropriate. Time is limited, and we don’t want to end up having to manage the management system full time, there has to be time for doing stuff!
This brings us to the roll out procedure for new functions. As Discogs is an ‘online application’, there are certain aspects that differ substantially from normal software development. One of the aspects that is used at Discogs is the ‘live testing’ theory. Because the system can be updated at a whim, and because everyone sees the updates at the same time, it is in fact easier (for most minor changes) to just roll them out and see what problems come up, rather than test them with a particular group of users for a while. Live testing in the real world always gives the best feedback.
Of course, this doesn’t work for major changes that affect the way information is entered into the database. However, it is my belief that it works well for changes such as the unicode update that we had a few months ago. Although criticized by some, I feel it worked out. We could have set up a dummy server, put the data onto it, done the change, tested it, found problems, fixed them etc, but this would have taken MUCH longer to do. As it was, the database was backed up, and the change was rolled out. Users found the bugs much quicker than 10 or 20 testers would have, and everything was tidied up fairly quickly. Of course it may have been slightly inconvenient for certain users during the crossover period, but problems were resolved and we now have a working unicode database in only a few months!
I hope this has given some insight and clarity to the overall issues of site improvement and feature debate, and hopefully more users will be able to use the ticketing system with confidence that their ideas will be reviewed, and that everyone will have a much better oversight of what is planned.