きちんとドキュメントできていなかったので、一旦ここで今回の設計意図を説明させてください。

令和最新版を実装するにあたっては、 #rubyfriends ムーブメントを踏まえて rubyists を配列で持たせるようにしました。つまり、複数人の Rubyist が写真に映ることを前提としました。平成 Rubyistokei は「Ruby Hero」を紹介することをコンセプトにしていましたが、令和最新版ではそれを「Ruby Friends」に拡張したらどうか、と考えました。

そうすると、bio は個々の Rubyist に帰属するため、

rubyists:
  - name: "Alice"
    bio: "bio of Alice"
  - name: "Bob"
    bio: "bio of Bob"

となるのが自然です。しかし、これを時計にレンダリングするには、余白が足りません。特に人数が増えると顕著です。使われないデータを入力してもらうのは勿体ないので、一旦 rubyists は文字列の配列としました。

そこで、従来の bio を単に description とし、「写真」の説明を記述する欄と位置づけました。もちろん Rubyist が一人で写っているのであれば、そこに bio が記述されるのは自然で、それがよさそうです。一方、複数人が写っているときは、それがどういう集まりなのか、どうしてこのように写真に収まるに至ったのか、が説明されるとよいなと考えました。

というのが現状の設計意図です。いかがでしょうか...?

丁寧な説明ありがとうございます!

平成 Rubyistokei は「Ruby Hero」を紹介することをコンセプトにしていましたが、令和最新版ではそれを「Ruby Friends」に拡張したらどうか、と考えました。

完全に理解しました! 私は平成 Rubyistokei のメンタルモデルのままだったので、これを機に改めます。
(拡張コンセプト、「民主化」といった趣で良いですね)

そこで、従来の bio を単に description とし、「写真」の説明を記述する欄と位置づけました。もちろん Rubyist が一人で写っているのであれば、そこに bio が記述されるのは自然で、それがよさそうです。一方、複数人が写っているときは、それがどういう集まりなのか、どうしてこのように写真に収まるに至ったのか、が説明されるとよいなと考えました

実務的には集合写真もまとめて扱うならこれが順当だな、と納得しました。

いまはRubyist単騎写真ばかりなので、Working Exampleとして #rubyfriends なdataもあると、混乱は減りそう。
(yamlのファイル名のつけかたとかの参考にもなりそう)

#rubyfriends example!
https://github.com/rubyistokei/rubyistokei.github.io/blob/main/data/harukasan-sugamasao-june29-asonas.yaml