SciOp

EUROPEAN SOUTHERN OBSERVATORY

La Silla Observatory

SCIENCE OPERATION DEPARTMENT

SciOp

Re-Engineering Project:

SciOp Communications

LSO-PLA-ESO-90000-4/1.1



Prepared Olivier Hainaut 2002-05-19
Reviewed Jorge Ibsen
 2002-06-09
Released Jorge Melnick
 2002-06-30

Revision History

0.1 2002-05-19 first draft, ohainaut and jibsen
0.2
 2002-06-09 include review comment
1.0
2002-06-30 release
1.1
2002-07-11 updated lasilla@eso.org procedure

Content

1- INTRODUCTION

1.1- PURPOSE AND SCOPE

This document describes the generic structure of documentation and information flow within SciOps, focusing on Information Technology related aspects.

Version 0.1 of this document was circulated for comments. Comments from J.Melnick, G.Andreoni, G.LoCurto, M.Sterzik, E.Pompei were received. They are included and discussed in version 0.2 of this document (review version).

1.2- REFERENCED DOCUMENTS

[1] LSO-PLA-ESO-90000-6: SciOp Staffing Plan, O.Hainaut.
[2] http://www.eso.org/webproject/policy/web-policy.html: The ESO Web Policy, Neumann et al
[3] http://www.eso.org/webproject/policy/eso-guide.html: The ESO Web Standards, Neumann et al
[4] LSO-POL-MAN-000-001: Policy for ToO Observations.

1.3- ACRONYMS

DDT: Director Disctretionary Time
CCS: Cascade Style Sheets
CMM: Configuration Module Mechanism
LED: La Silla Engineering Department
SWC: La Silla Software and Communication Team

1.4- SUMMARY

Below is a list of the various machines and what is done on them.
COMMENT: MSt: you will need a PC for dreamweaver edition
Reply: see below

2- PAPER DOCUMENTATION

A La Silla-wide working group is working on the documentation procedures in order to make them compatible with ISO-9001. This section is a proposal for that working group.

2.1- INTRODUCTION

Paper documentation refers to documents that are originally designed to be printed after going through the standard "Prepared/Reviewed/Released" stages. This can be extended to other kind of documentation, like a web-based user's manual.

The Documents are refered to in a Remedy Database that is described elsewhere. In summary, that database lists all the documents, with an abstract,  an author, and a web pointer. It is also used to generate document numbers. It can be searched to list all documents related to a given query, either directly on a Remedy client or through a web client.

The main documentation repository is kayu, which runs a local CMM server. The documentation repository is structured as CMM modules. Each document is a module, which is dealt with using the standard CMM commands. In summary, this includes (for illustration purpose, a manual will be produced):
Each module must contain:
latex report_emmi.tex
latex report_emmi.ps
dvips report_emmi.dvi -o document.ps
It must be noted that in this scheme, version numbers are handled directly by CMM. As the conversion from the currently existing documentation repositories to the CMM repository is a major task, manpower will be hired. This is considered in the Staffing Plan [1]

2.2- DOCUMENTATION EDITION

Procedure to create a document

  1. Author requests the creation of a module from the Documentation Officer. The author should provide enough information for the creation of the module in Remedy, such as a doc. title, the type of document (Manual, Plan, Procedure...), the group authoring the document (SciOp, other), etc. 
  2. Using the info received from the Author, the Documentation officer assigns a document number and module to the author. This implies
    1. create the document in the Remedy database, which assigns the Nr.
    2. create the module in the cmm system on kayu ((in the future, both operations will be merged)
  3. Author retreive the "empty" module in his personal account with cmmModify, and edit the the document. This should be done on kila.
  4. Author sends the modified, final printable "document.ps" for review and approval, do the modification required and iterate till a final version is obtained.
  5. Author checks the module with cmmCheckForArchive, and archive it with cmmArchive.
  6. Author notifies the Documentation Officer that the document is archived.

Procedure to create a new version of a document

Repeat steps 3-6 of the creation procedure.

Procedure to search and retrieve a document

Using a Remedy client (can be ARuser or Web browser), query the database to identify the document.
In the Remedy page, click on "link to document". This performs on the fly (through a CGI script) a cmmCopy of the corresponding document and puts it on-line (To Be Implemented).

3- WWW

A space on the web server (meli) has been reserved, as user sciops,  located at http://www.eso.org/lasilla/sciops. The current information available in the various Telescope Team pages is huge, and it would be an enormous task to move all these sites under the sciops pages. Moreover, all external links to these pages would be broken. Therefore,
The structure, content and look-and-feel of the SciOp pages will be defined (in accordance to the ESO web policy [2] and standards [3]) and applied to all the sciop tree (note that, currently, the SciOp pages only marginally adhere to these standards). As consequences:

4- EMAIL

4.1- EMAIL LISTS & ALIASES

The following email lists are available as majordomo mailing lists (TOBE IMPLEMENTED)
The leader of each group is in charge of the maintenance of these majordomo lists (i.e. adding new users, removing obsolete ones). Email to these lists will be distributed to 

4.2- EMAIL ACCOUNTS

The only allowed email browser is Netscape, as implemented on kila.
This must trigger a reply with CC to lasilla@eso.org by someone in the Department. When a reply is received, both the original and the reply are deleted (ie that email is processed).

So, at any given time, the lasilla email should countain only
In the future, lasilla@eso.org could possibly evolve into a more automatic helpdesk (remedy?).

A more detailed procedure is now (2002-07-11) available on the SciOp intranet.

Special case: DDT proposals. Currently, all DDT proposal (Urgent ToOs and not urgent DDT, for La Silla and Paranal) arrive at on lasilla@eso.org. At the time of SciOp implementation, these will be filtered and stored in a DDT subfolder for reference. Changes are being requested on the DDT procedure, so that the emails sent include the urgent/not urgent nature of the proposal, and the telescope(s) requested, so that proper filtering can be implemented.

4.3- EMAIL POLICY

5- TOO/DDT AND OTHER PENDING OBSERVATIONS

5.1- Definitions

The current follow-up of ToO, DDT, MOS requests, ToO compensations, etc... is a time-consuming mess. A Remedy scheme will be created (TO BE IMPLEMENTED) (on the generic model of the telescope problem report), with the corresponding Web Form, with the following fields:

5.2- Work Flow

6- ALL PURPOSE ACCOUNT

An account will be created on kila (to minimize the number of accounts, this should be lasilla, which would simplify the handling of finding charts and similar). Its structure will be the following (can evolve with time). It will merge the current nttt, 360cat and 2p2team account and serve as repository for dynamic info (i.e. not documents). This structure has to be kept clean.

     

7- OFF-LINE P2PP PREPARATION AND VISITOR ACCOUNTS

Each visitor is assigned a lsusr* account on the Linux Off-Line System. These are re-generated for each new visitor according to a template, maintained by SWC, that currently includes These accounts are accessible directly from any of the Linux pc of the Off-Line system, and from X-Terms.
By default, the visitor's X-Term in the control rooms should be logged on these accounts.

Each Telescope is assigned an account on the Linux Off-Line System. This is used for data processing, off-line P2PP, etc... by the SciOp staff. These accounts can also hold limited amount of data on a long term bases (like a flat-field library).

--oOo--