aiolabs/webapp
1
0
Fork 0
Code Issues 16 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Discussion: What properties should a task have? #7

New issue
Open
opened 2026-01-01 16:59:12 +00:00 by padreug · 0 comments
padreug commented 2026-01-01 16:59:12 +00:00
Owner
Copy link

Context

We're building a task system for a farm community where tasks can be:

  • Assigned to specific people (e.g., "Maria, please fix the fence")
  • Open for anyone to claim (e.g., "Someone needs to take out recycling")

Before implementing, we should define what properties a task needs. This issue explores whether start/end times are necessary and what other properties make sense.

Related to: #1 (Persistent Task List)

Real-World Farm Task Examples

Task Time Constraint Recurrence Notes
Feed the chickens Morning (6-8am) Daily Time-sensitive
Clean the chicken coop Anytime Weekly Flexible
Take out recycling Before pickup day Weekly Soft deadline
Fix broken fence ASAP One-time Urgency-based
Harvest tomatoes This week Seasonal Weather-dependent
Water greenhouse Morning or evening Daily Avoid midday heat

Observation: Some tasks need time windows, others just need a due date, and some have no time constraint at all.

Comparison: Popular FOSS Task Apps

Vikunja

  • Title, description, due date, priority (1-5)
  • Assignees, labels, attachments
  • Start date, end date, reminders
  • Recurrence, subtasks, progress %

Taskwarrior

  • Description, project, tags, priority (H/M/L)
  • Due date, scheduled date (when to start), wait date (hidden until)
  • Recurrence, dependencies
  • Calculated urgency score

Nextcloud Tasks (CalDAV)

  • Title, notes, priority, categories
  • Start date, due date
  • Recurrence, completion %

OpenProject

  • Subject, description, type, status
  • Assignee, priority, estimated time
  • Start date, finish date
  • Parent tasks, related work packages

Taiga (Agile)

  • User stories with tasks
  • Status (kanban), assigned to
  • Tags, due date, attachments

Common patterns:

  • Due date is nearly universal (optional)
  • Start/end times are less common than start/end dates
  • Priority/urgency is standard
  • Assignees are standard
  • Recurrence is common for repeating tasks

Proposed Task Properties

Core Properties (Always Present)

Property Type Required Description
title string Yes What needs to be done
description string No Detailed instructions
status enum Yes open, claimed, in-progress, completed
urgency enum No critical, high, normal, low
createdBy pubkey Yes Who created the task
createdAt timestamp Yes When created

Time Properties (All Optional)

Property Type Description
dueDate date Soft deadline (YYYY-MM-DD)
timeWindow enum morning, afternoon, evening, anytime
startTime time Specific start time (HH:MM)
endTime time Must be done by this time

Question: Do we need startTime/endTime, or is timeWindow sufficient for most farm tasks?

Assignment Properties

Property Type Description
assignedTo pubkey Specific person assigned
claimedBy pubkey Who claimed an open task
openForClaiming boolean Can anyone claim this?

Location & Context

Property Type Description
location string Where (chicken coop, barn, field 3)
area enum Predefined farm areas

Recurrence (Future)

Property Type Description
recurrence object daily, weekly, custom pattern
parentTask reference Template task for recurring instances

Incentives

Property Type Description
reward number Sats bounty (see #4)

Time Handling Options

Option A: Time Windows (Simpler)

timeWindow: "morning" | "afternoon" | "evening" | "anytime"
  • Less precise but often sufficient
  • "Feed chickens" → morning
  • "Clean coop" → anytime

Option B: Specific Times (More Precise)

startTime: "06:00"
endTime: "08:00"
  • Useful for scheduled activities
  • "Water plants before 10am"

Option C: Hybrid (Recommended?)

  • Use timeWindow for general tasks
  • Allow optional startTime/endTime for precise scheduling
  • If both provided, specific times override window

Questions for Discussion

  1. Time windows vs specific times - Is "morning/afternoon/evening" sufficient, or do we need exact times?

  2. Assigned vs open tasks - Should these be separate task types, or a property toggle?

  3. Location taxonomy - Free-form text or predefined farm areas?

  4. Recurrence - Build in now or add later?

  5. Dependencies - "Can't do X until Y is done" - needed for farm work?

  6. Estimated effort - Should tasks have time estimates (30 min, 2 hours)?

  7. Required skills/tools - "Needs chainsaw certification" or "Bring shovel"?

Proposed MVP Properties

For initial implementation, suggest keeping it simple:

interface Task {
  // Core
  title: string
  description?: string
  status: 'open' | 'claimed' | 'in-progress' | 'completed'
  urgency?: 'critical' | 'high' | 'normal' | 'low'
  
  // Time (all optional)
  dueDate?: string        // YYYY-MM-DD
  timeWindow?: 'morning' | 'afternoon' | 'evening' | 'anytime'
  
  // Assignment
  assignedTo?: string     // pubkey - specific assignment
  claimedBy?: string      // pubkey - who claimed it
  
  // Context
  location?: string       // free-form for now
  
  // Incentive
  reward?: number         // sats
  
  // Metadata
  createdBy: string       // pubkey
  createdAt: number       // unix timestamp
  completedBy?: string    // pubkey
  completedAt?: number    // unix timestamp
}

Add startTime/endTime, recurrence, and dependencies in future iterations based on actual usage patterns.

Feedback Welcome

What properties are essential for your farm workflow? What's missing? What's unnecessary?

## Context We're building a task system for a **farm community** where tasks can be: - **Assigned to specific people** (e.g., "Maria, please fix the fence") - **Open for anyone** to claim (e.g., "Someone needs to take out recycling") Before implementing, we should define what properties a task needs. This issue explores whether **start/end times are necessary** and what other properties make sense. **Related to:** #1 (Persistent Task List) --- ## Real-World Farm Task Examples | Task | Time Constraint | Recurrence | Notes | |------|-----------------|------------|-------| | Feed the chickens | Morning (6-8am) | Daily | Time-sensitive | | Clean the chicken coop | Anytime | Weekly | Flexible | | Take out recycling | Before pickup day | Weekly | Soft deadline | | Fix broken fence | ASAP | One-time | Urgency-based | | Harvest tomatoes | This week | Seasonal | Weather-dependent | | Water greenhouse | Morning or evening | Daily | Avoid midday heat | **Observation:** Some tasks need time windows, others just need a due date, and some have no time constraint at all. --- ## Comparison: Popular FOSS Task Apps ### Vikunja - Title, description, due date, priority (1-5) - Assignees, labels, attachments - Start date, end date, reminders - Recurrence, subtasks, progress % ### Taskwarrior - Description, project, tags, priority (H/M/L) - Due date, scheduled date (when to start), wait date (hidden until) - Recurrence, dependencies - Calculated urgency score ### Nextcloud Tasks (CalDAV) - Title, notes, priority, categories - Start date, due date - Recurrence, completion % ### OpenProject - Subject, description, type, status - Assignee, priority, estimated time - Start date, finish date - Parent tasks, related work packages ### Taiga (Agile) - User stories with tasks - Status (kanban), assigned to - Tags, due date, attachments **Common patterns:** - Due date is nearly universal (optional) - Start/end times are less common than start/end dates - Priority/urgency is standard - Assignees are standard - Recurrence is common for repeating tasks --- ## Proposed Task Properties ### Core Properties (Always Present) | Property | Type | Required | Description | |----------|------|----------|-------------| | `title` | string | Yes | What needs to be done | | `description` | string | No | Detailed instructions | | `status` | enum | Yes | open, claimed, in-progress, completed | | `urgency` | enum | No | critical, high, normal, low | | `createdBy` | pubkey | Yes | Who created the task | | `createdAt` | timestamp | Yes | When created | ### Time Properties (All Optional) | Property | Type | Description | |----------|------|-------------| | `dueDate` | date | Soft deadline (YYYY-MM-DD) | | `timeWindow` | enum | morning, afternoon, evening, anytime | | `startTime` | time | Specific start time (HH:MM) | | `endTime` | time | Must be done by this time | **Question:** Do we need `startTime`/`endTime`, or is `timeWindow` sufficient for most farm tasks? ### Assignment Properties | Property | Type | Description | |----------|------|-------------| | `assignedTo` | pubkey | Specific person assigned | | `claimedBy` | pubkey | Who claimed an open task | | `openForClaiming` | boolean | Can anyone claim this? | ### Location & Context | Property | Type | Description | |----------|------|-------------| | `location` | string | Where (chicken coop, barn, field 3) | | `area` | enum | Predefined farm areas | ### Recurrence (Future) | Property | Type | Description | |----------|------|-------------| | `recurrence` | object | daily, weekly, custom pattern | | `parentTask` | reference | Template task for recurring instances | ### Incentives | Property | Type | Description | |----------|------|-------------| | `reward` | number | Sats bounty (see #4) | --- ## Time Handling Options ### Option A: Time Windows (Simpler) ``` timeWindow: "morning" | "afternoon" | "evening" | "anytime" ``` - Less precise but often sufficient - "Feed chickens" → morning - "Clean coop" → anytime ### Option B: Specific Times (More Precise) ``` startTime: "06:00" endTime: "08:00" ``` - Useful for scheduled activities - "Water plants before 10am" ### Option C: Hybrid (Recommended?) - Use `timeWindow` for general tasks - Allow optional `startTime`/`endTime` for precise scheduling - If both provided, specific times override window --- ## Questions for Discussion 1. **Time windows vs specific times** - Is "morning/afternoon/evening" sufficient, or do we need exact times? 2. **Assigned vs open tasks** - Should these be separate task types, or a property toggle? 3. **Location taxonomy** - Free-form text or predefined farm areas? 4. **Recurrence** - Build in now or add later? 5. **Dependencies** - "Can't do X until Y is done" - needed for farm work? 6. **Estimated effort** - Should tasks have time estimates (30 min, 2 hours)? 7. **Required skills/tools** - "Needs chainsaw certification" or "Bring shovel"? --- ## Proposed MVP Properties For initial implementation, suggest keeping it simple: ```typescript interface Task { // Core title: string description?: string status: 'open' | 'claimed' | 'in-progress' | 'completed' urgency?: 'critical' | 'high' | 'normal' | 'low' // Time (all optional) dueDate?: string // YYYY-MM-DD timeWindow?: 'morning' | 'afternoon' | 'evening' | 'anytime' // Assignment assignedTo?: string // pubkey - specific assignment claimedBy?: string // pubkey - who claimed it // Context location?: string // free-form for now // Incentive reward?: number // sats // Metadata createdBy: string // pubkey createdAt: number // unix timestamp completedBy?: string // pubkey completedAt?: number // unix timestamp } ``` Add `startTime`/`endTime`, recurrence, and dependencies in future iterations based on actual usage patterns. --- ## Feedback Welcome What properties are essential for your farm workflow? What's missing? What's unnecessary?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
atio
demo-newui
feat/link-agg/newlayout
feature/link-aggregator
demo-login
cfaun
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: aiolabs/webapp#7
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?