As some of you noticed, we have done a major sorting out of the issues in Knex. We introduced the NG_ labels (New Generation) and tidied the board around a small set of main labels: bugs, feature_requests, documentation, and meta (other NG_ labels exist but are less central). Roughly half of the previously open issues were closed as done, duplicate, or no longer relevant. The goal was to make the backlog readable and actionable again. We also used tooling (including AI) to scan the repository for duplicates and related context; maintainers review and edit any AI‑drafted notes before posting. For each triaged issue, since the AI had a lot of connections about it, I got it to write a writeup used as a response; this is not "the" response, but rather a starting point.

There are still 500+ issues open and around 150 PRs that need attention.

Here is the order I think we should prioritise work:

• First we will deal with critical bugs
• Then existing PRs
• Then normal bugs
• Then important features
• Then other features

Stage 1: critical bugs
What “critical” means right now:

• Data loss, corruption, or broken migrations
• Security issues
• Regressions in the current minor
• Crashes or hard failures without a sensible workaround
• Cross‑dialect breakages on common paths
  We will also check for existing PRs that might already address those bugs and link them where missing.

Stage 2: existing PRs
Code ages. As the core evolves, older PRs can become stale or conflicted. Rather than let valuable work wither, where the original author is unavailable we will finish those PRs ourselves (rebase, resolve conflicts, add tests and docs) and preserve attribution. Where a PR has been superseded or is not salvageable, we will close it with a clear note and, where possible, point to a replacement.

Stage 3: normal bugs
Once critical items and active PRs are handled, we will work through the remaining bugs, focusing on issues with a clear repro or failing test first.

Stage 4 and 5: important features, then other features
This is where we add new capability. Some features will target Knex v4. The current idea is to create a v4 branch for breaking changes, keep v3 on maintenance, and prefer feature flags or opt‑in behaviour where feasible to reduce breakage.

Some features will be marked as “accepting PRs”. These are considered minor and will only happen if someone submits a PR. We will keep them clearly labelled and include notes to help implement them in line with project expectations.

So, for stage 1, the first step is to identify, and label, the bugs that are actually critical. This will be the next task.

With the backlog in a cleaner state and priorities clear, it is time to get our hands dirty and get things fixed. Thank you to everyone who has tested, reported, and sent PRs so far. Let us keep the momentum going.