4 ms·

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

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!).

aviaviavi 8y ago
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 :)
ryandrake 8y ago
> 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.
- newhouseb 8y ago
  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.
- tijs 8y ago
  * 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)
  - aviaviavi 8y ago
    Priority does get encapsulated via the special p=INT key val. 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.
- 2trill2spill 8y ago
  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.
- honestlyidk 8y ago
  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.

aviaviavi 8y ago

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 :)

ryandrake 8y ago

> 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.

newhouseb 8y ago
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.
tijs 8y ago
* 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)
- aviaviavi 8y ago
  Priority does get encapsulated via the special p=INT key val. 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.
2trill2spill 8y ago
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.
honestlyidk 8y ago
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.