Linearの良さ

linearはタスクに関わる作業に迷いが生じにくいのが良い

操作の快適さ

粒度の基準

ここに色々書いてある

自分がそういうのに意見がないなら、従っとくといい

例えば

「プロジェクト」

Aim for clarity

Don’t invent terms if possible, as these can confuse and have different meanings in different teams. Projects should be called projects.

用語の概念をちゃんと考えるのは大事だが、こと「プロジェクト」に関しては難しい

ロードマップ、プロジェクト、issue

ロードマップを作り、

それにプロジェクトが所属していて（複数のロードマップに所属してもOK

プロジェクトの粒度

At the early stages, it's especially important to scope projects. Design projects so that they can be completed in 1–3 weeks with a team of 1–3 people. Smaller fixes or additions should take only hours or a day.

プロジェクトにissue(タスク)がある

issueはsub issueを持っても良い

issueは可能な限り小さくする

issueとtaskは違う？

あんまり、そういう単語の定義を追いかけるのも不毛かも

たぶんgithub issueのissueと合わせてるだけという面も

issueを書いた段階ではまだtaskじゃなくて、書く中でissueを小さくしていき、taskとみなせるくらい分割していけ、という考えか？