Repository navigation
📋 Roadmap: vote on what ships next (👍 the linked issues) #52
Description
Vote on what ships next. 👍 the issues below — the counts genuinely reorder ROADMAP.md.
This project has one maintainer, so the ordering of the "Next" list is currently a guess. A reaction takes two seconds and replaces a guess with a signal. There is no other voting mechanism, no committee, and no weighting by who you are.
How to vote
👍 the individual issue, not this one. Reactions here don't tell anyone which item you want. Click through and react on the issue itself.
| Vote on | What it is | Issue |
|---|---|---|
| 🧠 Local / self-hosted LLM as a first-class path | OPENAI_BASE_URL already works with Ollama and OpenAI-compatible endpoints, but it isn't documented or tested as a supported path. This is the item people ask about most: it's what makes KubeIntellect usable where cluster data cannot leave the network. |
#17 |
| 📊 More observability backends — Tempo, Pyroscope | Today it correlates kubectl + Prometheus + Loki. Traces and profiles are the obvious next evidence sources for root-cause analysis. | #18 |
| 🔗 Composable detectors (AND / NOT / temporal windows) | Detectors currently fire on single predicates. Composition is what separates "a pod restarted" from "a pod restarted three times in ten minutes while memory climbed". | #21 |
📈 PromQL execution inside playbook detect blocks |
Playbooks can store PromQL but not run it. Closing that gap makes a playbook self-contained. | #20 |
| 🕸 Temporal knowledge graph: ingest nodes / events / PVCs | The graph currently models pods and deployments. Node pressure and PVC state are where a lot of real incidents actually start. | #19 |
| 📚 Grow the playbook library beyond 18 | One YAML file per failure mode. The lowest-barrier way to make the product measurably better, and a good first issue. | #13 |
Vote with your problem, not just your thumb
A 👍 tells the maintainer what. A comment tells them why, which is what actually
changes the design. The most useful comment on any of those issues looks like:
We run 4 EKS clusters and can't send pod logs to a hosted model for compliance reasons, so
#17 is the difference between "interesting" and "installable" for us.
One sentence of context like that outweighs ten reactions, because it says what "done"
has to mean.
Something missing?
- A problem you have that isn't listed → open a Discussion. Describe the problem, not the feature — problems are more useful than solutions.
- An architectural change → open an RFC issue. It gets discussed and recorded before implementation.
- Comment below if you think the whole list is ordered wrong. That is a legitimate answer.
Before you vote, know what's not coming
Saying no clearly is part of a roadmap. Autonomous remediation on by default, replacing your observability stack, becoming a GitOps pipeline, bypassing RBAC for convenience, and reviving v1/–v3/ are all decided against, with reasons, in ROADMAP.md § Explicitly not planned. Voting won't move those, and you deserve to know that before spending a click.
Also: if you're running KubeIntellect anywhere, #51 is the thread for that — knowing which environments are real is what decides what gets tested.
Activity
MSKazemi commentedon Aug 10, 2026
Status check, 2026-08-10: there are currently zero votes on all six items.
I would rather say that plainly than leave this thread looking like a race someone is winning. Nobody has voted because almost nobody knows the project exists yet — every visitor so far arrived from the paper, from search, or from GitHub itself. It has never been announced anywhere.
So the practical situation is: the "Next" order is still entirely my guess, and a single 👍 is currently decisive. That is unusual and it will not stay true for long. If any of these matters to you, this is the cheapest your vote will ever be.
detectblocksMy current guess at the order is #17 first, because it is the one that decides whether the project is installable at all for anyone whose cluster data cannot leave their network — and "interesting but I can't run it" is the most common way a tool like this fails. I would like to be told I am wrong about that.
What has changed since this thread was written
Worth knowing before you decide the order is fine:
pip install kube-qwas serving a build whose documented subcommands did not exist. All three distributions are on PyPI and verified. If you tried this project and it did not work, that was the reason.mainnow requires nine status checks, up from five, including both test suites on Python 3.12 and 3.13.None of that changes the six items above. It does mean that if you vote for something, there is now a realistic chance of someone other than me building it.
The most useful thing you can leave here is not a 👍
It is one sentence about your situation. Reactions tell me what; a sentence tells me what "done" has to mean, which is the part I actually get wrong. Something like "we run 4 EKS clusters and can't send pod logs to a hosted model, so #17 is the difference between interesting and installable" is worth more than ten clicks.
And if you think the whole list is ordered wrong, or that the thing you need is not on it at all, that is a legitimate answer — say so here or open a Discussion. Describe the problem rather than the feature.