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!).
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 :)
> 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.
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.
* 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.
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.
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/
44 comments
[ 2.7 ms ] story [ 84.4 ms ] threadhttps://github.com/naholyr/github-todos
Not used it myself
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!).
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.
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)
Also the edits you make in the UI actually are applied to the code! :D
My work flow is running a toodles server in a copy of our repo they we reserve for toodles, and commit the changes after planning meetings or similar.
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?
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.
I created an issue suggesting a docker container, hope that's not annoying!
PS in case it helps others: for macOS10.12 + brew, I had to add:
to `~/.stack/global-project/stack.yaml`I'll probably just upload some binaries to start, but that's a good next step
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.
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 :)
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.
https://edgeguides.rubyonrails.org/command_line.html#rails-n...
If you use Xcode, this link has a pretty nice script you can add as a Build Phase, and it generates warnings out or TODOs.
https://crunchybagel.com/xcode-todo-warnings-swift
Example: https://maven.apache.org/plugins/maven-project-info-reports-...
* https://probot.github.io/
* https://github.com/JasonEtco/todo