Tickets & Releases
Tickets

    Tickets are created for issues with assets that fall outside of the normal pipeline. A Ticket therefore refers to a problem that needs to solved. Here's what the create Ticket dialog looks like:

    Let's go through those fields:

      Title: This is a description of the problem. It should be succinct and descriptive
      Type: Pick the asset type from the drop down menu
      Status: This should be set to "in progress"
      Priority: Optionally you can set the ticket as high priority (drop down menu)
      Due Date: A due date should be set for the ticket so the PA can keep people on plan. Tickets turn red when past due.
      Description: Optionally more detail can be provided here
      Assigned to: Auto-completes to the artist's name the Ticket is assigned to
      Releases: Left blank for now. When completed the ticket will be connected to a Release.
      Related Tickets: If any, begin typing the Ticket number to auto complete
      Shots <-> Tickets: If the Ticket is related to a specific Shot is can be linked here.
      Asset <-> Tickets: Most of the time a Ticket will be related to an asset. Begin typing the name of the asset to auto complete
      Project: This is already filled out by default
Releases

    Once a Ticket has been addressed, a Release is issued for the new version of that asset with the changes. A Release can have multiple Tickets associated with it, similar to how a new software release can address multiple bugs and feature requests. Here's what the create Ticket dialog looks like:

    Let's go through those fields:

      Release Name: This is the name of the asset and it's version. So the naming syntax is [asset]_[version] which is an abbreviated form of our naming convention (see file name below). it is vital that the name here be consistent so we can see that TurntableSetup_v2 comes after TurntableSetup_v1, as opposed to random names like TurntableSetup_v1, TurntableMaster_v2, TurntableRig_v3. Do those go Releases go together? Who knows? That's why a Release needs to have consistent naming. Not hard to do, but crucial.
      Type: Pick the asset type from the drop down menu
      Status: This should be set to "working version" (see below for more on this)
      Description: Optionally you can elaborate here, however the linked Tickets (see Tickets below) usually will make that unnecessary.
      File Name: The exact file name of the asset that the Release is for.
      Path to File: The full path to where the file asset is located
      Tickets: All of the Tickets addressed by this Release of the Asset. Type the Ticket's number and SG will auto-complete.
      Project: This is already filled out by default
    Once a Release has been created you need to do a few more things:

    1. Set the previous Release's status Change the status of the previous Release for that Asset to "completed" Only the current version should have the status of "working version." So if Frog_v3 was the current version, but you are releasing Frog_v4 then Frog_v4 becomes the "working version" and Frog_v3 (along with Frog_v1 & Frog_v2) all become "completed" releases, but they are not the current "working version."

      Artists can then check the Release page to see what the working version is for a particular asset and also see the Tickets that have been resolved in that version. The Release page is filtered so that it only displays the working versions of all Releases. You can change the filter to see older "completed" Releases.

    2. Resolve the Tickets On the Ticket page, change the status of all the Tickets that you are including in this Release from "in progress" to "resolved"
    3. Email the crew about the Release
All content © copyright Light Collab.