---
# System prepended metadata

title: Task data model
tags: [Product]

---

---
tags: Product
---

# Task data model

Magesmiths focus
focus on Contributor/product flow (clickup flow)
mvp of public tasks (vg)
cross-camp ideas (vg)
cleanup flowchart for magesmiths, and rangers for pres
data models (sk)
define mvp gates (jord)
feature spec template (bill & jord)
define some simple task rubriks
- refactor a component
- design a graphic for X
define some initiatives
- build better partnerships
coordinaper style tipping? (vg)

TODOs: 
design
- cleaning up files
- create style guide
populate clickup
- add task w/template
- demo a product task
- demo a ranger/paladin task

#

# Task data model

A task is a bite-sized bit of work that can be picked up and completed by a single person.

### title

### description
```
we can provide guidelines on this content
    - bug version
    - feature version
    - add for other types
```

### type
- goal / objective
    - needs breakdown to initiatives or epics
- initiative
    - needs breakdown to epics or tasks


- feature epic
    - pipeline list
    - needs breakdown into manageable tasks
    - needs to pass through ux/spec/code review gates

actionable (go into sprint lists):

- feature task
    - small completable task related to a feature and completable by a single person
- single resource (same path as bug)
    - bug
    - chore
        - not feature/app related

```types will drive workflow
view by type for 1st work flow, once into task level it can move to 'working' workflow

```

### source
- customer request
- prospective customer request
- foundations
- bright idea
    - some greenfield idea - internal/external
- bug report
- ux improvement/maintenance list
    
```source informs priority score```


### priority score (time needed by)
- super high, high, med, low, superlow
- 1-5

### perceived value score (perceived value created)
- super high, high, med, low, superlow
- 1-5

### Time 
(some questions about time as a metric)
- Seems like an important metric for appraising a task. 
- Does the dev measure the time invested?
- Do we estimate time before hand? enter actual - compare diff
- How does this relate to value added? An experienced dev is much faster than a new dev.
    - estimate time expected for an moderately experienced dev, then capture actual time. Makes explicit the cost of training/learning -- perhaps if a junior dev stays with the project past some threshold (like a couple months), they can be paid for the extra time they spent on tasks.
- If a pure value added is preferable, then how do we account for 'surprise' tasks that were undervalued or overvalued?
    - one possibility: each task gets a value and two time fields: an estimate and and actual. The `value_expected` can be compared with `time_expected` to help make decisions about what to work on, and `time_actual` can be used to assess if extra compensation is required based on effort involved. Could even add a `value_actual` to close the loop, which could be used to assess if a bonus should be paid e.g. for work on a surprisingly valuable task.
 

### status 
- backlog
    - space level
- ready
    - space level
    - need to specify what for? e.g. design vs. dev
- claimed
    - space level
- in gate
    - list level (magesmiths for sure)
    - need to specify which gate?
- complete
    - space level
- validation
    - list level
    - time added/value added/on post sprint report/measured
    - let's leave this off list for now to generalize



```
drives workflow and workflow changes by type
these probably vary by type - if it's a task for ranger it can have different values
```
### problem statement 
- [ ] - build draft spec
### ux gate
- [ ] - is all ux accounted for in the spec
### spec gate
- [ ] - check spec ready to code
### code review gate
I started a JS code review guide. (Jord)  
- [ ] - validate use-cases are met by the code


https://hackmd.io/QFznvlJEQbePCTfxih7v4A
### qa gate

```
gates only needed on feature epics 
maybe each gate has
    - complete/not needed
    - completed by
```

### simple task flag


// at what level do we add gate fields?
// // pipeline list?


keep sprint lists

pipeline can be broken into many lists if needed



### Week of 4/12

goal/initiative scoring vs. task scoring
    - new fields, maybe new units for goals/initiatives 

goal/initiative relationships to tasks



#### Playbook


tags
- bugs
- skills

end
- add actual time spent

