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.
-Note on stability
-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. +Keep in mind that users may start to rely on your track hub for their work. If the track hub web +server is down or the URL changes, users of the track hub will have no access to the data. Users may +also have stable session links in manuscripts that include the track hub data and the sessions +could all stop working. We check public track hubs periodically and send an email after a 24-hour +downtime. We will remove track hubs if they are offline for several days. Contact us +(genome-www@soe.ucsc.edu) if there is a change such as moving webservers of the track hub.
-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. +Sudden changes can also impact users where large changes to the track hub can change the analysis +of users such as removing tracks or changing options. In these cases, keeping a previous version of +the tracks and making them in a different track group with suffixes such as "V1", +"(previous versions)" or hint in the track long labels will help users. You can also add a +"dataVersion" trackDb statement to indicate to users what version of the data is being used.
Related tracks can be grouped in a few different ways, namely superTracks, multiWigs, and composites. 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.
Related tracks of the same data type (e.g. a set of related bigBed tracks) should be combined into composites where