거기에 있는 칩들은 릴리스의 하이라이트라고 생각하는 내용을 게시하던 이전 패턴에 비해 큰 그림을 이해하는 데 도움이 되지 않습니다.
새 형식의 내용 없는 릴리스 공지 사항은 더 이상 Discourse의 흥미로운 새로운 기능을 강조하기 위해 링크할 가치가 있는 게시물이 아닙니다. 업데이트의 주요 트리거로 감시 이메일을 사용하는 우리에게 알림 기능은 수행하겠지만, "이 달의 Discourse에서 이거 봐, 멋진 새 기능이 나왔어"라고 소셜 미디어에 게시할 현실적인 옵션은 더 이상 제공하지 않습니다. 릴리스 사이트에는 그런 관점이 없습니다. 그것은 단순히 git log 위에 살짝 뿌린 설탕일 뿐입니다.
시간을 어떻게 사용하는지에 대한 최적화라는 점은 이해합니다. 하지만 릴리스 사이트가 공지 사항의 유용성을 기능적으로 대체하는 것으로 어떻게 인식되었는지는 명확하지 않습니다. 칩으로 포맷된 커밋 메시지 무더기를 읽어서 무엇이 흥미로운지 추측하려 하지 않을 것입니다. 칩은 기본적으로 git log와 같지만 세로 공간이 5배 더 많이 차지하여 읽기 어렵게 만듭니다. 그래서 다가오는 Discourse 릴리스에서 실제로 흥미로운 것이 무엇인지 슬프게도 모르게 될 가능성이 높습니다.
RSS를 볼 수 있으면 좋겠습니다. 각 카테고리마다 RSS 피드가 있으며, 공지(Announcements) 카테고리의 경우 이것입니다. 그리고 릴리스 노트(release-notes) 태그의 경우 이것입니다. (최신 상태일 것으로 예상되는 Discourse RSS 피드 찾기를 참고하세요.)
이 주제와 제공된 링크를 보고(확인할 이유 없이) 2026.3.0이 릴리스되었는지(언급된 33개의 보안 수정 사항 컨텍스트에서) 생각했습니다. 이제 제 실수를 깨달았습니다.
2026.2를 보면 하이라이트를 볼 수 있습니다. 작은 글씨로, 색상이 있는 배경 위에 밝은 텍스트가 사용되었습니다. 이는 라이트 모드 사이트인데, 다크 모드의 특징인 어두운 배경 위의 밝은 텍스트가 많은 사람들이 다크 모드를 좋아하지 않는 주요 원인입니다. 명시적인 라이트/다크 모드 전환 버튼을 보지 못해 브라우저의 라이트 모드 설정을 따르고 있거나 아예 모드가 없는 것으로 추정하지만, 읽기가 정말 어렵습니다.
여기서 자동화가 시간을 절약해 주는 것은 분명하지만, 제 제3자 피드백으로는 이것이 경험의 개선이 아닙니다. 이해하고 있었다면 별도의 주제에서 이 일을 했을 텐데 죄송합니다!
@derek 스타일링 개선 사항을 기대하고 있습니다. 라이트 모드에서는 텍스트가 어둡게, 다크 모드에서는 밝게 보이도록, 배경색의 채도가 접근성 가이드라인을 충족하는 대비 비율을 유지할 수 있는 색상으로 제한되면 좋겠습니다. 또한 텍스트 크기가 Discourse 자체의 것과 동일하게 유지된다면 사용자 편의성 측면에서 이점이 될 것이라고 생각하며, 브랜드 일관성에도 도움이 될 것입니다.
라이트/다크 모드와 무관하게, 해당 박스의 색상은 고정되어 있습니다. 팔레트 선택과 관계없이 동일한 배경색과 텍스트 색상을 사용합니다. 말씀하신 대로 배경색(--color-feature 변수의 #667eea)은 흰색 텍스트를 사용하기에는 너무 밝습니다.
크롬의 대비 검사에 따르면 #667eea 배경 위에 rgb(255, 255, 255 / 95%)를 사용할 경우 대비 비율이 3.46:1로, WCAG AA 최소 기준인 4.5:1에도 미치지 못합니다. (놀랍게도 검은색 텍스트는 4.5:1로 간신히 기준을 충족하지만, 여전히 보기 좋지 않고 가독성이 떨어집니다.)
따라서 이 문제는 비교적 시급하게 해결해야 하며, 솔직히 말하자면 사이트 전체에 대한 종합적인 접근성 검토가 필요합니다. 2026년인 지금, 접근성은 모든 웹사이트의 기본 출시 기능이 되어야 합니다.
(그동안 --color-feature를 #3048b6으로 변경하면 배경색으로 허용 가능한 수준이 됩니다. 흰색 텍스트와의 대비 비율이 7.12:1로, 7:1 이상을 요구하는 WCAG AAA 가이드라인을 충족합니다.)
