Add comments to checklist sub-tasks
Page: 1, 2
BrianJCohen
on Nov 19. 2007. 6:04 am
Right now, activeCollab does not seem to allow adding comments to checklist sub-tasks. Before you say, "that's what Tickets are for", bear with me a second. The reason this is unfortunate is because I don't always correctly anticipate whether my task belongs in a checklist or as a standalone Ticket. And I'm finding it happens all the time. For example, my client sends me a list of changes/requests and I enter them all as a checklist, hoping to come back later and check them off as I complete the work. But on one of them, I hit a snag and need to make a note about why it's complicated. Now what? Should I delete it and open a new Ticket? That's double-entry, and breaks my workflow... activeCollab should work for me, not the other way around.
So, I would really appreciate it if this functionality could be added.
Thanks,
Brian
So, I would really appreciate it if this functionality could be added.
Thanks,
Brian
Why not just add them as tickets in the first place? You can still add tasks that you can check off. We don't use checklists at all, just tickets.
J.R.
BrianJCohen
on Nov 19. 2007. 4:11 pm
J.R.- That's what I meant when I said, "Before you say, 'why not just add them all as tickets in the first place.'". So yes, you are right in the sense that it does kinda make Checklists useless. The reason I posted to the Features forum is because by allowing us to add comments to checklist subtasks, Checklists wouldn't *have* to be useless.
J.R.:Why not just add them as tickets in the first place? You can still add tasks that you can check off. We don't use checklists at all, just tickets.
I'm of the opinion that Checklists should be removed anyway. I'm guessing that Checklists were there before Tickets. Then Tickets came along as an advanced Checklist. Checklists were left in because they're simpler. But then you run into the problem you have. You have to decide where to start and you can't change later. Checklists should be removed and Tickets should be the only option. Or instead of having Tickets being advanced Checklists, make Checklists simple Tickets. That way moving a Checklist to a Ticket in the future would just involve flipping a flag in the database.
J.R.
Actually, tickets are precisely what these should be entered as.
Your client is submitting a ticket, and you need to do work on it.
Checklists are more internal and personal work related.
@J.R. I do agree that Checklists should use the Ticket system, but not without the full functonality. Terminology wise, a ticket would be an issue, bug, request from a client and a checklist would be an internal project element.
If Ilija would make the comments, tracking, etc. (ticket features) enabled on the Checklists, the funtional use of these would be differentiated by workfow.
Your client is submitting a ticket, and you need to do work on it.
Checklists are more internal and personal work related.
@J.R. I do agree that Checklists should use the Ticket system, but not without the full functonality. Terminology wise, a ticket would be an issue, bug, request from a client and a checklist would be an internal project element.
If Ilija would make the comments, tracking, etc. (ticket features) enabled on the Checklists, the funtional use of these would be differentiated by workfow.
Okay .. I see. However, I see another use for checklists - and with a little added functionality (the ability to copy to a ticket), checklists would be perfect as a template (similar to basecamp templates).
There are a variety of things that get done over and over and over again ... Daily PM's, Monthly PM's, Year End PM's, Dump & Load DB's, New Hire checklists, etc. ... I work in an environment where I am maintaining an ERP system that consists of 28 databases across 3 different servers on both Unix and Windows platforms and a mix of the two moving a LOT of data on a day to day basis.
A dump & load checklist:
• Notify users of planned maintenance
• Check the HWM
• Verify that diskspace is available
• Suspend scheduled tasks (or cron jobs)
• Stop Data Collection
• Stop Background Queues
• Disable logons
• Run Database Analysis
• Create dump scripts
• Stop all DB's
• Backup the DB
• Move backup to archive
• Move logs to history
• Dump the schema
• Dump the data
• Delete the structure
• Optimize filespace
• Rebuild the structure
• Load the DF
• Load the Data
• Rebuild Indexes
• Start the DB (w/o OIB)
• Review logs
• Run DB Analysis
• Compare before/after analysis
• Backup the DB
• Move Backup to Archive
• Verify the HWM
• Start the OIB
• Start Background Queues
• Start Data Collection
• Start scheduled tasks
• Verify successful completion of scheduled tasks
• Enable logons
• Notify users of successful completion
Now that's quite the checklist ... and 'checklist' is a really a good term for it. I know it appears to be anal but this is a corporate environment and everything has to be documented. I don't need to track time on each of these items, I just need to show that due diligence was done.
But it's not something I want to recreate (28 times) every time I have to do a dump & load. If the checklist were a template, I could create it once and them simply copy to a ticket every quarter or whenever it needs to be done and track the time on the ticket.
There are a variety of things that get done over and over and over again ... Daily PM's, Monthly PM's, Year End PM's, Dump & Load DB's, New Hire checklists, etc. ... I work in an environment where I am maintaining an ERP system that consists of 28 databases across 3 different servers on both Unix and Windows platforms and a mix of the two moving a LOT of data on a day to day basis.
A dump & load checklist:
• Notify users of planned maintenance
• Check the HWM
• Verify that diskspace is available
• Suspend scheduled tasks (or cron jobs)
• Stop Data Collection
• Stop Background Queues
• Disable logons
• Run Database Analysis
• Create dump scripts
• Stop all DB's
• Backup the DB
• Move backup to archive
• Move logs to history
• Dump the schema
• Dump the data
• Delete the structure
• Optimize filespace
• Rebuild the structure
• Load the DF
• Load the Data
• Rebuild Indexes
• Start the DB (w/o OIB)
• Review logs
• Run DB Analysis
• Compare before/after analysis
• Backup the DB
• Move Backup to Archive
• Verify the HWM
• Start the OIB
• Start Background Queues
• Start Data Collection
• Start scheduled tasks
• Verify successful completion of scheduled tasks
• Enable logons
• Notify users of successful completion
Now that's quite the checklist ... and 'checklist' is a really a good term for it. I know it appears to be anal but this is a corporate environment and everything has to be documented. I don't need to track time on each of these items, I just need to show that due diligence was done.
But it's not something I want to recreate (28 times) every time I have to do a dump & load. If the checklist were a template, I could create it once and them simply copy to a ticket every quarter or whenever it needs to be done and track the time on the ticket.
cbtrussell
on Dec 22. 2007. 1:46 pm
Checklists (which should REALLY be Tasks or Task Lists) are perfect for established processes and procedures.
Tickets are great for ad-hoc/on-demand work.
So for example, our normal production process is documented as a series of checklists. Once project templates (or at least the ability to upload checklist templates, like basecamp provides) are available, this will be a real timesaver as our process is identical from one project to the next. Those tasks are assigned to individuals as appropriate during the course of the project.
Tickets are reserved for work not specifically part of the process, for example defects, other client requests, etc.
I do agree that tasks need the ability to comment. We also need to be able to add time directly to a task.
I find our folks are confused by the task functionality available in the pages section. It's kind of weird to have tasks in checklists and also in pages.
My personal opinion? I think you should be able to add comments, files & time to ANYTHING, consistently. Teamworklive does this, and it's quite nice.
Tickets are great for ad-hoc/on-demand work.
So for example, our normal production process is documented as a series of checklists. Once project templates (or at least the ability to upload checklist templates, like basecamp provides) are available, this will be a real timesaver as our process is identical from one project to the next. Those tasks are assigned to individuals as appropriate during the course of the project.
Tickets are reserved for work not specifically part of the process, for example defects, other client requests, etc.
I do agree that tasks need the ability to comment. We also need to be able to add time directly to a task.
I find our folks are confused by the task functionality available in the pages section. It's kind of weird to have tasks in checklists and also in pages.
My personal opinion? I think you should be able to add comments, files & time to ANYTHING, consistently. Teamworklive does this, and it's quite nice.
I agree 100% with everything that cbtrussell - couldn't have said it better.
and I'd also like to see Checklists renamed to Tasklists! Maybe we could do a poll on this?
and I'd also like to see Checklists renamed to Tasklists! Maybe we could do a poll on this?



