|
I've made a few comments over the last couple months about separating different kinds of comments but I haven't thought about it enough until now to articulate the concepts.
I think there are four kinds of comments:
1) Comments about a task. This is part of the definition, the spec that tells us what the task is.
Comments on task activity. This is where we use the ctrl+D to document what's been done on a task as it happens. There are actually two kinds of activity comments:
2) Notes for people working on the task so that there is a detailed log of what's going on. These notes are not published in reports to clients or management. I'll refer to these as Internal Activity Comments
3) Notes for clients/management about general activity, issues, milestones. These notes are for reports. I'll refer to these as Public Comments.
4) Comments in time logs detail why the time is being logged. This could be for purposes 2 or 3 above, so we'd have Internal Log Comments and Public Log Comments.
How might we get from here to there?
We currently have two comment fields, the task comment and the time log comment. One quick/cheap way to separate comments is to use an unusual character in the text (alt-sequence) to separate Internal from Public comments. In XSL we can parse either side for specific report types. I do this to parse the first line of a comment as a task summary, using the EOL character as the delimiter. My code then checks the result to see if it's null before wrapping it in HTML. I can share my XSL. For time logs, the single comment field can similarly be parsed by a macro or other code that post-processes the CSV data. This DIY method can be used by anyone now with some discipline and XSL changes, but requires no effort by Dan.
Another mechanism requires code changes. Keeping the Comments field for all who use it, three new fields can be added to the tasklist schema for anyone who wishes to separate the concepts: TaskDescription, TaskInternalActivity, and TaskPublicActivity. Like Comments, each of these fields would be optionally PlainText or RTF. It would be up to anyone who desires to use these field to copy relevant parts of the existing Comments field to whichever field they wish. The general purpose Comments field can still be used by each individual for whatever purpose they wish, as it's used now, or in addition to the other fields. The UI would need to accommodate up to four comments blocks. The time log would also have another comment box added to separate Internal from Public comments, and the CSV would get a new related column.
As I sometimes do, I'm presenting a challenge that I have just to see if others have the same challenge. I've presented my thoughts for a solution but I'd be interested to know what others do or think.
Thanks for your time.
|
|
|
|
|
I think 'comments' are sometimes a misnomer. Some times 'Notes' are a better name.
There is an additional comment 'type' - app / task / maintainer comments. "Set up this task with these fields ..."
I think the various comment types reflect more on the task type than on the comments. Arguably anything with sub-tasks are summary tasks, and only summary information should be present. Thus task execution comments might not belong in that record, but in a sub-record.
Arguably, for each comment type you note, there should be a corresponding sub-task within which the associated comment type would be entered. [You're almost suggesting a hierarchy of comments within a record, when that hierarchy organization is already inherently present at the task level - wheel reinventing?] Milestone, for example, is typically a standalone task. Or a summary task. (Bottom up vs top down, almost, depending upon your personal viewing preferences.)
You also almost seem to be suggesting comment tags. e.g. Maintainer tag / comment, Project Manager tag / comment, task executer / comment [e.g. time spent journal log comments]. For that moment's use case, apply a tag filter and you're there?
It feels like you are groping towards sub-comments. If you instead consider summary tasks as the task, providing you a sub-hierarchy of task and therefore comment types, are you not already where you're trying to go? [I do get, given your musings, that the presentement that you are looking for may not currently be present - but is it possible that that is because of some lack in filtering / presentation facilities for where you're trying to go, which would be a different beastie? i.e. Enhancement request is not for comment sub-hierarchy but for a 'filter by tag plus other considerations' combination.]
More succinctly - treating sub-summary tasks as the task definition, and applying tags, is what you're looking for not already present?
|
|
|
|
|
Thanks @_BS_. I've thought about your comments carefully, mixed thoughts on each reconsideration. I do use a hierarchy of sub-tasks (project level task, parent task, child task) where the parent task is a container, not actually used for logging, and thus can be used to contain task definitions. One can assume here that the child tasks would be used purely for tracking activity, and their comments would have the related log data that I describe.
However, each child task needs its own description - why does this task exist such that it will be worked on separately? That can't always be summarized in the top line. So using your scenario I would need to use these child tasks as definition items and do my actual processing on grandchild tasks. In other words, each task that gets actual work would require an immediate parent to define that item. This doubles the number of task nodes in a list.
The problem is that while the structure is sound for some folks with some applications and with some additional handling, this is an imposed structure which may not conform to existing lists.
To back up a bit - To me, a task has many fields, and I find myself using the single Comments field for multiple purposes. I think it's quite reasonable to propose additional fields on the task to support this application, because I'm guessing that while most people haven't yet considered this to be an annoyance, now that we're talking about it I'd think some folks would see the value in enhancements in this area.
Here's another option - supporting additional data types on Custom Attributes: Text Area and Rich Text Area. Right now we just have a small text field suitable for tag-like text. I'm wondering if people use that for more text and just accept that they can't see the whole thing. Rather than having a new standard field to separate descriptions from comments, I'd be happy creating custom attributes for my own purposes. If course we'd also need another mod to set which custom attribute are displayed in the grid, and the edit block would need to adapt to support larger custom fields.
So in my initial note I proposed adding new fields and structuring the Comments field for these purposes. @_BS_ has proposed another mechanism. And here I propose yet another. I'd be interested in other comments and proposals.
|
|
|
|
|
FWIW, I really only use the first two types mentioned, and I don't have need for reporting to customers or bosses using TDL.
My notes are mainly to more carefully explain the task and to provide additional background to it (Notes or links to files/emails). This is mostly presented in the parent tasks.
I also sometimes have a small list of sub-tasks in the comments that I don't feel warrant their own 'real' tasks, which live in the relevant child task.
I also use TDL as a structured note taking application.
Bearing in mind I don't use the system the way you do (and hence may not understand some subtleties), I see it slightly differently. I do wonder whether the first two are different enough to warrant distinguishing them.
To me it comes down to separating by audience. In this case, 1. People working on the task, 2. People you are reporting to about the task (i.e. Internal vs Public). Each audience may have description, background, work details, or time log notes information (is there really any need to separate these out?).
So I wonder whether you only need 2 comment types /sections to achieve what you are after (Internal/Public). I can't really comment on how this might be implemented, but the suggestions above seem possibilities.
PS: I'd be keen to see you comment manipulation code...
zajchapp
modified 9-Nov-14 5:21am.
|
|
|
|
|
Dan,
A few questions, using RC2:
- Not sure if this is intended behaviour. I am finding that when in Listview and I change the Filter, the Sort is lost and needs to be reapplied - bug or feature?
- I noticed that once the task is checked off, the status is set to 'Complete', and cannot be changed. Initially I expected the status value to just be changed, rather than locked down. I have had occasion to want to change it to 'Cancelled'. Comment?
- Is there a way to 'hide' task references when applying a filter? They are useful to see for some task management processes, but are not useful for others. Could this be added as an option perhaps?
- Something from a long time ago, the Gantt chart still fills the bars in as white when the chart is set to using default colours, and there is no colouring. Ideally the bars should default to black or grey rather than white in this case in my opinion...
zajchapp
|
|
|
|
|
zajchapp wrote: Listview and I change the Filter, the Sort is lost
the status is set to 'Complete', and cannot be changed Thx, I'll these both fixed.
zajchapp wrote: Is there a way to 'hide' task references when applying a filter? Not currently.
zajchapp wrote: Ideally the bars should default to black or grey rather than white in this case in my opinion... I'll make sure that they get filled with a color that distinguishes them from the background colour.
|
|
|
|
|
Many thanks for the consideration.
I'm presently in a 'can I use TDL better' mode, so these things are popping up.
|
|
|
|
|
zajchapp wrote: these things are popping up. Keep 'em coming!
|
|
|
|
|
I've noticed I lost sight that 6.8 has continued to receive bug fixes, being 'overshadowed' I suppose by 6.9RC discussions. (Although I have RSS'ed the wiki, updates come in as totolist_exe_pre.zip - and I guess I have always assumed pre = pre-release.)
Anyone know if just this page (not the forum) can be RSSed?
Even better if like the wiki I can do a diff display of changes from prior version. From that I should be better able to bop myself upside the head that a new version is out.
|
|
|
|
|
Best thing to do is to enable 'auto-updates' in the Preferences, at least as a way of notifying you that there is an update.
|
|
|
|
|
That doesn't work for this use case. With these multiple instances, I can't have disparate users updating (or not) in disparate places. Not that they would even know what to do about an update. (e.g. Extract the one .exe and one .dll in use and put it in all the appropriate directories. If they just run with the update process it will update their machines, not the individual instances?)
And I haven't been regularly in TDL local/registered to notice, myself.
Anywho, I'm guessing from your note there's no RSS ability for the page.
Any other suggestions for receiving version update notifications? I do get wiki change notifications, if that helps.
|
|
|
|
|
_BS_ wrote: I do get wiki change notifications, if that helps. Perhaps create a filter for updates to 'todolist_exe.zip'...
|
|
|
|
|
filter? (In wiki? codeproject.com?)
I do see the todolist_exe_pre.zip land, however nothing accompanies it (or todolist_exe.zip, I presume) to indicate version number. Thus, for example, I can't tell if it's a new production version or a pre-release (I assume that's what the 'pre' stands for). Given the variety of installs and variability of user capability, I can't be casually updating production versions, let alone with pre-release or RC versions.
I get the filename not having version information within the name makes the update / publication process easier. If there were a wiki revision history page, I could get notifications for changes to that.
Any other suggestions for automatic change notifications with version numbers / upon change?
Actually, there is http://abstractspoon.pbworks.com/w/page/1262222/Previous%20Versions ... I suppose a new version coming in would cause the current version to be entered upon that page, and such change would notify me. Doesn't contain point releases it seems, though, unlike this codeproject page.
|
|
|
|
|
_BS_ wrote: filter? (In wiki? codeproject.com?) If you get email notifications then can you not set up some rules to look for 'todolist_exe.zip' in the email body which would indicate a new version of the current release?
|
|
|
|
|
Bingo!
Perhaps you have hit on the crux of the issue. (Actually, thinking about it, I did allude to that - a posting of todolist_exe-6.8.10.exe would be more obvious. e.g. Would have bopped me on the head when I saw 6.8.2 that I wasn't asking a question about the current production version.)
It is not clear which (files) is what. e.g. I keep asking for confirmation of what _pre.exe is/means.
So, reading into your question, my guess would be that a todolist_exe.zip posting notification went by and I didn't notice, or given whatever the _pre versions are, the non-pre's got lost in the noise.
Further, given your note, hopefully beat into my noggin now is - when you see this file go by, a new version is out, go peek at the modification list.
I suppose a wiki page explaining the uploads would be useful. Then a simple See: {wiki article} would have answered this thread earlier in the cycle.
Note that this doesn't take away from earlier comments or suggestions. For revision history / notification changes, it does seem that the wiki offers more built in automated functionality than the codeproject pages, but I do get that there are enough fiddly bits flying all about, and change is additional effort in and of itself.
|
|
|
|
|
_BS_ wrote: I keep asking for confirmation of what _pre.exe is/means.
'_pre' denotes a pre-release version so, for your specific purposes, you can safely ignore it.
Therefore any notification from the wiki that 'todolist_exe.zip' has changed can safely be assumed to be a new version.
|
|
|
|
|
|
Random thoughts...
I think we pay for open source software with our time. So if you want this wonderful free software, then you or someone you know needs to spend time tracking its progress.
Not a solution but an idea to consider: CodeProject has a new API which might have functions to allow you to pull desired content via a web service. Depending on the content retrieved you might be able to parse version numbers, file names, or other data of interest. Then with that data you can have the client code email you with nicely formatted emails.
Or someone here might offer to charge a couple bucks per year to email desired updates to a mailing list. To facilitate that I'd suggest that a specific wiki page get updated periodically, and the content of that page should then be pushed out to subscribers. Oh wait - that's RSS.
The problem with open source software is that most people just want the software, they don't care about the open source or the fact that open source documentation is as much a part of the FOSS as code. Everyone seems to rely on the code author to author the documentation as well - but few people realize how bad that expectation is, for many reasons.
Oh well, enough cynicism for one day...
|
|
|
|
|
Oh please. You seem to have painted a broad brush across all FOSS here that doesn't universally apply here. Else the argument 'since other FOSS does it just fine ...' pokes its head up. And you ignore the acknowledged contributions I've made to this project. (Not to not acknowledge your own.)
Note that I have not suggested any more work than is already occurring. Releases and change notices are entered and present (scroll up). Arguably they could be put in the wiki (where automated notification facilities already exist) instead, and a link to it placed above. If however you wish to reinvent the wheel through codeproject one off API coding, don't let me stop you.
Wiki RSS is already present. No additional work needed - just in a different spot. [For that matter, I wonder if the wiki page could be embedded within the code project page above.]
In the mean time, please don't paint all FOSS users with the same brush. I don't expect you fall into the stereotypical (masses) FOSS user you intimate, don't paint every other FOSS user with that same brush that doesn't apply to you. Not all FOSS users are the same. Your comment is ironic - my acknowledged contributions are with the documentation.
Ideas and suggestions and questions are just that. Doesn't mean they're good ones for an environment. Part of the point of this community / forum is to discern whether they are good ones or resonate.
I asked a question that was substantially "How might I ..." - doing so doesn't deserve a beating.
|
|
|
|
|
You're quite right on all points, and I apologize. As I said at the bottom of my note, I was in a cynical mood. I'm obviously of the same mind, posting notes here to see how others are using this software (and CP), to see how we can all get more benefit. To me, that is a contribution in the spirit of FOSS.
Present company not included, I'll stand by my notes about FOSS users in general - there are a precious few folks who contribute to the model. We got a bad taste of that here when Dan took some time off a few years ago. Rather than discussing how to keep the software going, most people who commented were like rats just jumping ship to go find the next developer they could abuse into retirement. I was appalled. Having been involved with FOSS for nearly 20 years, my tainted view of how the model has been abused comes from witnessing the growing graveyard of software and disappointed developers evidenced in SourceForge, CodePlex, GitHub, Google Code, here at CodeProject, and other repositories. It comes from the multitude of wikis on popular software that go unmaintained, and forums where people are eager to ask the same questions over and over, but have no interest in the Search button. My cynicism in this area will continue until the model is revised to somehow compel people who use free software to contribute back in some small way, to better reward those who provide the core from which we benefit.
As to RSS, etc, I don't know if it was mentioned but if you look in the left margin of this page you'll see a link under Article called Revisions[^]. That's not exactly what you want but it might be of some help.
|
|
|
|
|
I hear you / choir re: general FOSS users.
However, it has occurred to me over the last couple years:
- not everyone has interest or skills in everything. But everybody uses.
- we have skills and interests and abilities that not everyone has.
- everyone else has skills and interests and abilities that we don't have.
- just because most don't contribute or show appreciation for a bit of FOSS doesn't mean they're worthless excuses for human beings. (Not that you were implying such.)
So if I apply my interests and contribute as I can to a project, and someone else doesn't, turns out that's OK. Hopefully they're doing something for someone else in some other way in this world that is valuable to others - be it laying a sidewalk, being a politician, volunteering, raising a child, or just being a friend. All of which I am (indirectly) a beneficiary of, from someone, somewhere - it's just not present in my computer life, and so invisible to my electronic circle of acquaintances. Easy to lose sight of that. Sort of changes one's (FOSS) worldview. A wee bit less cynicism, not that it's not justified, and a wee bit more tolerance, something we can all work on. (-:
Not to say the whiners don't get old, really fast. This is free, in my spare time, it's my volunteer work, and you're demanding I spend even more time to suit -your- (commercial) purpose? ... NOT.
And not to say FOSS creators don't frequently shoot themselves in the foot, casting a cloud over all FOSS developers in the process - this is what I've done, make use of it if useful to you, if you have questions or suggestions or don't understand ... sod off.
Both sides can always use more appreciation for the other ... and less ignorance all around.
And ... everything is new to everyone at some point. Easy to lose sight of that over time (TDL versions coming to mind, for me, at the moment), when we didn't know (and so don't understand) what we didn't know. My problem is I've forgotten so much that I once knew (download links -> filenames comes to mind) ...
But I do hear you / choir - in the end the real problem is those with attitudes and feelings of entitlement. Absent that, demonstrate understanding seeking without demanding, and I will work with you to the ends of the earth. Doesn't mean that after answering the same question for the umpteenth time doesn't make us cranky. (But is why I like documentation / wikis / FAQs - if I thought of it, so will others. Answer once, and we all get to move on faster.)
May everyone have a good day. Take a moment to say "Thank You." to the next volunteer you meet. Be they a computer person / FOSS participant, or not. "Thank You." just never gets old.
... Thank You! Dan.
.
|
|
|
|
|
Thx for everyone's support over the last 11 years!
modified 4-Nov-14 23:55pm.
|
|
|
|
|
Thank you for your really great software and your interest in enhancing it over all the time ...
|
|
|
|
|
A truly remarkable effort Dan. Many thanks.
zajchapp
|
|
|
|
|
Thanks for keeping us supported all this time
Alex
|
|
|
|
|