We used something like this on the teams I lead at Dropbox to (what I felt) was great effect. We had a script that would regularly run and sync with Phabricator, our bug tracking tool of choice.
One thing that we did differently, however, was to "assign" TODOs based on project or team rather than individual people. This way we could triage issues more flexibly to people according to their workloads and also build in more immunity to organizational change (when I was around we still had TODOs for the founders -- ten years in!).
> One thing that we did differently, however, was to "assign" TODOs based on project or team rather than individual people.
If this works for your team, that’s awesome, but beware, I think you’d need a very disciplined team with good communication for this to work. I’ve found on some teams, if a task is not assigned to a single individual, nobody feels “on the hook” to do it. Things assigned to a group can tend to pile up un-looked-at, because everyone thinks someone else will take care of them. You can fix this by having some kind of rotating duty, where people pick up ownership of issues on some schedule but if you’re going that far might as well just assign directly from the start.
* differentiate between backlog and ready for development: (bi)weekly triage
* bugs first, then code reviews, then features
* order features by priority; PM? Triage as well?
* work ready for development list top to bottom
Looks like the tags and keyvals could cover some of that. Maybe a bit hard to express priority (or change it).
Would be neat if changes in the dashboard would update the todos in your code (bit scary though)
What? Your team doesn't pick up unassigned tasks when they are done with their work? What's the alternative? When I'm done with a story I look in the backlog which is roughly ordered by priority and find a story that's in an area I know and start working on it.
Right, we would triage these TODOs as part of a larger cadence once every week (or maybe every other?... it was a while ago). If a given TODO was both important and urgent, someone would be specifically assigned to address it.
looks like the team was lazy in some regard or some other negative adjective if "lazy" is too mean:
-dev has extra time
-queue has tasks ready to be done
-dev doesnt do tasks becuase they are not specifically assigned to them
I will some times look into tasks that are assigned to other people just to get an understanding on how I would solve the problem and learn the rest of the code base. I wouldnt assign it to myself unless I get approval because that would be stepping on others toes. If a dev doesnt like actively coding and isnt interested in fixing problems for the company that is not a problem with the layout that is the problem with the devs attitude.
lazy , unmotivated how ever you slice it, its unproductive. Ill say this is one reason why working at a company you enjoy is important. You should be happy to make they company better in general with small touchups or performance refactor overhauls. What good is a "todo" list if its just a list of things people wont do.
Very cool! Assigning to teams definitely makes sense. I built this to help organization at a 4 person company so hopefully we'll grow enough to one day exercise that strategy :)
Looks interesting! I'm looking forward to trying it.
The annotation syntax looks powerful but do people
really edit thier code to adjust priorities and
assignees?
On a related note, I review `TODO` in PRs and consider whether to allow them in the codebase; and `DEBUG` to indicate code that shouldn't even be checked in. Does anyone else have a codetag for this? DEBUG doesn't seem to be a well-known codetag, and I'd prefer to use something other people use.
> Does anyone else have a codetag for this? DEBUG doesn't seem to be a well-known codetag, and I'd prefer to use something other people use.
My team now uses `TODO(#pr)`. The #pr tag meaning it should be taken care of in this pull request, but I don't think that's common. Though maybe if toodles gets some use it will become more common :)
Ah sorry that was a little confusing. "#" signifies a tag / label in toodles, so #pr means adding the literal "pr" tag to the todo. So we're not adding a PR number.
We used FIXME to denote temporary changes that shouldn't be checked in, or sections which hadn't been written yet, and had a Git hook which stopped code being committed with that tag. (It also looked for 'console.log' and 'debugger' statements in our JS and blocked those, too.)
FWIW I have seen tag NOCOMMIT used to indicate that a commit should be rejected by a pre-commit hook.
Useful when you're putting in debug logging statements you want to remove later, or hard-coding your own credentials during development with the intent on making them configurable later, etc.
I made the very same thing years ago. I remember ending up removing the web-interface and use the CLI and vim-wrapper instead. I still think the syntax of the comments etc was pretty good http://hkjels.github.io/ntask/
Neat! We use a TODO.md, but this solution can keep track of the exact position. Looks very useful.
If there's a way that the developers can run it without installing the Haskell suite (maybe binary releases for Windows, Linux, macOS), we will try it.
Does it ignore paths like node_modules/ and others or support command line arguments for that?
> If there's a way that the developers can run it without installing the Haskell suite (maybe binary releases for Windows, Linux, macOS), we will try it.
Great, I was waiting for someone to ask for a binary distribution before actually going ahead and setting it up. I'll go ahead and do that then.
> Does it ignore paths like node_modules/ and others or support command line arguments for that?
Yes, you set a list of regexes per project for toodles to ignore.
One thing that we did differently, however, was to "assign" TODOs based on project or team rather than individual people. This way we could triage issues more flexibly to people according to their workloads and also build in more immunity to organizational change (when I was around we still had TODOs for the founders -- ten years in!).