As pointed out by some other answers, the right question here is probably: why do you have an issue tracker. A good answer to this question (not just from a management perspective but also from a developer perspective) is imperative if you want an issue tracking system to really work and be regularly updated.
In many companies the issue tracking system is mainly used as a management reporting tool. Getting programmers to update issues just so that management can run a report does not work well. And forcing programmers to update issues does not work either - you may have updated issues but you should question the data.
In my experience, the only way to really have developers (and testers, management, etc.) effectively use an issue tracking system is to integrate it into the development process. This means that the output of one part of the process becomes the input to the next part of the process.
To give the bug tracking system authority I would suggest the following:
- Only bugs/features logged in the issue tracker are worked on by developers. All ideas, refactoring projects, new features, custom tools to be developed, etc. should be logged as well.
- Issues are worked on in order of priority. The priority should partly be determined by management, but developers should definitely have a say in determining priorities as well. This is especially true when it comes to maintenance and refactoring issues.
As to process, you could use something like the following:
- status 'new' indicates that an issue has not yet been picked up by a developer and is still in the queue of prioritized issues
- status 'assigned' indicates that it has been assigned to a developer. This could be done by the developer or someone else such as the team lead. I find it works well to have a few issues assigned to each developer, and usually a mix of 'heavy lifting' such as new features and easy pickings such as simple bugs or some simple maintenance work. This allows developers to choose work depending on their mood.
- status 'in progress' means that a developer is working on an issue. Only one or two issues per developer should be 'in progress' at any point in time.
- once an issue has been resolved the developer can change the status of the issue to 'needs testing' and change the owner to the tester. This is an important step, as this is also the work queue of the testers.
- testers can change the status either to 'failed testing' and change ownership back to the developer which means that it goes to the top of the queue for the developer, or they can change the status to 'ready for deploy'.
- issues with the status of 'ready to deploy' can then be merged and released according to the release cycle by whoever is responsible for the releases.
In short: make the issue tracking system an essential part of the development process and you won't have to worry about issues not being updated.