[Yt-dev] Website Changes, dev blog?

[Matthew Turk]

> You may already be thinking this, but I suggest that you have a bit more information for each link. It could be a few more words, or perhaps a representative picture for each. For example, I get that yt and microscope are different in goal, but I think it should be clear that they are even more completely different being written in Python and IDL. And without knowing what a pastebin is, that link is a mystery.

Okay, I've gone ahead and changed the text:

http://enzotools.org/

it's a bit longer, but not *super* long.

> Again, a little pomp would be nice. I'm guessing you're aiming for minimalism, but you want people to think yt is cool!

Fair enough.  :)  I am trying to avoid anything overt, that detracts
from the fundamental message: here are places to go for help or for
information.  Maybe just a playful sentence or something?  What do you
think?  I had a kind of off-putting email exchange last week with
someone who chewed me out about the information overload; I think we
need to simplify things greatly.  Scientists: not terribly interested
in carefully reading things.  To that end, a very abbreviated table of
contents, with a narrative set of column headings, is what I want to
be the front face.  "What Is YT" though maybe should have something
like, "YT Is For You" or "YT Is Awesome"?  I dunno, that comes across
rather egotistical.  But something *like* that.

> I'll add things to it, if I have things to add. In my opinion, a blog for yt (or other enzotools.org stuff) would probably have to lean towards the announcement end of the communication spectrum, rather than a disussion blog. I mean that we already have a mailing list for discussions. That's my two cents.

I think that's *exactly* what I want -- a place to say, this is what I
did, it's in trunk, and here's why I did it.  I'm thinking her of the
numerous times I, or you, or Britton have left demonstrative and
communicative changelog messages that then get read exactly once and
scroll off the timeline.  The documentation is the long-term location
for the instructive components of those, but for design decisions and
so forth, as well as interim announcements/instructions, I think that
a blog-like structure would work well.  I'm still not completely sold,
but data export is not terribly difficult.

-Matt