Deadlines Incentive

[0x4007]

After a few calls with prospective pilot partners, it’s clear that teams care about accurate time estimates and incentivizing deadlines. This command should make deadlines more useful while rewarding contributors fairly.

---

Objective

Build the command-deadline plugin to:

1. Encourage accurate time estimates by tracking task durations.
2. Reward early completion while ensuring deadlines matter.

---

How It Works

Setting a Deadline

• Use /deadline [date] to set a deadline on a GitHub issue.
• The deadline is tied to UTC by default but can be configured.
• If a GitHub Project View is linked, the GitHub issue should sync there on the timeline view (if configured).

Rewarding Early Completion

By default, finishing a task on time earns 100% of the task value. If completed faster, the contributor gets a speed bonus. If late, they either receive a reduced payout or are disqualified (configurable).

---

Deadline Reward Ratio Configuration

Instead of always giving double the task value for instant completion, we introduce a configurable coefficient:

• deadlineRewardRatio → Controls how much of the task value is used for speed bonuses.
• Default is 0.25, meaning a max bonus of 25% extra for instant completion.
• If set to 1.0, instant completion can double the reward.

For example, on a $1600 task with deadlineRewardRatio = 0.25:

• Instant completion → $1600 + $400 bonus = $2000
• Halfway to deadline → $1600 + $200 bonus = $1800
• On deadline → $1600 (no bonus, no penalty)
• Past deadline → Payout gradually decreases unless disqualification is enabled.

---

Final Reward Formula

reward = baseTaskValue * max(0, 1 + (deadlineRewardRatio * (1 - (actualCompletionTime / assignedDeadline))) - ((1 - disqualificationEnabled) * (actualCompletionTime / assignedDeadline)))

How It Works

• If completed early, the reward increases up to 1 + deadlineRewardRatio times the base task value.
• If completed exactly on time, the reward is 1× task value.
• If late:
  • If disqualification is enabled, the reward drops to 0 at assignedDeadline.
  • If disqualification is disabled, the reward gradually decreases until 0 at 2 * assignedDeadline.

---

Disqualification (Optional)

If enabled, contributors must complete the task before the deadline or they receive nothing. This can be toggled per project.

---

Mock YAML Configuration File

Here’s a sample config.yml with all possible settings and their default values:

commandDeadline:
  timezone: "UTC"  # Default timezone for deadlines (UTC, PST, etc.)
  deadlineRewardRatio: 0.25  # Max speed bonus (0.25 = 25% extra, 1.0 = 100% extra)
  disqualificationEnabled: true  # Whether missing the deadline results in a 0 reward
  projectView: null  # Link to GitHub Project View if deadlines should sync there

Configurable Behavior

• If deadlineRewardRatio = 0.5, contributors can earn up to 50% extra for early completion.
• If disqualificationEnabled = false, contributors still get some payout even if late, but it gradually declines.
• If projectView is set, deadlines will be synced to the linked GitHub Project View.

---

Final Summary

• /deadline [date] sets a deadline.
• Early = Bonus (configurable via deadlineRewardRatio).
• On time = Full payout.
• Late = Configurable penalty (default: disqualification, or gradual payout reduction if disabled).
• Deadlines can sync to GitHub Project Views if linked.

This setup keeps the system flexible, fair, and easy to configure.

[Keyrxng]

Used AI for comment structure

Accurate Time Estimates for Tasks

For time estimates to be meaningful, labels must accurately reflect task complexity. This requires a strong understanding of the codebase, whether assigned by a human or an LLM. One requires having a dedicated "repo expert" while the other requires complete codebase awareness (codebase embeddings).

Deadline-Based Incentives

A possible incentive structure:

• Tasks start with a set time limit (/start).
• Time counts down until ready for review, then pauses.
• If the PR is sent back to draft, time resumes.
• At merge, the total time taken determines a multiplier for the assignee's reward.

Similarly, reviewers could earn bonuses based on how quickly they respond to a request for review, encouraging faster merges.

Example Scenarios

1. 8hr task, merged in 4hrs → Assignee & reviewers get a bonus.
2. 8hr task, merged in 12hrs (after 2 re-drafts) → Reviewers get a bonus, assignee does not.
3. 8hr task, merged in 4hrs, but reviews took 2 days → Assignee gets a bonus, reviewers do not.

This maintains existing disqualification logic but rewards efficiency.

Potential Exploit & Counterbalance

One could delay /start, work independently, then submit quickly for an efficiency bonus. However:

1. This adds a game theory element—waiting risks someone else claiming /start.
2. Knowing this, contributors are incentivized to /start immediately if they’re confident they can finish on time.

---

An insightful move might be to gather the data from all previous tasks including:

• time assigned
• time actually taken (/start - merge)
• idle-time spent waiting for reviews
• time spent waiting for the assignee to respond to reviews
• time spent reviewing

The above would allow for better informed decisions to be made based on historical data (https://github.com/ubiquity-os/dao-analytics), especially when considering training an LLM fit-for-purpose.

[0x4007]

I really like the idea of having "two timers" and how it flips based on the draft/ready state of the pull - one timer for the assignee and one for the reviewers. One thing that is tricky though is if the timer is flipped back to the assignee but they already logged out for the day/are sleeping...then 8+ hours later when they check back in, they might have timed out/gotten disqualified.¹

The questionable part of the idea though is that it is built with our label system in mind. However I think that the interviewees want a traditional "deadline" like to input a date, which would simplify the complication I mentioned above.

So lets say a GitHub issue is created with our time and priority labels, and then a team member writes

/deadline Friday 7 February

(will need timezone configured in yml) we need to think through what happens next.

Perhaps an XP/USD bonus can be applied as a linear drop off from the moment the deadline was set, to the deadline time. I'm not sure what the max reward should be (perhaps lets default to the task price i.e. 100 USD) and then the assignee finishes halfway to the deadline time, then they receive a 50 USD speed reward.

This plugin could also disqualify the assignee if they miss the deadline.

GitHub Timeline View

We could take advantage of GitHub Projects timeline view and set the current task's timeline from now to the deadline. This will make visualization simple and use built-in GitHub APIs².

Footnotes

1. It could also be interesting to automatically switch to draft if all reviewers requested changes. ↩

2. A problem slowly dawning on me but if we have closed source partners, they may not have access to some "premium" GitHub features, like draft/ready pulls. ↩

[Keyrxng]

A /deadline [date] partner would not use assistive-pricing but instead I assume they'd call /deadline only once a task has been assigned, which would result in either a hard deadline with an ejection or reduced task value with the value being dynamic based on deadline and priority? Otherwise if using it pre-assignment then conditions can become too skewed and task completion is far less likely.

I think it raises a point that at a high level we need to know and accommodate for, what partners expect of their people.

• Is it a quota of daily hours like a 9-5 with strict deadlines and one-assignee until it's done
• Is it more laid back with dynamic deadlines and assignees, it's more open-source in nature

Then we adjust accordingly?

I imagined a slider during setup, on the left "open-source" and the right "occupational" where deadlines are far more strict, task value is reduced vs ejected (configurable) because if it's your job, you do it end of story. While the left has more dynamic and lenient deadlines, accommodating the nature of truly OS projects and their contributors who have other obligations and tasks have multiple people attempting it.

[0x4007]

This feature is definitely intended only for the closed source "occupational" side because it seems that this is the most common management style of those I had discussions with for piloting.

I think most of your previous comment spans quite a bit out of scope. We need to keep this as simple as possible or else it will never get shipped.

The primary business problem is 1. Accurate time estimates and 2. Getting people to hit deadlines.

---

I realize that the drop off should probably occur if the task is not completed by the deadline, meaning that the drop off should start after the deadline date has passed.

I suppose we can "mirror" the deadline duration to model the drop off.

For example:

• Monday the task is made with a Friday deadline (five days)
• assignee is late by 2.5 days (Sunday evening submission)
• 2.5/5=-0.5 we can take the absolute value of this 0.5 and multiply the deadline setter's reward by it.

[Keyrxng]

I think most of your previous comment spans quite a bit out of scope. We need to keep this as simple as possible or else it will never get shipped.

Agreed.

The primary business problem is 1. Accurate time estimates and 2. Getting people to hit deadlines.
I realize that the drop-off should probably occur if the task is not completed by the deadline, meaning that the drop-off should start after the deadline date has passed.

1. Accurate Estimates: Since /deadline isn't AI-powered, accuracy depends on the deadline setter’s judgment. Without AI-based pricing (which would require codebase awareness and historical data), this remains a limitation.

2. Incentives: A flat rate until drop-off misses an opportunity. Efficiency-based bonuses would push contributors to complete tasks sooner. If rewards only decrease after 14 days, many would delay serious effort until day 7–8. But if earlier completion increases earnings, contributors have a strong reason to push ahead.

This also highlights a gap—assuming reviewers are more active and efficient than contributors may not hold true, especially in smaller teams. Since reviews are crucial for meeting deadlines, penalizing only assignees ignores the impact of slow or subpar reviews—reviewers should also be accountable, so I don't think we should forget the dual-timer idea. This would help gamify the process and incentivize efficiency on both sides.

---

In my previous career, I experienced an efficiency-based bonus system (1.5x – 3x hourly rates per hour of efficiency) that was highly effective. While salaries prevented base-rate reductions, consistent inefficiency led to discussions about fit. This model might offer useful insights for structuring incentives here if catering to the "occupational" side due to salaried employees (I assume) and the new pricing logic required for /deadline.

E.G:

• A config option setting the efficiency bonus per hour banked, gives the partner complete control of bonuses including those with negative efficiency and is easier to understand and adjust vs our own formulas?
• A tiered scheme via config, where high xp/level/trusted users gain access to 1.5x, 2x, 3x bonus, partner-defined
• Bonuses could be accumulated throughout the month and released according to a config-defined schedule, this may be attractive for "occupational" according to how their current payroll works and/or risk-aversion in terms of boomerang tasks eating into bonus later in the month.

[0x4007]

1. Estimates

Think that suggestions can be made from similar issue deadlines and time estimate labels but it is highly dependent on the specific repository's code base and team members' talent.

There is a GitHub issue up to predict time labels. We can make another in the future for predicting deadlines which is dependent on this v1 to be up.

2. Incentives

I agree with your point perhaps we can start with 200% and then 100% at deadline and 0% at the end of the score decay timer.

dual-timer

Agreed but I think that it should be in v2 of the plugin. Basically we can make a task after v1 is up.

In my previous career, I experienced an efficiency-based bonus system (1.5x – 3x hourly rates per hour of efficiency) that was highly effective. While salaries prevented base-rate reductions

Can you elaborate on how efficiency was measured?

Can you reiterate your last sentence? We use the term "base pay" as a parallel to salary so I am confused. Less commonly we use the term "base rate" as a baseline multiplier for incentives in text-conversation-rewards.

[0x4007]

/annotate #66 (comment) global

[Keyrxng]

In my previous career, I experienced an efficiency-based bonus system (1.5x – 3x hourly rates per hour of efficiency) that was highly effective. While salaries prevented base-rate reductions

Can you elaborate on how efficiency was measured?

Measuring Efficiency

Each job was assigned a total estimated time, calculated by software that broke down all tasks—both large and small—using industry-wide average completion times. A buffer was added to account for unpredictability.

In our context, this translates to harvesting objective data, such as:

• Time spent completing tasks vs. assigned priority
• Cost of task vs. source lines of code (SLOC)
• etc...

Using comments and discussions to train the model is too subjective. Ideally, the model should be trained on datasets built from robust organizational statistics, with each partner having their own specific model for their needs.

The Buffer

The buffer was set arbitrarily based on priority and business value. Time tracking was digital:

• Employees signed on to a job to track active work.
• They could sign off and juggle multiple jobs to optimize efficiency.

While I wasn't involved in back-office operations, the system was designed to be EV+ for the company.

In our terms, such granular tracking is possible via the IDE although intrusive it's ideal. We could implement a /sign-on and /sign-off approach via GH comments, more friction but more accurate than the following. Or an acceptable formula that accounts for "time-off" and that sort of thing.

Accruing Efficiency

• Daily quota: 12 hours
• Job list: 16–30+ hours of assigned work

For example, completing two 8-hour jobs in a day meant accruing 4 extra hours of efficiency. Efficiency was tracked over the month and distributed in arrears to account for later fixes or adjustments.

Bonus Structure

Can you reiterate your last sentence? We use "base pay" as a parallel to salary, so I am confused. Less commonly, we use "base rate" as a baseline multiplier for incentives in text-conversation-rewards.

The system was straightforward:

• 1:1 payout ratio – Each accrued efficiency hour equaled an extra hour’s worth of pay.
• Performance boosts – Consistent high performance earned 10–20% bonuses.

In our context, I'm assuming /deadline sets the date and we have Priority to work with still so we can price-label the task, so an "hourly rate" might be calculated based on this price.

Using fixed monthly salary/wage/base pay would require injecting those figures into a config/DB per team member, which seems undesirable.

[0x4007]

In our terms, such granular tracking is possible via the IDE although intrusive it's ideal. We could implement a /sign-on and /sign-off approach via GH comments, more friction but more accurate than the following. Or an acceptable formula that accounts for "time-off" and that sort of thing

"Sign on" and "sign off" may possibly be automatically derived from what event the contributor invoked.

For example instead of writing sign on and coding, we possibly may be able to set a 30 minute buffer around each commit (let's say from the perspective of context switching)

And then we could consider a 5 minute buffer around each comment.

The idea here is that while they work, instead of manually saying when they started and stopped, we may be able to automatically calculate a roughly accurate duration of time they worked based on the specific action they took.

It seems shaky for accuracy but I couldn't imagine that manually clocking in and out is the best approach. It seems easy to make a mistake or abuse.

---

But I suppose this is getting to off topic territory but interesting to do some research around sometime.

[Keyrxng]

I'd be happy to start working on this if we could split it two manageable tasks.

1. The command itself and the new task pricing. It would involve custom time and price structuring to accompany any partner style and custom priority label handling. As well as creating a new configurable pricing system that's easy to tweak.
2. The efficiency/bonus system. Based on the above discussion including activityBuffers and configurable release/decay options.

Once the first is through and refined to match expectations regarding task price considering all factors then the second will be much easier to create a spec for.

[0x4007]

/ask write the first task specification draft. Use what I said to take precedence. Focus on making v1 as simple as possible.

[0x4007]

I realized that we can't implement rewards until the kernel is upgraded to support "payment permit requests" from every plugin.

Otherwise, again, it will need to be consolidated inside of text-conversation-rewards which is definitely wrong.

[0x4007]

No there's nothing in the spec about modifying labels. Just needs to be placed on the timeline GitHub project view.

And the rewards need to honor the deadline date of course.

[Keyrxng]

I was working off of a different understanding of how "occupational" would be using the system based on the conversation my bad.

1. Is /deadline called before or after a contributor has started the task? What is the intended usage of the command in this sense because it'll affect formulas if used improperly, at least I think so given how I'm picturing building things.
2. Since this feature as spec'd does need a solution for direct permits or kernel payment requests I'm not as confident in being able to push it through quick enough, unless everything is built around the permit generation event and we can merge in, I'll probably hold back until the prerequisites are met.

[0x4007]

1. before. Usually deadlines are known before tasks are made
2. @gentlementlegen will get a start on it. I imagine it will be operational in 3-4 weeks.