> I think a better long-term story is to have a documentation repository > where we can place -- and update -- system design information for > future people who have to maintain this stuff. Scattering it on > obliquely named project pages (how far can I see on a "Clearview"? and > are avian carriers involved in "Volo"?) doesn't help organize or > explain anything.
I think the naming issue is a separate matter. Further, I think even with the oblique names today, there is sufficient tie-in to allow developers to find what they need -- e.g., both Clearview and Volo purposely used their project names in the changeset log comments so that future developers can connect the dots and pull up the relevant background behind a particular code change. That is quite valuable. > Projects make sense to me while they're going enterprises and still > doing useful work. I'm much less convinced that they're of lasting > value historically. I disagree -- I have often found decade-old documentation (when I can find it) useful for understanding the rationale behind non-obvious changes. > But even where they do have useful information, we still need to avoid > having it just pile up in the middle of the road where it's at least > slowing traffic, if not yet causing accidents. How is the project page "slowing traffic"? Are these really the long pole in the website migration project? I'm all for disposing of pages for abandoned projects, and for updating the pages for delivered projects to make it clear it is only of historical note. However, purging them and moving their content to somewhere else seems of limited utility, and makes it harder for people to find relevant content. -- meem _______________________________________________ networking-discuss mailing list [email protected]
