Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[Design] Redesign decisions and resolved comments

未关闭
#163 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
38/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
bun, typescript
领域
design, frontend

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

triage/human-response

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.
主要语言
TypeScript
星标
406
派生
24
平均合并
12 小时 42 分钟
30 天内合并 PR
416

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

githubnext/chopin 的其他 Issue

查看 githubnext/chopin 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。