Team Task Management

[dendron-bot]

Goals

Better automation of tasks for the Dendron Team

Context

Creating tasks inside Dendron is powerful and flexible. Its easy to link to existing issues and reference inside other tasks.
We've reached a point now where this is becoming hard to scale, with over a dozen full time people and close to a thousand tasks.
This RFC looks into improvements in pods as well as task notes to evolve Dendron into a

Proposal

1. All items we're tracking should be available as a github issue
2. We should use task notes for all tasks internally
3. We should use the github pod to update and sync tasks to github
4. We should use github projects ¹ to provide higher level organization to our tasks
   • sample board

Details

1. All tasks should belong in one of the following areas:

• sprint: tasks we are doing this week
• epic: tasks we are doing this month
• backlog: tasks we are doing this calendar year (we'll count all backlog items this year as both 2021 and 2022)
• icebox: tasks we have no immediate plans to do

Tasks

• [[36 Pods V2|dendron://dendron.dendron-site/dendron.rfc.36-pods-v2]]
• task notes method for marking task as done
• task note expose hook to run custom action when the status changes ^MSZbKVmb0c6S
  • run pod: run a pod that has access to metadata from task note
  • append to: add link to task note to another note
• task note support archiving a task ^MFOcdUFJnt1Y
• task note support to make methods work with a selection (eg. highlighting 5 tasks while running task archive should archive all 5 tasks) ^XEk2lz8CrMK7
• task note support convert to task method ^d3jvrN81ig7t
  • adds task note metadata to existing task
• github pod support ability to create comments ^IhpPQX5pKLON

Example

Sprint Planning

Planning

1. When planning tasks, create tasks for individual team members and add it to the [[Weekly Journal|dendron://dendron.handbook/handbook.sop.weekly-journal]] ^FjqjKTGhP02x
2. Tasks should be created with the following metadata

   # optional, only fill in if high priority
   prio:
   # github milestone
   milestone: 
   # team member that is responsible
   owner:

3. During sprint planning, the team lead will copy all tasks and run Pod Export: Github ² to create github issues for the weekly tasks

Execution

1. As tasks get completed, individual team members can update the status of the issue
   • eg.

   status: DONE

2. To update the project, the can be in the task note and run Pod Export: Github ³ to update the task

Wrap Up - Phase I

1. After we have released the weekly build, all task notes should be marked done
2. When task notes are marked done, [[task note automation|#^MSZbKVmb0c6S]] should do the following
   • add the following comment using the [[github pod|#^IhpPQX5pKLON]]:
     • NOTE: the milestone is available in the task note metadata

     this should be fixed in v{{fm.milestone}} of Dendron. please post here if not, otherwise this issue will auto close in 4 days

   • add the status.needs-info tag to the issue

Wrap Up - Phase II

1. At the end of the auto close period, tasks should either be closed or have additional comments
2. The team lead goes back to the [[weekly journal|#^FjqjKTGhP02x]] created at the onset of the sprint, [[highlights|#^XEk2lz8CrMK7]] all tasks, and [[archives|#^MFOcdUFJnt1Y]] them
3. Tasks that have additional comments and need to be addressed go through the triage process

Executing Queries

The nice thing about having tasks syncwith github projects ¹ is that it supports filters and queries on tasks.
It can answer questions like:

• all tasks that are assigned to me that are due this week/month/year
• see all tasks grouped by status
• see all tasks grouped by milestone
• sort all tasks by status

Backlog Grooming

1. Go through tasks using github project
2. Update milestone, status, assignment, etc
3. Run Pod Import: Github to sync changes back into workspace

Handling User Submitted Issues

1. As part of weekly planning, oncall imports all new issues using the github pod. They can work with the team lead to assign status labels to all tasks

Backfill - migrating existing tasks to this system

1. Start by only adding tasks for current sprint into the project
2. As we gain more confidence in the system, start [[converting|#^^d3jvrN81ig7t]] tasks from backlog

FAQ

Isn't this overly dependent on github projects? Its beta software and could change

The source of truth for all tasks is still Dendron. Github projects is just the presentation layer as well as a convenient way of bulk editing and traiging tasks. If it ever goes away or we decide on something different, we just have to change the github projects specific bits into something else

What about private tasks or projects?

We can either publish tasks into a private repo with a private project or publish to a different tool like airtable.

What about tracking bigger projects?

Create a project label and create a custom github project that filters on the project label

Related

• [[Task Sources|dendron://private/dendron.ref.tasks#task-sources]]

Discussion

https://github.com/dendronhq/dendron/discussions/new

Footnotes

1. About projects (beta) - GitHub Docs ↩ ↩²

2. [[36 Pods V2|dendron://dendron.dendron-site/dendron.rfc.36-pods-v2#^k2tGQOBXQrOK]] ↩

3. [[36 Pods V2|dendron://dendron.dendron-site/dendron.rfc.36-pods-v2#^NWDbwthvJ0xm]] ↩

[SeriousBug]

I like the idea, I think it increases transparency of Dendron's development process.

This is not necessary right now, but could we set up a bot that auto-exports everything (i.e. a Github action that runs the export pod through the CLI) so that manually running the export pod is not necessary? We could even build our own Github action that others can use this for their own project easily too.

[nickolay-kondratyev]

Looks like a good way to integrate with existing tooling

[jonathanyeung]

Nice! I think this is an essential revamp to our processes.

Some comments:

optional, only fill in if high priority
prio:

Let's just expand this to use the full word 'priority'?

Should we consider cost and burn down metrics yet? I.e., this task has a cost of 5 days, it currently has 3 days left, etc. In my past experience, it's only moderately helpful to have these metrics be as granular as having a numeric value (as opposed to S, M, L, XL), but having a way to measure partial progress on bigger tasks is useful.

All items we're tracking should be available as a github issue

Are we saying all work should be tracked in a github issue, or only all work that will lead to a code change? IMO, probably cleaner for it to be the latter.

We should be careful to decouple task notes from Github Issues. That is, we should be able to interface between task notes with other platforms (Trello, JIRA, etc.) in the future. As an aside - here is a potential situation where I'm thinking that having a note be able to support multiple types could be useful. A note is both a dendron.task and also a github.issue - We can then support dendron.task functionality, but then also github.issue specific fields/functionality.

Practically speaking (for our immediate benefit, not talking about long term strategy), how should we create a new task? Do we start by creating a github issue and then importing it, or do we start by creating a task note in Dendron and then exporting it? Either way, it needs to be quite frictionless.

task note expose hook to run custom action when the status changes

We might need to be careful here...ideally, we say that the state in github aligns with our task states in dendron remote; i.e. it probably makes most sense for this hook to run when we commit and push rather than when we update locally. I can see us falling into scenarios where multiple people are attempting to triage locally, and we get into inconsistent states. It may be an acceptable compromise to not auto-run a hook right now, and need the user to run the pod explicitly once they are done with the local triage? That we we are pretty intentional when we want to change things remotely? Not sure, maybe we can see how it goes.

Wrap Up - Phase II
The team lead goes back to the [[weekly journal|#^FjqjKTGhP02x]] created at the onset of the sprint, [[highlights|#^XEk2lz8CrMK7]] all tasks, and [[archives|#^MFOcdUFJnt1Y]] them

It'd be great if the pod or some command can automate this. I'm worried this step might be quite process heavy? Maybe we'll just need to try it out to see if that's the case. For me, ideally this can be done within the github projects UI, and after all tasks have been properly closed out or updated, we just import that state back into Dendron.

[elasticdotventures]

disclosure: I'm very new to dendron so I'm trying to get up to speed, a lot makes sense, somethings don't.

RE: "Prio"
PLEASE don't abbreviate ANYTHING -- keep attribute fields contextual or if you're trying to actually save space or whatever then use an emoji or equivalent pinyin character "地位" (status) with an i18n substitution table.

The rule should be: making humans create synapses is an expensive operation. Each new synapse required to use dendron will shrink the user-base.

Avoid burning synapses to save a few keystrokes.

In fact super productive users are starting to adopt stenography in-lieu of typing and so things like 'prio' are anti-helpful since they aren't real words.

Use intellisense in VSCode to make typing easier, expand enumerations, don't make new words -- there are better ways to speed up interfaces such as pre-populating templates so I don't need to remember all the fields and make it easy to customize my own defaults.

RE: Github issues.
Budgeting time etc. isn't exactly the strength of github's project management, it's more about being open and transparent to the community. It's not about high speed triage.

Github specifically has a client "gh" for accessing issues, feature requests, etc. (it's super easy to setup)
it can be used to remotely synchronize state of issues, etc.

I'd suggest whatever agent dendron has/is planning to have should be able to use that 'gh' interface, it's like git but specifically for github functionality.

[kevinslin]

Let's just expand this to use the full word 'priority'?

open to it. it does mean changing the existing implementation (currently configured to use priority). maybe we can add a doctor command to migrate

Should we consider cost and burn down metrics yet?

those are useful. the question is if we want to build them in or have a way for users to define their own attributes. eg. Taskwarrior - User Defined Attributes (UDA)
maybe this is starting to merge with the note type system...
user should be able to configure frontmatter for a default tasknote. for an individual, cost and burndown might not be that meaningful (and even for some teams)

Are we saying all work should be tracked in a github issue, or only all work that will lead to a code change? IMO, probably cleaner for it to be the latter.

Latter

We should be careful to decouple task notes from Github Issues. That is, we should be able to interface between task notes with other platforms (Trello, JIRA, etc.) in the future. As an aside - here is a potential situation where I'm thinking that having a note be able to support multiple types could be useful. A note is both a dendron.task and also a github.issue - We can then support dendron.task functionality, but then also github.issue specific fields/functionality.

So one thing to decouble is note types and pods. A task can be synced with a github issue when we export (at which point it has a github issue id). this would be different from a note type (eg. tasks, journal, etc)

Practically speaking (for our immediate benefit, not talking about long term strategy), how should we create a new task? Do we start by creating a github issue and then importing it, or do we start by creating a task note in Dendron and then exporting it? Either way, it needs to be quite frictionless.

Create in Dendron. At end of the day, we can do a daily export of all tasks (for immediate feedback, user can export their task as well)

We might need to be careful here...ideally, we say that the state in github aligns with our task states in dendron remote; i.e. it probably makes most sense for this hook to run when we commit and push rather than when we update locally. I can see us falling into scenarios where multiple people are attempting to triage locally, and we get into inconsistent states. It may be an acceptable compromise to not auto-run a hook right now, and need the user to run the pod explicitly once they are done with the local triage? That we we are pretty intentional when we want to change things remotely? Not sure, maybe we can see how it goes.

I like the "onPush" concept. maybe like workspace sync, this can be configurable (eg. execute immediately vs onPush)

It'd be great if the pod or some command can automate this. I'm worried this step might be quite process heavy? Maybe we'll just need to try it out to see if that's the case. For me, ideally this can be done within the github projects UI, and after all tasks have been properly closed out or updated, we just import that state back into Dendron.

I think we'll find out once we try this out. This process should just be highlighting your tasks and running "mark as complete"

[SeriousBug]

Let's just expand this to use the full word 'priority'?

open to it. it does mean changing the existing implementation

Is this something with the GitHub pod? Task notes already use the priority key and not a shortening. They just get displayed as prio:something in the editor highlighting.

[kevinslin]

actually, it’s just in the proposal. it’s already implemented like this so no change necessary

[kevinslin]

Some additional thoughts on tasks:

• all tasks in Dendron should just be task.{date}.title
  • makes it easy to find all tasks
  • easy to import/export
• a tasks can contain other task notes
  • if a task note detects wikilinks to other tasks, it should be able to show progression as decorate, see https://www.loom.com/i/c347cf35e86745f2831e61e2b5ce91e4
  • optionally, we can gate this to be tasks mentioned in a specific seciton (eg. inside ## Tasks secion of the note)