minor doc and notebook updates

Author: pothiers

docs/nightly-digest-fresh-start.org

@@ -1,11 +1,14 @@
-Time-stamp: <2025-01-24 16:29:44 pothiers>
+Time-stamp: <2025-01-28 10:33:09 pothiers>
+# name?  TSSW Nightly Digest
+# ~/sandbox/notes/noirlab/rubin/nightly-digest-beta2.org
+
 * Abstract
 In Aug 2024 we began working on what is now called the Nightly Digest.
 It was to develop a /project-wide logging initiative/.  Virtually
 nothing else about it was known. Developers were brand new to Rubin.
 As should be expected: no requirements existed, no framework for the
 work existed, and development was chaotic.  Thankfully, there were
-three log sources with API access already in place.  Three months
+`three log sources with API access already in place.  Three months
 later, we had an MVP (Minimum Viable Product) "release" delivered as
 a notebook under Times Square.
 
@@ -185,7 +188,7 @@ created our own.
 
 
 * Approach (How get get where we want to go)
-See also: [[https://github.com/lsst-ts/ts_logging_and_reporting/blob/prototype/docs/unified-time-log.org][SUTL]]; *Single Unified Time Log* /(SUTL="subtle")/
+See also: [[https://github.com/lsst-ts/ts_logging_and_reporting/blob/prototype/docs/unified-time-log.org][SUTiL]]; *Single Unified Time Log* /(SUTiL="subtle")/
 
 ** Prove approach outside of Notebooks
 To prove that we can provide an application that does not use
@@ -201,7 +204,7 @@ instance, we might not move our back-end into the TSSW stack (to avoid
 the changes to fit dev style and approvals that will require). Perhaps
 pass token to app via env variable when app launched.
 
-*** Create MVP Django App
+*** Create Django App
   + Should the Django app be in the same repo as back-end? Probably.
   + Move data from all_sources into a database. Extend this to hold
     most recent N days. Atomically remove data older than N days.
@@ -233,6 +236,8 @@ pass token to app via env variable when app launched.
 - Define new dev (maintenance) work-flow
 
 
+** Tasks                                                           :noexport:
+
 * Challenges
 ** Users
 We have not agreed upon who the users are for this application.  The

docs/unified-time-log.org

@@ -1,4 +1,4 @@
-Time-stamp: <2025-01-24 12:36:59 pothiers>
+Time-stamp: <2025-01-27 13:54:17 pothiers>
 * COMMENT PRESCRIPT
 \setlength{\parindent}{0em}
 \parskip 7.2pt
@@ -19,7 +19,7 @@ This white-paper describes a partially implemented vision/design
 created [2024-11-28 Thu]--[2024-12-02 Mon]. I wrote it after I found
 myself excitedly yammering incoherently to a few people about the
 concepts. These ideas can be grouped under what I have come to call a
-*Single Unified Time Log* /(SUTL="subtle")/. SUTL is currently being
+*Single Unified Time Log* /(SUTiL="subtle")/. SUTiL is currently being
 used (in DRAFT form) in the /Night Summary/ being created for /TSSW Logging and
 Reporting//
 
@@ -47,7 +47,6 @@ tests).
 \tableofcontents
 #+End_Latex``
 
-
 * Challenges
 1. Every data *source is accessed in its own way*.
 2. Some fields are tiny, some over 5,000 characters
@@ -190,7 +189,6 @@ rendering is created for each user type.
 
 6. /"Throw it against the all and see what sticks."/
 
-
 * Future
 ** Beyond a Night Summary
 The same technique used to summarize a night into periods could be used
@@ -252,7 +250,7 @@ and selected "insert template" (C-c C-e #).
 
 
 #+TITLE:   Night Summary
-#+SUBTITLE:   using a Single Unified Time Log (SUTL)
+#+SUBTITLE:   using a Single Unified Time Log (SUTiL)
 #+AUTHOR:    Steve Pothier
 #+EMAIL:     steve.pothier@noirlab.edu
 #+DESCRIPTION: Personal design notes