# Script v0.0.4

---

### Introduction to Figma Version control and Task Management [1/8]

#### Video 1 - Introduction to Figma Version control and Task Management talk points
- Overview for the following
- GitHub issues
- GitHub comments
- Figma document
- Figma version control canvas
- The bridge between both Figma and and GitHub

#### Video 1 - Introduction to Figma Version control and Task Management script

***Slide - 1 :*** Hello, welcome to the task management and Figma Version Control video. This video series is to show you how we do the Task Management and UI/UX Version Controlling at WizardAmigos.

***Slide - 2 :*** In the following videos we will go over how we do version controlling on Free version of Figma

***Slide - 3 :*** How we manage the dependcies between components

***Slide - 4 :*** How we connect Figma and GitHub together and

***Slide - 5 :*** Version control each output of a task

***Slide - 6 :*** Furthurmore we will also show you our task management process.

***Slide - 7 :*** Covering usage of `@input`, `@output`, from and next

***Slide - 8 :*** lastly how we communicate information with our GitHub comment structure.

***Slide - 9 :*** Just to quickly mention. In our case, we use GitHub and Figma but you can use our Figma version control and GitHub task managment methods with any other application you prefer. These two methods are entirely inpendent of each other and does not need to be used together in your case. I hope you stick through, be seeing ya.

---

#### Video 2 - Version Control on Figma talk points
- Overview of the structure (clicking through component pages etc)
- Link to GitHub Issue
- Link to Component's Video
- Last update date
- Show how each version is structured using 1 component for the example
- Dependencies
- Dependents
- Show how a link that can be generated
- Link of a canvas
- Link of a publish file
- Give example of spliting 1 component into multiples
- Use PopOver Components for this example
- Show depricated process
- Show successor process
- Give example of merging multiple components into one
- (?) Which example should we use here?

#### Video 2 - Version Control on Figma script
***Slide - 1:*** Welcome to the first video, we will start off with how we cover version control in free version of Figma.

***Slide - 2:*** You may know free version of Figma keeps your update history for only 30days. Once that is passed your changes can no longer be tracked. So, with a bit of management, let me show you how we tackle that problem

***Slide - 3:*** On the left here you see the Figma pages.

***Slide - 4:*** Each page here represents a different component.

***Slide - 5:*** When you open a page, you will see artboards/canvases where your design resides, and each canvas contains a header section.

***Slide - 6:*** This section have a component name with the version number

***Slide - 7:*** which must match the canvas name and the output expected to be produced in the github issue.

***Slide - 8:*** Followed by the date when it was updated

***Slide - 9:*** and a link to the GitHub issue where this component is created.

***Slide - 10:*** Below that we have a small description about the component updates. If there is an explanatory video about this component you can link that to a text here

***Slide - 11:*** After that we have the list of dependencies

***Slide - 12:*** and dependents. Each of these links to the their respective canvases. This shows us what version of component this design requires as input and what other components needs this component as an input. Where all the designs are being used and how the whole project components are linked to each other.

***Slide - 13:*** When you make a different version of a component. You duplicate the same canvas,

***Slide - 14:*** change the version name and updated date,

***Slide - 15:*** the components description section

***Slide - 16:*** and change any links to updated dependencies or dependents and their versions.

***Slide - 17:*** Once done you can modify the components design in your new canvas.

***Slide - 18:*** Now, what if you delete something? or split 1 component into multiple other? Or something which is deprecated but now have a successor component in replacement?

***Slide - 19:*** Let's use this component we have here called `PopOverComponent` as an example. For the first canvas we have all the popover designs in 1 component, but in this situation we want to split those popover designs to be their own standalone components.
***Slide - 20:*** We will duplicate the current canvas, we keep everything the same
***Slide - 21:*** but this time we add a `deprecated` tag in the header,
***Slide - 22:*** and at the very bottom we will link all the success of this deprecation. In this case, multiple popover components with their own pages and issues.

***Slide - 23:*** We also have cases where we merge multiple components into one. Let's use this `fileExplorerPopOver` and

***Slide - 24:*** `BookmakrPopover` as an example.

***Slide - 25:*** Same as before, you duplicate and add `deprecated` tags on each header.

***Slide - 25:*** And we link the successor at the bottom, which is this case will be the same component.

***Slide - 26:*** That's all for the 1th video. In the next video we will talk about how we link Figma to GitHub. Thanks for watching

---

#### Video 3 - Connecting Figma With GitHub or any other management platform talk points
- Show how Figma version and GitHub `@input` and `@output` are connected
- Copying the links of pages, canvas and GitHub Issues
- Linking the GitHub and Figma to each other
- Publishing the Figma project

#### Video 3 - Connecting Figma With GitHub or any other management platform script

***Slide - 1:*** In this 2nd video we will be touching the subject of how we connect Figma and GitHub together. Remember you can use this process with any project management or designing tools, not just Github and Figma. So, let's start.

***Slide - 2:*** Each file you see here are linked to Figma canvases. The version number at the end of the file name represents which canvas and version those are from.

***Slide - 3:*** To link the Figma file to GitHub output. Simply goto the component page,

***Slide - 4:***`right click` on the canvas name,

***Slide - 5:*** go to `copy/paste as`,

***Slide - 6:*** then select `copy link`. Then you can use that link for the output file on GitHub or any other place you want.

***Slide - 7:*** Simply select edit on GitHub comment,

***Slide - 8:*** place the name of file in square bracket then following that place the link in simple brackets. Just remember to not leave any space between these brackets. Otherwise the link will not work

***Slide - 9:*** Lastly to publish your whole project. Click on share button on the top right conver of Figma,

***Slide - 10:*** click on publish to community, and then select publish.

***Slide - 11:*** From the community page you can always get the share link under the Share title on the bottom right corner.

---

#### Video 4 - github issues top level comments for tasks talk points
- Issue Title
- `@todo` tags
- Tasks and sub-tasks
- Indentation of input and output
- Default sub-tasks to create when making a task group for new version component
- What to do for task which doesn't produce output?
- Exampl of doing all this in markdown

#### Video 4 - github issues top level comments for tasks script

***Slide - 1:*** In last 2 video we went over how we connect designs to our project management application. From here on we will show you how our version controlling process works on GitHub

***Slide - 2:*** In this video I will go over how the tasks and information are structure in the main top level comment.

***Slide - 3:*** Then we will go over markdown. Which is a form of markup language.

***Slide - 4:*** We start out our comment with a `@todo` tag, where we place all our task.

***Slide - 5:*** Each issue must produce at least 1 `@output`.

***Slide - 6:*** Each task or task groups created within this issue must also have at least 1 `@output`. There may be multiple outputs produced and used wihtin the issue but the last output(s) will be considered as the produced output of that issue.

***Slide - 7:*** The indentation of the task group is important. You must keep the `@input` & `@output` with the same hirerachy as the tasks listed within that group

***Slide - 8:*** Now let's go through how to do these changes.

***Slide - 9:*** When writing a new comment you will see these two options. `Write` and `Preview`. In the write section you will write all your markdown text. Let's start by creating a task

***Slide - 10:*** Simply write a minus with open and closed sqaure brackets, followed by the task name.

***Slide - 11:*** Now clicking on preview you will see a new task is created.

***Slide - 12:*** The empty space between the square brackets means the task is open. Placing an X in between will mark the task as done.

***Slide - 13:*** To create a subtask, simply go to the next line, write the task in the same manner but this time with 3 spaces infront of the minus sign.

***Slide - 14:*** This will indent your tasks as such.

***Slide - 15:*** To link something as `@input`. replace the square brackets with "@input" placed in the backticks
(= \`@input\` ).

***Slide - 16:*** Then following that you write the emoji name within 2 colons, e.g. (`:question:` or `:package:`)

***Slide - 17:*** After that you can link the file but placing the file name withing a sqaure bracket and backticks and placing that file link in normal/circle brackets right after. Remember there must not be any white space between the brackets. otherwise it will not work. Lastly, you can mention the link of the issue this input document is **`from`**.

***Slide - 18:*** To mention the issue you can simply write the issue number starting with the hashtage then selecting that issue (e.g. `#42`)

***Slide - 19:*** You can do the same for output (= \`@output\`) to make it appear as (= `@output`)

***Slide - 20:*** Now toggle to preview to see the changes before you comment.

***Slide - 21:*** To edit a comment simply click on the three dots on the top right corner, then select edit. Now before we finish this video, there are few concept to understand.

***Slide - 22:*** 1. Every github issue is also a task

***Slide - 23:*** 2. There is one root issue per project. (So all these task you are see in this issue are indirectly linked to the project's main root issue.)

***Slide - 24:*** 3. a task on issue1 can be a normal text task with an output

***Slide - 25:*** 4. a task on issue1 can be a sub task in a task group with or without output

***Slide - 26:*** 5. a task on issue1 can be a link to another github issue2 in which case:

***Slide - 27:*** it does not have output, because all outputs are listed in that issue2

***Slide - 28:*** an output of issue2 can be listed/linked as input on issue1. if that is the case, that task in issue1 has to be listed before the output of issue2 is used as an input in another task in issue1.

***Slide - 29:*** Lastly, if some work or tasks seem to be associated with no output, then this should be first discussed before proceeding.

---

#### Video 5 - @inputs, @outputs, next and their status talk point
- `@inputs` and `@ouputs`
- Taking inputs from other issues
- Taking inputs from same issue
- Linking output to "produced work" and comments
- next labels
- planned, done and in-progress status

#### Video 5 - @inputs, @outputs, next and their status talk script
***Slide - 1:*** Welcome. Here we are gonna talk about how `from`, `@inputs`, `@outputs` and `from` works and how we show the status of the inputs and outputs and also indicate whether a task is still open or done.

***Slide - 2:*** Almost all the tasks, require some sort of `@input` document link.

***Slide - 3:*** and there are even cases where we take multiple input documents. These input files are used to build something new or maybe something to be improved upon. There are 2 ways we use `@input`.

***Slide - 4:*** If our `@input` is something which is produced in another issue we link to that **`from`** issue.

***Slide - 5:*** If the document is produced within the same issue

***Slide - 6:*** then we don't mention the `from` destination. A link to an `@input` document can never have more than one issue it is `from`.

***Slide - 7:*** As mentioned in the last video, every task group has to produce at least one `@output`

***Slide - 8:*** we link to that `@output` document and

***Slide - 9:*** we also link to the specific same issue worklog comment that introduced the output labeling the link with "`from`".

***Slide - 10:*** Such as this comment over here.

***Slide - 11:*** If there are any tasks anywhere which use a specific `@output` document as one of their `@input` documents, we mention all those issues as bullet points below the `@output` document link and label them with "`next`". Every output can have multiple `next` issue links.

***Slide - 12:*** Furtheremore, Each output or input can have one of 3 possible status.
1. Planned (= :question:)
2. in-progress (= :factory:)
3. and done (= :package:).

***Slide - 13:*** Planned output are represented with a :question:, in this case there is no comments

***Slide - 14:*** tasks which are in progress are represented using :factory:. This can only happen if an output follows multiple tasks in a task group that do not ahve outputs themselves, where for example the first task group task created the new output document and the last task group task finishes the output document.

***Slide - 15:*** and lastly tasks which are done/completed are mentioned using :package: emoji. Any task with an immediate output usually switched from :question: to :package: skipping the :factory: status.

***Slide - 16:*** if an output is not used in the same issue as an input for another (sub)task and also has no next field to specify a different issue where it is linked as a task input, then it is a final project output marked with 🏁 in addition to any other status like :question: or :package:
for example
1. :checkered_flag::question: is a planned final project output
2. :checkered_flag::package: is a finished final project output

***Slide - 17:*** That's all for this video, thanks for watching

---

#### Video 6 - Worklog comment structure talk points
- worklog comments with optional and required section A,B,C,D
- worklog titles to be named after the YouTube videos
- Rules on naming the YouTube Video?
- Updating the Timelog document
- Rules on linking the Timelog worklog to github comment
- Which includes
- **`worklog`** (or feedback required)
- **`tasks`** (required - at least 1 task to log time)
- **`proposals`** (optional)
- and **`feedback`** (or worklog required) sections
- Rules on keeping the section titles even if there is no content

#### Video 6 - Worklog comment structure script

***Slide - 1:*** Hey, welcome to the last video of this series.

***Slide - 2:*** If you remember, in previous video, we mentioned each output have to have a linked `comment`. This video We are gonna talk about how to structure your comments.

***Slide - 3:*** Each comment is divided into 4 section, which are Tasks, Worklog, Feedback, Proposals section. Let's quickly go over them individually.

***Slide - 4:*** We start off with the task section.

***Slide - 5:*** Here, you will list all the task you have work on and

***Slide - 6:*** the time you spent on each task.

***Slide - 7:*** When you work on a task and have any output.

***Slide - 8:*** You can either write it down in the feedback section or choose to record a video then upload to YouTube playlist made specifically for WizardAmigos **A worklog video must not exceed 5mins.** In the video you will go over what you have worked on

***Slide - 9:*** All these video are put in the worklog sections,

***Slide - 10:*** and the sequence of your worklog names must match with the sequence of your YouTube video title. The date, however is not important to be mentioned in the comment.

***Slide - 11:*** After that comes the Feedback section. If you have any input or feedback to an ongoing discussion. You can always leave them here.

***Slide - 12:*** Lastly, we have the Proposal section.

***Slide - 13:*** If you have any suggestion of a task, you can mention them in this section. Once they are accepted you can then move them to the main comment.

***Slide - 14:*** Proposal section is not mandatory. You can leave them empty if there is nothing to add there. However even tho you don't have any info to add in these section you are still required to list the section titles in your comment. Plus, you are required to either add the Worklog or a Feedback. You add both if need be but 1 is fine.

***Slide - 15:*** Once done, you copy the comment link,

***Slide - 16:*** and update the output's comment mentioned in your top-level main comment.

***Slide - 17:*** Finally, you can log the time in your contract hackMD file.

---