I mean who should be the one to say whether a task is really done or not?
Someone (I’ll call them the performer) is assigned a task with a due date. When they’re done, they click the “Done” button and move on to the next task. I have not found an exception to this practice in any project management software or social task management system. The idea is simple, obvious even, but flawed.
Sure, if you have developed the task for yourself, then you will know with certainty when it’s “done”. But if someone else has asked you to do something (I’ll call them the requester), shouldn’t they be the one to determine if it’s really done?
A better, more specific approach is this: the performer sends a message to the requester asserting that they are done with the task. The performer delivers what they think was asked of them. Then the dialog shifts over to the requester who accepts the delivery and then determines if the task meets the requirements of their initial request. If so, the requester closes the task. If not, the requester sends it back for adjustment or rework until they are satisfied.
It may seem picayune, but underlying the above approach is a more fundamental point. The smallest element of work is not a task; it’s a conversation about a task. Two people (requester and performer) forging an agreement to get something done together, making adjustments along the way, and finally closing the conversation with some acknowledgement. It’s far too simplistic to think an assignment gets made and then the performer says “done”.
CommitKeeper software manages and records this “conversation for action” between requesters and performers.