Project Dakota Contribution Guide

[castrojo]

"So you're telling me this one heals itself?"

https://github.com/projectbluefin/dakota

Ok here's how it works. One thing that sucks about Linux is people spend all their time manually copying the same info around all day. So this automates you reporting an issue. This process will not be automated, but we'll make it nice and easy.

This is designed for people to contribute back useful information to upstream projects. So why not do that in the open, it is in fact, the reason this stuff is so good lol. So we're not automating and using telemetry with an agent (that's so 1990s) instead we're giving the users the chance to dive in and talk more high level instead of wasting time on toil. Issue trackers for humans are just toil, so let's make them suck less!

So Dakota will be built with this in mind. Also we gotta get the agents in control here, there's good stuff, so we're going to use it right, I had to ask around and found a guy named Andy who is going to help.

Built-in feedback loop

Dakota doesn't eat tickets, it treats them as evidence.

Every user running Dakota is part of a structured loop that flows directly back into upstream GNOME, freedesktop, and the kernel. When something breaks on your hardware, you have three commands:

Command	What it does
ujust report	Captures your system state and opens a pre-filled issue. One command instead of a wall of "please attach logs."
ujust confirm <issue>	Tells the team your hardware hits the same bug. Adds a hardware fingerprint to the issue — no duplicate filing.
ujust verify <issue>	After a fix ships in a nightly, confirms it works on your machine. Closes the loop with evidence.

No telemetry. No phone-home. Every report is reviewed by you before it leaves your machine, lives in a gist you own, and can be deleted anytime.

Then we'll figure out how many reports to close.

The hardware layer

Each Dakota installation is designed to run as a hardware diagnostic lab for itself. When will you find your first?

Read the full feedback loop design

The research behind it

This is insane, we're using some real cool tech for this. Dakota's feedback loop model is grounded in Andy Anderson's work on autonomous AI-assisted software development. The core finding: the intelligence of a system like this lives not in any single model, but in the infrastructure of instructions, tests, metrics, and feedback loops surrounding it.

• The AI Codebase Maturity Model — the arxiv paper
• When AI agents become contributors — CNCF blog
• Beyond prompting: How KubeStellar reached 81% PR acceptance — The New Stack
• KubeStellar Hive — the reference implementation Dakota draws from

[castrojo]

How we will try this

Sounds like some AI mumbo jumbo and we're all going to get eaten by raptors - we're keeping this one contained in Dakota only. I am excited to see who will find the first GNOME issue! Soon you'll be able to run the whole test suite so we can kill that stupid keyring login bug forever.

The way it works (please read Andy's stuff!) is the humans are going to drive the issues, the designs, all of it, until it's in a decent enough place where agents can do it. People with agents can just donate their token time on well scoped, reviewed issues. And andy built a system that will manage that for us. This is cutting edge stuff so why not fix our computers?

This will land in the next dakota build, feel free to submit test issues we need to practice! This is also awesome for those who are less technical who can do design and PM work with plain language and then we'll see how good it comes out.

dakota.projectbluefin.io - all human dakota design discussion here.

Leave a comment, push back on the design, or share how your hardware is affected. When a discussion reaches consensus, a maintainer marks it status/approved and it enters the contributor queue.

If you got an agent and ready to build something? See the agent-ready queue for issues with clear acceptance criteria and no open questions.

And then we're going to put the clankers to work. Dakota only because who knows what's happening. THIS IS A CONTROLLED EXPERIMENT IT HAS BEEN ZERO DAYS SINCE THE LAST RAPTOR ATTACK.

LIFE FINDS A WAY.

[castrojo]

hive.projectbluefin.io

The issue templates have also been optimized, so if you have agent time to donate to the project follow the links.

We've also got some incoming ujust report bugs, so if there's something wrong with your machine or you find a bug, use it so we can fix it! WE'VE ALREADY FIXED BUGS.