Thread

Hey Dam1an

I actually wrote my own project management software for managing tasks/projects although I need to get around to finishing it off.

one of the features I was going to implement (i’m not sure if someone has suggested this already) is the ability to clockin/clockout for projects, so other users can see if your current working on a project and once you clockout you can see exactly how long you’ve spent on a particular task or project.

I’ve got my software hosted online at home. If you’d like I can give you a login so you can play around with mine, just PM me or just signup http://dev.mariovisic.com/R-Project/, it’s not finished by any means (you’ll probably notice the profiler at the bottom). but might give you another look on it.

Hi CC, yeah thats been discussed although not quite in that way
What I was thinking is instead of just clocking into a given project, was to have a start/stop times on your tasks, so you don’t have to fill in time sheets (I think it was me and Gary that where discussing this)
2 concerns that he mentioned where
1. Is this information made available to the client, should it be optional? Do you want your clients to know you just spent 2 hours on a £10,000 project?
2. Should other people in the team see other users time stats, or just the PM? If I see I constantly put in twice as many hours as someone else, I may get annoyed by that (ignoring all variables like how efficient a given worker is for now)

What are your thoughts on this? Yes/no/maybe?

well yeah, essentially the system would record when you start/stop working on the project. with your concerns I suppose it’s up to you, if you spend 2 hours on a £10,000 project then your probably overcharging a little, although realistically you should be able to select who has the information.

If i were creating it I would only show clockin/clockout times created by your own user, you shouldn’t really be able to see other peoples clockin/clockout times. Although maybe just show if they are currently working on a project or not, as that would be useful to know. This is just my opinion though.

In the end, the user that’s going to be using your system will know best, so just try and think through a users eyes, then you’ll probably realize if it’s beneficial or not to show that information and to who!

A nice feature of Jira that I don’t believe has been mentioned is the ability to link issues.  You select an issue, pick link, and then you can pick various possibilities (e.g., This issue is related to __ issue; this issue depends on __ issue; this issue is a dependency of __ issue, etc.).

One thing that’s nice to have in any application is the ability to hover over something for a little more info (e.g., hover over an icon to find out it means “OMG take care of this issue or you will die!” because the 16x16px tombstone might not be obvious) or click on a help icon for a longer list of help (e.g., A list of the task types).

A feature that would be low priority but could be nice is the ability to vote for (or perhaps against) an issue.  This can be great for getting quick input from other developers (or whoever is using the PMS) as to whether an issue is important or valuable.

Linking between ‘things’ is something I’d thought of, but not gien too much thought about how to best implement/present it, as it’s all too easy to just have a mess of related ‘things’ at the end of an item. I’ll have a look how Jira implement it 😊
It could work nicely with the hover over, so somwthing like this under the item
2 tasks | 1 ticket | 1 file | 2.5 hours

And hovering over a link shows more details

And I’ve thought of adding a poll feature, but as you said, it’s a low priority, although pretty simple to implement (just a lot of rows to keep track of who’s already voted)

I’d probably do it as a pretty simple table (two issue IDs and a relationship type ID, allowing you to create your own relationship types if you wanted).  For the most part, I don’t think you’d get too much of a mess, since people would only link issues when the link actually matters enough to be worth the few clicks. 😊

Can’t remember if it’s been mentioned but another great feature is parsing of comments/descriptions/etc. to automatically link ticket IDs to the appropriate issues.

And, yes, I am interchanging “issues” and “tickets” haha.

That sounds simple enough, until you want to link more then just issues/tickets
This either means having 2 IDs, the 2 table names and the relationship (which would result in a huge table) or lots of smaller tables, which have the benefit of being able to then store other information if I want to and lookups for a given type will be quicker as that table will be much smaller and I would just have to lookup the int fields
Maybe I’ll just start with relationships between one or two types of ‘things’ and then spread it out based on what works

I can’t remember if it was here or in person, but I had talked to someone about extracting dates (start off with something easier to identify) and it could then spread out to other stuff. The problem with that is, it would either involve a lot of lookups in real time to suggest linking it to a given ticket, which could slow things down, or it could do it later by which point its lost context (or it could assume it knows better then you and link it without you knowing till you go back to it)

And note to self: Go through this thread and sumarise it, cause neither me or half the people posting here now can’t remember exactly what has and hasn’t been covered

That sounds simple enough, until you want to link more then just issues/tickets
This either means having 2 IDs, the 2 table names and the relationship (which would result in a huge table) or lots of smaller tables, which have the benefit of being able to then store other information if I want to and lookups for a given type will be quicker as that table will be much smaller and I would just have to lookup the int fields
Maybe I’ll just start with relationships between one or two types of ‘things’ and then spread it out based on what works

The table could end up with a lot of entries, but it would just be storing three ints, which are all foreign keys.  I don’t think it would become much of an issue, but if you really wanted to, you could move relationships where both issues are closed to a separate table.  The good thing is that this would be an easy feature to add later on without affecting any of the existing table structures.

I can’t remember if it was here or in person, but I had talked to someone about extracting dates (start off with something easier to identify) and it could then spread out to other stuff. The problem with that is, it would either involve a lot of lookups in real time to suggest linking it to a given ticket, which could slow things down, or it could do it later by which point its lost context (or it could assume it knows better then you and link it without you knowing till you go back to it)

For starters, you could just create the links without doing lookups, so it would just be a regex and the results could be cached.  You lose the benefit of hovering over and getting more details about the issue, but you get the performance gain.  I think that’s probably something you’d have to benchmark a bit to see how much of a drop it causes.  There are a bunch of ways to tackle it (e.g., decide to cache for five minutes at a time and consider that accurate enough, create a table that shows references to tickets so you can regenerate the cache for any applicable page after an issue update, etc.), but I have no idea which would be the best without a lot of testing.  I say a simple regex without details is good enough for starting out 😊

And note to self: Go through this thread and sumarise it, cause neither me or half the people posting here now can’t remember exactly what has and hasn’t been covered

You have to write a PMS to track what to do on your PMS 😉

Ok, so this is the way I’m thinking of storing the relations (until I change my mind)

related_items
- item_1_id -- The ID of the item
- type_1_id -- Int for the type of item this is
- item_2_id
- type_2_id
- relation_type_id -- The type of relation, will initially be the ones you mentioned earlier, but allows me to add custom ones later
- deleted/active -- If this relation is active, can at a later date purge these to a seperate table if needed (as you suggested :blush:)

I can then query this like so

$this->db->where('item_1', $item_id);
$this->db->where('type_1', $type_id);
$relates_items = $this->db->get('related_items');

If I just need the numbers I can do counts, if I need the actual items, throw in a few joins and all should be ok

This whole project will run into a lot of complex caching issue, and it’s something I hope not to have to worry about till it proves to be a problem (although I obviously plan to write the best/fastest code I can, just don’t want to sacrifice flexability/understandability just yet if I don’t have to)

And you joke about needing to use a PMS to track my PMS, but part of the write up will be about how we managed the project… and in my case the anwer will be with my project 😊

Ok, so this is the way I’m thinking of storing the relations (until I change my mind)

related_items
- item_1_id -- The ID of the item
- type_1_id -- Int for the type of item this is
- item_2_id
- type_2_id
- relation_type_id -- The type of relation, will initially be the ones you mentioned earlier, but allows me to add custom ones later
- deleted/active -- If this relation is active, can at a later date purge these to a seperate table if needed (as you suggested :blush:)

I’m not sure what the type_ids refer to?  Wouldn’t the issue/ticket itself have it’s type_id stored in its table or are you planning on having multiple tables for issues?  As a minor thing, I’d make that last one inactive/active or simply is_active as a bool.  Of course, depending on what you plan on doing using that field, you may not need to store it (and instead check the status of the two issues referred to by the item_ids).

This whole project will run into a lot of complex caching issue, and it’s something I hope not to have to worry about till it proves to be a problem (although I obviously plan to write the best/fastest code I can, just don’t want to sacrifice flexability/understandability just yet if I don’t have to)

I think as long as you keep planning ahead, I think you’ll be okay on the caching issues.

And you joke about needing to use a PMS to track my PMS, but part of the write up will be about how we managed the project… and in my case the anwer will be with my project 😊

Don’t forget an incredibly long forum thread 😉

This table (related_items) will be sotring relationships between everything, so tickets, messages, tasks, milestones, files etc. Each of those will have their own table, so I need a way to identify which table the item ID is. If I didn’t have the type ID, I wouldn’t know if the related item is a ticket, task, message…

The last field will be a bool, I just wasn;t sure if I should call it something positive (is_active) or negative (is_deleted) but think I will go with the first. I plan to leave it in this table as it takes an extra lookup, which makes my life much easier and the whole thing quicker. It also means I can stop the relationship between 2 things without completing/deleting the items themselves.

Ah, I didn’t realize it would be doing more than just issue to issue linking.  I would have just thought each one would have a specific relationship that always exists (e.g., a comment is always associated with a ticket, a ticket is always associated with a milestone, a milestone w/ a project, etc.), which lets you just have a foreign key reference in each of their respective tables.  In what way do you see these other items being linked?

Well, a comment can be linked to pretty much anything (even to a comment) but even if that wasn’t the case, I need to keep this as flexible as possible, instead of forcing a given method onto them (if the choose not to use milestones, then does that mean they can’t have tickets in your example… I know it’s a silly example, but it gets the point accross)

Another thing that can be linked to pretty much everything is tasks, in most cases they will be linked to a ticket, but they could also be linked to a file (eg change background colour of image, crop it etc), to a milestone, time a time log entry (lots of tasks making up a single time entry) etc

I see what you’re saying, so that makes sense now. 😊

So here’s a quick summary of all the stuff which has been covered so far
And I just summarised a 14,000 word thread to 350 😊

- Be specific with when tasks are to be done (down to the hour)
- Gantt charts
- Nested TODO lists
- Integration with SVN (and others, but SVN first)
- Custom ticket and priorities
- Estimates and actual time tracking (Will go as low as 15 minute blocks)
- Almost everything is optional
- API
- Per user per project scratchpad for brain dumps
- Easy way to see everything assigned to you
- Differant ‘modules’ based on project type, so a web dev project might have SVN integration, but that’s not needed in other project types
- Recurring tasks/events/milestones
- Small desktop widget with your tasks which also tracks time spent on them by toggleing the clock on and off for each tasks (this is a great example for the API)
- Start/stop timers via the website as well for tasks (list active tasks in the sidebar so you don’t forget about them)
- Per project permissions on who sees what time entries (PM sees everything, but the client and other users are optional)
- ‘Clever’ input, which understands dates in tasks and stuff and adds them to your calendar/milestones, amybe also understand actions, people and locations (very hard to implement properly but very useful)
- Import/export to iCal
- A logbook/journal
- make your own dashboard (choose exactly what you want to display)
- Keyboard navigation
- Specific to the context, so no group stuff if you’re a solo worker, also differant context if it’s an internal vs external project
- Simple (yes, that is a feature)
- Can generate task lists based on a set of lines (with nested based on indentation) in a text area, instead of one task per textfield
- Code/document approval—Also to do something (eg push it to a web server) when approved
- The ability to link almost anything to anything (if it’s got an ID, it can be linked 😊)
- Lots of hover over for more info to keep the UI clean but informative