GNOME.org
 

Re: [Planner Dev] Prop. for new feat. - first patch



Richard Hult wrote:


I'm just talking about the naming scheme in the code though. The UI
shouldn't have a name for this in my opinion, it's just a task with a
high priority that should get scheduled before other tasks.

It might even be good enough for the code to just talk about priorities
too. And any task with a priority higher than other tasks, will
"vampire" on those lower priority tasks. What do you think about that
Matteo?


Hi,
yes, you named it, a high priority, previously unthought of task that eventually must be processed 
prior the actual work may begin.
Since the task naturally arises from the originally processed task, it is difficult for me to actually think of it as something that eats away my time in order to actually achieve what I was supposed to 
be doing instead ,-)
Perhaps we should instead name them "MustBeUsingWindowsOrSimilar..." SoftwareConfigurationSystemRestorationTasks...
By the way, naming them vampire tasks as a picture of that they actually steal away otherwise precious time seems to me that one is rather annoyed by the fact that the task eventually did arise from the project or otherwise currently processed task. of course such tasks are tedious, however, the software should reflect that they indeed are positive in that one may actually learn to fore-front calculate such time consuming and often re-occurring tasks due to 
uncalculateable mishaps during the projection phase.
My proposal would be to just make a task initially a container that by default consists of the task itself, and additionally add sub-tasks that then would have a higher priority than the original task. this is consistent with the current architecture of the planner and is also more neutral in language than for example calling it a "vampire" 
high priority task. At least this is my personal opinion on that topic.
I actively watch further development of the planner as I am in dire need of a working and appropriate project visualization software, that is, I plan to incorporate part of the planner, namely the chart generation facility, or at least part of its overall architecture into a custom project visualization and project management software of mine - for now only being defined for 
internal purposes (self management etc.).
For this I would need a proper and clean document structure, that is the actual document structure that the planner currently implements. I reckon that introduction of some "vampire" task scheme would also require change of the structure of the planner's generated xml documents. Therefore I am more or less strictly against naming that task a vampire task as it can always be realized as follows: 

Task   { some scheduled task }
initially, this task describes all of what is to be done and when during normal operations. let that be the main project task, ie the 
main task that stands for the project itself.
now, whenever a new task arises, this task must be planned and scheduled. Therefore we create a sub-task of that task, that now will eventually and provably eat away some of the time intially being scheduled for the declaring task.
now, if we have a high priority task that arises due to some unforseen circumstance, we define a new task, ie a higher priority 
   task that we then fit into the overall schedule of the project.
"vampire" tasks, as they represent such high priority tasks would then be just that, high priority tasks that are part of the tasks of which they actually 
   will take away some of the scheduled project time from.
now, if we had a task defined, that itself is a sub-task of the original project, we could always define such a high-priority "vampire" task as a direct sub-task of that task, making it a preliminary task that must be worked on as it actually has a higher priority than the declaring task itself, which 
   eventually then would have a low priority of say 0.

   Task
"Vampire" Task ( the "vampire" task now is mere but a sub-task of a higher priority than the containing task itself, which is actually now and always a subtask of itself) /Task ( the Task is actually a sub-task of itself, having a priority of for example 0)
In that case we would not require that we have "Vampire" tasks, we would just state that these tasks are actually higher priority tasks that take away some of the initially scheduled time or instead increase the amount of the that the tasks actually consumes. the task then would be just a sub-task (sub-process) of itself in that it adjusts its actual instance by either rescheduling itself so that it actually endures the originally scheduled time minus the time taken for the "vampire" high-priority sub-task. as such, preliminary as in preliminaries or something like that would be more appropriate as it is rather neutral to the real nature of the taks, that is, either prolonging overall task duration or causing stress by shortening the time available for actual processing of the task. 

   Something more philosophical:
Yeah, we are developers and we hate prolonging something ad ultimo, and more so if the environment intially is not setup to our liking or something does not work out or there is some inherent malfunction in one of our customers. yet, always ranting about that vampire task is actually not keeping up the good faith on the project.
I for my part am currently working on multiple projects that are becoming more complex as time progresses and my personal knowledge grows. currently I am in a phase where there is some manifestation of some regular re-occurring patterns of research so that I finally can come to terms. for that I require that I fail in certain aspects of planning the overall process as the process itself must at first grow so that it finally becomes mature in that erring on project schedule becomes less critical in that errors can be avoided forefront. it is critical that these errors be respected as actual helping instances of self-error or error in some other person's personal schedule or logic and by that a success rather than something being called for example something eating away time and profits. 

      examples:
- customer requests that the graphics for some software need to be redone. this requires overworking part of the architecture of the system. initially had forgot to ask if perhaps the customer requires an extensible graphics engine or graphics generation system and implemented in a static way. now that i could not continue in further developing the overall graphics subsystem i am required to change the schedule so that the architecture be overworked and finally the existing implementations be reimplemented so that actual work can continue.
- now, is this a vampire task? does it eat away profits and time as it is clearly a customer request to that which we should obey?
working on the project requires setting up a test environment forefront. initially had forgot that in the hurry of the overall process. 
               vampire task? tedious task, high priority task?

-           test environment crashes and must be reinstalled.
            vampire task?
I believe that all of these tasks are not actually eating away time as they actually are required to actually establish our time in that without the testing environment we would not be able to actually ship the product, unless you are one of the global software players...
how is your opinion on that? do you expect additions to the document schema when introducing vampire tasks and if so, how would you call the 
   then to be introduced element (type)?
I for my part see it in the above displayed way that a task is actually a sub-task of itself, with a self-schedule. 

How do you think about that when viewing it from this perspective?

Cheers,

Carsten
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]