Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Design] Redesign decisions and resolved comments

Open
#163 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
bun, typescript
Domain
design, frontend

Research direction

Start with /design-audit#surfaces and inspect the decisions rail, questionnaire cards, comment thread cards, SidecarCard, and provenance in packages/editor. Review the listed verification commands and inventory every required layout and relationship state; done means annotated before/after evidence, shared anatomy decisions, browser evidence, deferred states, and Maggie's approval without changing record authority or workflows.

Written by the indexing model from the issue text.

Description

Base branch: main
Branch: maggie/redesign-decisions-and-comments
Depends on: None

Goal

Give decisions and resolved comments a coherent, high-quality sidecar design while preserving the distinct durable record states.

Context From Planning

  • The current decisions and resolved-comment specimens in /design-audit#surfaces both need a proper design pass.
  • They share sidecar-card foundations and provenance, but questions, accepted comments, resolved history, deliberately empty links, and orphaned links must remain semantically distinct.
  • This is a human-reviewed design task rather than a mechanical restyle.

Current Behavior

Questionnaires and comment threads share SidecarCard, but information hierarchy, provenance, actions, settled treatment, history disclosure, and empty/orphaned records remain visually weak. Existing behavior carefully distinguishes pending, linked, deliberately empty, and orphaned relationships.

Desired Behavior

Design a small sidecar record system that makes open work, settled decisions, provenance, related prose, and exceptional relationship states immediately legible without fragmenting the product into unrelated card styles.

Acceptance Criteria

  • The design audit covers outstanding questionnaire, answered questionnaire, open comment, accepted comment, resolved history, deliberately empty relation, orphaned relation, focused/related-prose, disabled, and narrow layouts.
  • Questions and comments share card anatomy/tokens where their semantics match and remain distinct where actions differ.
  • Provenance, primary content, contextual quote, related-prose state, and actions have a clear reading order.
  • Pending, linked, deliberately empty, and orphaned states remain visibly and programmatically distinct.
  • Existing accept/dismiss confirmation, frozen accepted threads, resolved-history disclosure, focus handoff, related-prose highlight/pin, and record authority remain unchanged.
  • Maggie approves the audit specimens before production migration.

Verification Commands

  • bun run types
  • bun run ci
  • bun test packages/editor
  • bun run e2e

Primary Surfaces

  • /design-audit#surfaces
  • Decisions rail and questionnaire cards in packages/editor
  • Comment thread cards, SidecarCard, and provenance

Expected PR Checks

  • Repo required checks

Report Requirements

  • State inventory and annotated before/after screenshots
  • Shared anatomy/token decisions
  • Browser evidence for focus, disclosure, and related-prose behavior
  • Any deliberately deferred states

Implementation Notes

  • Records own decisions; rendered document projections are not authority.
  • Preserve the four relationship states: pending, linked, deliberately empty, and orphaned.
  • Empty means intentional absence; orphaned means the former target cannot be recovered safely.
  • Keep one shared foundation without forcing question-owned controls into comment-owned action slots.

Stop Conditions

  • A visual treatment obscures the difference between empty and orphaned relationships.
  • The design requires changing record authority, anchoring, or questionnaire/comment workflows.
Dominant language
TypeScript
Stars
351
Forks
20
Avg merge
14h 7m
Merged PRs (30d)
34

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from githubnext/chopin

All issues in githubnext/chopin

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.