Skip to content

004: Project Name

  • Type: Product
  • Status: Planned
  • Date: YYYY-MM-DD
  • Author(s) / Deciders: Project authors and maintainers
  • Question: What name and identifier will represent the project across repositories, package registries, and documentation?

Context

A project name shapes discoverability, CLI/package ergonomics, and brand identity. Choosing a clear, conflict-free name early avoids breaking changes to package identifiers, repository URLs, and namespace imports later.

Funcional names are often more discoverable and easier to remember than abstract or metaphorical names, hee are a list of them:

  • NASA: National Aeronautics and Space Administration
  • Vocaloid: Voice + Android

Requirements and Restrictions

  • Pronounceability and Brevity: Easy to type, pronounce, and remember.
  • Namespace Availability: Available on target package registries (such as crates.io, PyPI, npm), GitHub/GitLab, and domain registrars if applicable.
  • Trademark and Search Collision: Does not collide with active software projects or registered trademarks in the same domain.

Alternatives

  • Candidate A: Summarize meaning, availability, and why it was or was not selected.
  • Candidate B: Summarize meaning, availability, and why it was or was not selected.
  • Descriptive Functional Name: Directly states what the tool does, trading uniqueness for immediate clarity.

Decision

State the chosen display name, repository slug, and package/CLI binary identifier.

Consequences

Positives

  • Consistent naming across the codebase, documentation (zensical.toml), and distribution channels.

Negatives

  • Document any spelling ambiguities or similarity to unrelated terms outside the domain.