Skip to content

Improve the English README for clarity - #163

Closed
Floating-Y wants to merge 3 commits into
deeplethe:devfrom
Floating-Y:docs/update-readme-en
Closed

Floating-Y wants to merge 3 commits into
deeplethe:devfrom
Floating-Y:docs/update-readme-en

Conversation

@Floating-Y

Copy link
Copy Markdown
Contributor

Summary

This PR revises the English README to make Utopia's positioning, philosophy, and current capabilities clearer to new readers.

Changes

  • clarify Utopia's positioning and its approach to knowledge engineering
  • expand the Philosophy section to better explain the bitemporal knowledge graph
  • improve the feature table, setup instructions, roadmap, and project status
  • refine terminology, grammar, and formatting throughout the document

Validation

  • git diff --check passes
  • documentation-only changes; no runtime tests were required

@Floating-Y
Floating-Y force-pushed the docs/update-readme-en branch from 894cdef to 1d002ce Compare September 1, 2026 15:38
Signed-off-by: Liangziyi <Danmushu@outlook.com>
@Floating-Y
Floating-Y force-pushed the docs/update-readme-en branch from 1d002ce to 52e467a Compare September 2, 2026 07:34
@WaylandYang

Copy link
Copy Markdown
Contributor

Thanks for taking the time on this — the rows are tighter and several of the labels are better than what is there now (Document ingestion, Human review and audit trail, Model integration all name the thing more directly).

I'd like to keep the prose form, though, and I want to explain why rather than just asking for a revert.

The two READMEs do not have to match line for line. Comparing this against README.zh-CN.md makes it clear the diff followed the Chinese table row by row, · separators and all — including its claim that Jira is still in progress, which is out of date there too. That one is on us, and the Chinese file is going to be rewritten in the same prose form in a separate change. But the English file is not a translation target: it is written for readers deciding whether this differs from the other options in the space, and it carries more argument per row. Please treat it as its own document.

The sentences are doing work that · separators cannot. "Hybrid retrieval over Tantivy full-text and pgvector, fused with RRF" says what is fused into what; "Tantivy · pgvector embeddings · RRF fusion" lists three nouns and leaves the reader to guess the relation. The same happens wherever the current text carries a claim rather than a feature name — that a base ships with no vocabulary of its own and cold-starts from packs, that correcting a fact closes the old version instead of overwriting it, that the whole system can run on an isolated network. Those are the parts a reader weighs, and they do not survive compression into phrases.

A few specifics from the diff:

  • Jira is not in progress, it works today (jira_issues.rs), alongside GitHub. Feishu is not built — there is connector groundwork, but nothing a user can turn on, so it should not appear in a feature table.
  • The ingest format list and the note about legacy text encodings were dropped. Encoding detection is unglamorous, and it is exactly what people hit first with older corpora.
  • "Failed parses reprocess in place" and bulk re-extraction went too. Both are things people ask about before committing a corpus.

Where the current English text genuinely needs fixing, please do:

  • "A system console, a graph browser and an ontology workbench that runs in the browser" — the relative clause attaches to the last item and reads as if only the workbench is in the browser. All three are.
  • "Rules are expressed in temporal Datalog" is our own overstatement. Rules compile from ontology axioms, and there is deliberately no user-facing rule language (ADR 0002). Something like "Ontology axioms compile into rules, evaluated by forward chaining" would be accurate.
  • If any row reads as a run-on or buries its point, splitting or reordering it is welcome.

Same table, same level of detail, with the wording improved and the two errors above fixed. Happy to take that in this PR.

WaylandYang added a commit that referenced this pull request Sep 2, 2026
* docs: add repository star history

Signed-off-by: Liangziyi <Danmushu@outlook.com>
(cherry picked from commit 0185b1e)

* Daily, and pinned to a commit rather than a movable tag

---------

Signed-off-by: Liangziyi <Danmushu@outlook.com>
Co-authored-by: Liangziyi <Danmushu@outlook.com>
@WaylandYang

Copy link
Copy Markdown
Contributor

Thanks for this — the star history is in dev as of #178, with your commit and authorship kept intact.

Two adjustments were made on top, in a separate commit so they stay distinguishable from your work:

  • The schedule runs daily rather than weekly. A star curve that only moves once a week is flat six days out of seven, and the shape is the point of the chart.
  • lowlighter/metrics is pinned to commit 65836723 rather than the v3.34 tag. This is the first workflow in the repository with contents: write, and a tag can be repointed by the action's owner, so a movable reference plus write access means trusting code that can be swapped out later. Running daily rather than weekly multiplies that exposure, which is the same reason.

METRICS_TOKEN still has to be added in repository settings before the first run can succeed, so the README image will be broken until then — the SVG is committed by the workflow itself. workflow_dispatch is there to trigger that first run by hand.

That leaves the Features table commit, which is a separate question and not one this merge decided. The rewrite is tighter and scans better than what is there now, but it also drops detail that some rows were carrying deliberately — the BIRD Mini-Dev result, the bitemporal explanation, the "no vocabulary of its own" cold-start framing. Would you be up for a version that keeps the compact two-column shape but holds on to those specifics? Happy to go through it row by row if that is easier.

@WaylandYang

Copy link
Copy Markdown
Contributor

Closing this, with the star history already merged.

To recap where the two commits ended up: docs: add repository star history is on dev via #178 with your authorship intact, and it has grown since — the chart is now generated by a script in this repository rather than a third-party action, because GitHub restricted the stargazer timeline on 2026-06-30 and the action bundled a per-day chart that could not be turned off separately. Your commit is what started that, and it is in the release.

The Features table is the one going no further, for the reason given above: the prose rows carry specifics the table cannot hold, and the two READMEs do not have to match line for line. That is a judgement about this particular section rather than about the work — several of your labels read better than what is there, and if you want to open a PR that keeps the prose form and takes those names, it would be welcome.

Thanks for both. The first one is live in the README.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants