KubeIntellect now has contributors who are not me — what shipped, and who shipped it

[MSKazemi]

This is the first of these, and it exists because the project crossed a line worth marking: KubeIntellect now has contributors who are not me.

Five people have commits in the repository. Three of them arrived in the last two days, without the project ever having been announced anywhere. If you are reading this because you found the repo by accident — that is how everyone here found it so far.

Who shipped what

@hariomlohardev — removed the executable bit from 94 non-script Python modules (#70), plus #57 and #65. What made #70 a model contribution is that EXE002 can be silenced two ways — chmod -x, or by adding a shebang — and the second would have passed the rule while falsely marking 94 library modules as executable programs. They checked all 94 had no shebang first, and fixed the cause.

@AdvaitVarhade — fixed the demo UI's React errors (#73), and corrected the issue while doing it: it had named the wrong file. They also proposed the kq export command and reported the Python 3.13 syntax warnings that became #63.

@shaurya703 — two PRs in one afternoon (#77, #78), both merged unmodified. The second one found something I had missed in my own issue: license-files in pyproject.toml resolves relative to each package directory, and two of our packages had no LICENSE of their own — so two published wheels had been shipping with no licence text at all. In an AGPL project that is a real compliance gap, and it was invisible from the source tree.

Contributors are credited in CHANGELOG.md, in the release notes, and now in a Contributors section on the README.

What else changed this week

Installation works again. All three distributions are on PyPI — kube-q 1.5.0, kubeintellect 2.2.0, ki-protocol 1.0.0 — and every documented kq subcommand runs from a plain pip install. For a while it did not: the published CLI predated the subcommand interface, so the docs described a tool nobody could install. If you tried KubeIntellect in the last few weeks and it did not work, that was our bug, and it is fixed:

pip install --upgrade kube-q
kq --version    # 1.5.0

PyPI now points at the right place. The kube-q package page had every link — Homepage, Repository, Bug Tracker — aimed at an old snapshot repository. Bug reports were going somewhere nobody reads.

The bar to merge went up. main now requires nine status checks rather than five: both test suites on Python 3.12 and 3.13, types, lint, install smoke test, file modes, and a syntax-warning gate. make setup from the repo root runs six of the nine locally and needs no cluster, no Docker, and no API key.

Four good first issues were closed as already-fixed. They had been sitting in the pool advertising work that was done — one of them fixed by a PR whose stated subject was something else entirely. If you picked one of those up and found nothing to do, I am sorry; that was my failure to keep the pool honest, and the remaining ones have all been re-verified against main.

If you want to help

Contributing needs only Python 3.12+ — no Kubernetes cluster, no Docker daemon, no LLM API key. The test suites are fully mocked.

git clone https://github.com/MSKazemi/kubeintellect.git
cd kubeintellect && make setup

• Open good first issues — each names the file, the reproduce command, and the command that proves you fixed it. #79 is the freshest and I ran it myself before filing, so the one surprising part is written down.
• Tell us you're using it — even "Kind on my laptop". Listed environments are the ones that get protected.
• Vote on what ships next — 👍 reactions genuinely reorder the roadmap.
• Answering someone's question in Q&A counts as a contribution and is credited the same way.

One thing that will look broken and isn't: on a first-time contributor's fork PR, GitHub runs no CI until a maintainer approves it. Your PR will sit with no checks and a blocked merge box. That is expected, it is not your fault, and you do not need to do anything.

Every issue and PR gets a human first response. There is deliberately no time promise attached to that — this is a one-person project and a number that gets missed is worse than no number — but in practice it has been same-day so far. If a thread of yours goes quiet, a nudge is welcome rather than rude.

[MSKazemi]

Update — two more contributors, six hours later.

The post above said five people had commits. It is seven now, and both landed today.

@floze-the-genius — fixed the bug where the kq test suite failed depending on your terminal (#106, #109). If you cloned this repo onto an 80-column terminal, you could watch tests fail before touching a line of code — on a suite that was green in CI. That is a miserable first impression and it was entirely our fault.

What makes this one worth reading: the fix pins the rendering environment in pytest_configure, before pytest imports the test modules, rather than in a fixture. That distinction turned out to be load-bearing, and we can prove it — see below. They also reported a full five-environment before/after matrix, and every number reproduced exactly when I re-ran it independently.

@Priyanshu608 — wrote the NetworkPolicyBlocking playbook (#99, #108), the 19th, and the only one in the set whose signal is that nothing is there. A NetworkPolicy denial is discarded in the CNI datapath: the Service is healthy, endpoints exist, DNS resolves, no event is ever emitted, and the connection just hangs. Every other playbook keys off something present. This one had to make the absence of evidence a positive finding, and it does.

And a contribution that never merged, which we owe an explicit mention. @AshSgDe29071999 independently diagnosed the same terminal bug and submitted the fixture-only fix (#107) — which clears four of the five hostile environments and still fails under NO_COLOR=1, because an autouse fixture runs after collection, by which point the module-level console already exists with the stripped theme. Running their branch as a control is the only reason we know the pytest_configure hook is necessary rather than incidental. That PR is closed, and it is in the CHANGELOG.

They also hit a collision that was our process failure: #106 had been claimed an hour earlier and we had not labelled it, so there was no way to see that from the issue list. Claimed issues now carry a claimed label, which exists because of that PR.

If you are picking something up

Comment on the issue first and it gets labelled claimed immediately — that is the only way to avoid what happened above. GitHub will not let us assign an issue to someone who is not a repository collaborator, which is why the label does the job instead. "I'd like to take this" is enough.

Two of today's contributors had no prior commit here, and both shipped within hours of picking an issue. The good first issue pool has been re-verified against main — every one of them names the file, the reproduce command, and the command that proves you fixed it. Contributing needs only Python 3.12+: no cluster, no Docker, no API key.

If KubeIntellect is useful to you, a star genuinely helps other engineers find it — and sharing it with someone who runs Kubernetes helps considerably more than a star does. Both are optional, and neither has any bearing on how contributions are treated here.