PrjPlanner - The Answers
So, here is the short version:
They are whatever the developer, your team, or the first-level manager defines them to mean.
Ok, here is the longer version:
The main goal of PrjPlanner is to give an idea of a project's status very quickly and intuitively. I believe the information radiator does this. While we can quibble about definitions, it is obvious and agreeable by all that tasks start at 0% complete and 0% correct and when a task is deemed finished by a developer it is 100% complete and 100% correct in the developer's mind. So with a quick glance, one can determine a project's overall state: Are all the tasks near the origin, somewhere near the middle, or near the upper-right? This is enough for task management for developers, small teams and their immediate managers.
Now, what the professional project management tools attempt is to define these for you. Completeness is generally the percent of work done on a task to the developer's total effort estimate. The developer said it would take 6hrs to complete this task and she has worked 1.5hr on it so it is
25% complete. Correctness is generally the percent of tests passing out of the total number of tests. The developer has written 14 tests and 3 are failing so the task is
~80% correct. When put this way (eg. simply) those are arguably (though by few developers) reasonable metrics. When implemented within the massive systems already discussed they become noise to developers. They become weapons for managers to beat up on developers. Developers begin to hate the systems, management, and project management in general (preferring to just be left alone and wishing they could tell their management: I will tell you when I am done, dammit!). The systems are no longer an instantiation of a methodology to help developers do their job or inform their management, but become excuses for one level of management to defend to their management why the project is slipping.
What? That was not your question? Well, how about this then:
No, there is no mechanism. Just edit the XML file.
And the longer version:
Philosophically, I think a real task, not one that was accidentally added, should never be deleted as it is useful information. So, for 1.X versions, there will be no mechanism within the tool to delete tasks. If you really want to, it is simple enough to edit the XML file and remove the task and sub tags. 2.X versions of the tool might allow for the deleting of tasks OR to place them in a Completed category, similar to Backlog, so that they will not have to stay around in the radiator.