Re: lurkers

[hjohnson@pluto.njcc.com (Herbert R Johnson)]

I'm not fond of the "dummies" concept. As Tom says, TASS is not for
dummies. So I've changed the subject heading. Here are my thoughts on
this issue. I'd appreciate comments. - Herb

On Tue, 14 Apr 1998 15:18:11 -0400, "Shawn Dvorak" <sdvorak@bright.net> wrote:
*> HOWEVER, I have been reading all of the postings and although I follow
*>most of the threads I still haven't deciphered the wheres and hows of all
*>the data and programs available.  An explanation of where data is located
*>and what it is (full URL's, please!) and the location/operation of software
*>to process the data.  I'd love to churn through some of the data and to
*>test out some of the s/w but just don't have weeks/months to hunt for
*>software/data and decipher its use as well as setting up a Linux machine
*>and installing Postgres and Perl; maybe it's just selfish of me.  Maybe I
*>should volunteer to spend the time to figure it out and write the guide
*>like Chris suggests.  On the other hand it would be helpful to at least
*>have a few more tech notes written by the experts that give some directions
*>to those of us who weren't here as some of the programs and procedures were
*>created.
*>
*>Shawn Dvorak

What to look for in TASS

Many of these things are moving targets. Even so, the TASS Web page is the
place to start. The Tech Notes represent those bit of activity where active
TASS members think/thought we need some kind of review or reference or bits of
information. A few of the Tech notes are in fact reviews, such as my
Tech Note #36 on the installation of Real-Time Linux (to operate the Mark III
camera software under Linux). I've documented the driver's features, development,
and installation by compiling and editing the email on the subject.
I was overwhemed by the reception it recieved. Beyond Tech Notes, there
are reports and references that should be looked over.

Lurkers should know that there is not one "pipeline" for all camera data.
There are two camera control programs in use (for MS-DOS and Linux). There
are two or three data reduction programs in use to create the "star lists",
each with slightly different criteria for determining the characteristics
of point sources and aligning the observations with known star catalogs.
And the database recieving those starlists is *very much* in evolution.
Data reduction from star lists to light curves is, I believe, done by
the individuals on-site: I don't think we have many off-site people
doing data reduction (correct me if I'm wrong). One smart bet is to stick
with one camera site and follow the data and software trail from that site.

And there are a number of side issues in hot persuit. Flat field boxes,
optics for the new camera, finding moving objects fast and slow, etc.
And the design of new tools and instruments. And there are technical
discussions: on photometry, astronmetry, cataloging, electronics,
database design. Any of these threads in the TASS maillist are worthy
of study and review: many of them are backed up by reports on the
Web page (some are not or the reports are dated). There is a search engine
for the archived email: check that out. Most email messages are one subject
per message. Most message headings give a clue about content.

The new mark IV camera
is mostly Tom's affair; but the optics have been discussed and worked on
by others. I myself did a bit on the Orion telescope as a prototype optic -
that was a good example of how someone can jump in and contribute in a
well-defined way with a clear, er, objective and a conclusion (it's good
enough). I got the telescope, took a picture, and analyzed the photo
in the context of how the Mark IV CCD would "see" the image.
I've left a trail of what I did and how I did it, and I used
my own Web page to provide a dynamic report of results. Now, that info is
part of the TASS Web page, and when it is concluded maybe I'll make a
Tech Note (maybe not, it's kinda a side issue). Other issues have
come up, been disussed, and made into reports or even Tech Notes.
And they've been discussed again: even we don't read our own notes!

Strategies to get involved, to do work

I'd say that a good operational strategy for someone not in the main line
of TASS development is to grab a piece that they can do something with
and DO IT. Then, they've got some *focus* to their search through the
TASS Web page - and the email database - for a particular bit of effort
or research or review. And, they have something in particular to ask about.
I suggest "leading with your strong suit" - work on what you know. But some
folks like jumping on the learning curve on something that is new to them.

A little known secret of science is: pay attention to the details! So
good scientists and techs and engineers worry a lot about the details.
If you ask one of these folks some vague questions, it's frankly confusing:
where do you start? what is important? What are you looking for? Another
secret of science is: pay attention to the big picture! You can design
a good widget and then look at the wrong thing with it. So you also need
a plan, a goal, a vision of what you want. For most of us, that vision
has to be constrained so you can get something done in your lifetime,
or the length of your grant or your patience. And, the RIGHT question
will get you the sharpest vision or plan, and generate the most exciting
result. It's an art to decide what is too grand, what is too small.

All the above is a way of saying: science is tough and demanding, and so
you've got to be both focused AND aware of the context of you are doing. Same
thing for asking about science in progress, and for what kind of answers
you should expect to get from active scientists and others.

Leaving a trail

However, the point made by Shawn is I think well taken: we in TASS have to
leave some kind of "trail" so others can follow what we've done.
Reasonable notes in progress do a fair job, but at some point they
have to be consolidated so one person can read them COLD and get something
out of them. I did this with my Orion stuff, and updated my notes as
I got comments. Tom does this with his Mark IV design reports, and I
complimented that by consolidating his reports into a kind of
"running specification".

Let me say to my colleagues: at some point,
this stuff will sit on a shelf for a decade or two, and then someone
will want to "work the data" to find some event or feature you've not
planned for. They will need to "pick up the trail" of what was done
and how, so they can second-guess how it will have affected the data
THEY want. I've gone through this myself, looking at radio astronomy
data from 10, 20, 30 years ago: it's painful. Worse, the principle researchers
involved have forgotten or mis-remembered what they did and when. Or,
they are indifferent to any new analysis of their old data - it's
history to them, the results succeeded or failed, life moves on.
The modern problem is not a lack of documents, but as Shawn suggests
TOO MANY documents: email, reports, data, programs all equally available.
Email is a tough resource for referencing: I know that from creating reference
documents from email trails. And, as documenting is not "science", it
is not well-recieved work. But consider documents as "lures" for turning
lurkers into workers. And consider my remarks about harvesting old data.

Herb Johnson


  **** ------------------------------------------------------ ****

Herbert R. Johnson                      voice/FAX 609-771-1503 day/nite
hjohnson@pluto.njcc.com                 Ewing, in central New Jersey, USA

                 amateur astronomer and astro-tour guide
            supporter of classic S-100 computers as "Dr. S-100"
        rebuilder of Mac Plus computers for your computing pleasure
     and senior engineer and asteroid spotter at Astro Imaging Systems