1cb7fc28305bae2eddf80c3f9b6cdb8b10ee3255
max
  Thu May 30 01:05:27 2024 -0700
adding notes about track hub stability, refs #33768;

diff --git src/hg/htdocs/goldenPath/help/publicHubGuidelines.html src/hg/htdocs/goldenPath/help/publicHubGuidelines.html
index 8c36738..cdc6f11 100755
--- src/hg/htdocs/goldenPath/help/publicHubGuidelines.html
+++ src/hg/htdocs/goldenPath/help/publicHubGuidelines.html
@@ -71,30 +71,58 @@
  <li>The following settings should properly be set in your genomes.txt (The last 3 settings will make
      it easier to find assembly hub species in hgGateway by UI search):
  </li>
  <ul>
   <li>defaultPos</li>
   <li>scientificName</li>
   <li>organism</li>
   <li>description</li>
  </ul>
 </ul>
 
 <a id="recommendedGuidelines"></a>
 <h2>Recommended Guidelines</h2>
 <p>These guidelines in the following sections are recommended to improve user experience, but are
    not required to be implemented before the hub is added to our list of Public Hubs.</p>
+
+<h3>Notes on stability</h3>
+<p>
+Keep in mind that users may start rely on your track hub for their work. Obviously, if the
+track hub web server is down or its URL changes, your users have no access to
+the data anymore.  Users may also have stable session links in manuscripts and
+these will all stop working.  We check public track hubs every hour
+automatically and send email notifications after 24h of downtime and will
+remove them if they are offline for several days. But if you tell us about a
+change anytime, ideally before you move the webserver of your track hub, we can
+change the URL in our internal tables which will fix all existing sessions and
+avoids downtime for users. If the track hub is successful or you run into
+performance or storage funding problems after some time, for example if the
+research group is moving institutions, we can also host files at UCSC, just contact us.
+</p>
+
+<p>
+Even if the webserver is stable, on a more subtle level, sudden changes to your hub
+can be a problem for your users. While you can make large changes to the tracks
+anytime, users will find that their analysis does not work anymore from one day
+to the next and if you take away tracks or change options, this can be hard to understand.
+In these cases, you can keep the previous version of the tracks in a different track group,
+e.g. with a suffix such as "V1" or "(previous versions)" track group or give a
+hint in the track long labels where new options are found. There also is the
+"dataVersion" trackDb statement to indicate to users what the version of the
+data used was, in addition to track groups or longLabel statements.
+</p>
+
 <h3>Track organization recommendations</h3>
 <p>
 Related tracks can be grouped in a few different ways, namely <a href="trackDb/trackDbHub.html#superTrack"
 target="_blank">superTracks</a>, <a href="trackDb/trackDbHub.html#aggregate"
 target="_blank">multiWigs</a>, and <a href="trackDb/trackDbHub.html#compositeTrack"
 target="_blank">composites</a>. If your hub includes a large number of tracks, the grouping of
 tracks may be necessary. This will prevent your hub's track group from being an overwhelming mess
 of individual tracks and can make user configuration of your tracks easier.</p>
 
 <h6>Composite tracks</h6>
 <p>
 Related tracks of the same data type (e.g. a set of related bigBed tracks) should be combined into
 <a href="trackDb/trackDbHub.html#compositeTrack" target="_blank">composites</a> where
 appropriate.</p>
 <ul>