Task management & version control script v0.0.1

Slides Steps

1. Introduction to the Topic
   One of the key factor for a project success is the flow of information and proper management. In this video I am going to teach you how to manage and version control your UI/UX project using open source and free applications like GitHub and Figma.

This is the project we are working on called Tiling window manager, which we are going to use as an example for this video.

2. Issues
   This page is what we call an Issue. We have an outer most or known as the main issue. This represents the whole project. Once this issue is closed, the project will be consider completed

There are multiple sub issues. Each representing a different component, which we will get to later in this video.

3. @todo and @info
   Each issue has a @todo tag which contains all the tasks and there is also an @info tag where we provide few lines of information regarding that issue/component

4. Status icons
   We use icons/emoji to show the status of the task. Question mark emoji means the task is planned, Factory emoji means the task is in progress, and Packaged emoji is use for completed tasks

5. @input, @outputs and Next
   We use an @input tag to show what that task needs in order to proceed further. Now these input shows us specifically what is being taken as input and where it is taking that resource from. In this case, it is taking the SAID file from the SAID issue. If we are calling input from the same issue, then we don’t mention where that input is coming, only the file name.

We use an @output tag to show what is the expected outcome of the completed tasks. We also link the output file to their destination and add the comment where we produce the worklog of that task.

6. Comments
   Comments is where we provide the worklog videos. In these videos we mention what task we worked on and what is the produced output, if there is any file we also link that to this output. We log our time, and attach tags of the task’s status. For completed task add done and progress tags if the task is in progress.

We copy the link of this comment and attach it to where the output was planned

7. Worklog videos and time logs
   Each worklog videos are uploaded to YouTube with the worklog number in their title

8. Proposed Tasks
   If there is a new plan or idea. We propose those task here. Once those are accepted we
   place them under the last output as Next. In cased where something is depended on
   this Issue we put that as Next after the final output.

9. Figma Pages
   On Figma, we use pages to represent components. The pages are named after component but without the version number. Inside the pages, we place canvases inside which we have a container with the component title and version. Next to it, we have last updated date and the link to the component’s github issue. Below that we have a small description, after which we list the dependencies and dependents of this component. After that, follows the UI designs

10. Links
    Each dependencies and dependents are linked to their respective canvases. Clicking
    them takes the user to that component page.

11. Go through the whole process
    Now let me show you how it works in process. This is the main issue. Let’s assume, we have proposed two tasks. First Design – TabContainer. Second task will be Design – Tabs component.

Once these tasks are accepted, We create an issue for each component. We add the inputs, place the proposed to-do list inside the issues, and link the output then the next task

Once the tasks are done, we upload a comment, linking our worklog video, all the task we have worked on. Their status and the time we spent on them. Then we simply link our output. In this case, it is a Figma file. We scroll up, and link this output to the comment where we uploaded the worklog and the output. We also link the output file here.

We go to the next one, and do the same think.

Once everything is done, you upload your worklogs to the discord channel assigned to you. That’s all, thank you.

Task management & version control script v0.0.2

Talk points/topics

Video one

• Top level task comment structure
  • Issue Title
  • @info and @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?

Video one script

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.

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

We start out our comment with an @info tag. which houses, some general description about the issue. Following that we have @todo tag, where we place all our task.

Each issue must produce 1 @output. Each task or task groups created within this issue must also @output. There may be multiple outputs produced and used wihtin the issue but the last output will be considered as the produced output of that issue.

If there is a situation where there is no produced @output then we keep those in the Task Management issue. However, you are always encouraged to kindly place the task within a group which may closely relate to the output. For instance a task for a discussion on a subject does not produce any @ouput it still should be placed within the task group which related to that subject and have an @output. As you can see in the example here for Task Management & version control script

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

Video two

• @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 two script

Welcome to the 2nd video of the series. Here we are gonna talk about how next, @inputs and @outputs works and how we show the status of the tasks. //// NEXT SLIDE

Almost all the tasks, require some sort of input and there are even cases where we take multiple inputs. These input files are used to build something new or maybe something to be improved upon, creating a new version per say. There are 2 ways we use inputs. //// NEXT SLIDE

If we require something which is produced in another issue we mention where that file is being taken from. //// NEXT SLIDE

If the file is produced within the same issue //// NEXT SLIDE

then we don't mention the from destination

As mentioned in the last video, every task group produces an output//// NEXT SLIDE

we link the output to that file's destination and //// NEXT SLIDE

we link the respective comment where the worklog of that output is presented. //// NEXT SLIDE

Such as this comment over here. //// NEXT SLIDE

If there is a planned task or issue which comes after this output. We mention that using a next task with a link to that issue.

Furtheremore, Each output or input have 3 status. Planned, in-progress, and done. //// NEXT SLIDE

Planned output are represented with a

Video three

• 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, task, proposal and feedback sections
  • Rules on keeping the section titles even if there is no content

Video three script

Hey, welcome to the 3rd video. //// NEXT SLIDE

If you remember, in last video, we mentioned each output have to have a linked comment. //// NEXT SLIDE

This video We are gonna talk about how to structure your comments.

Each comment is divided into 4 section, which are Worklog, Tasks, Proposed Tasks and Feedback section. Let's quickly go over them individually. //// NEXT SLIDE

When you work on a task and have any output. //// NEXT SLIDE

You are required to record a worklog video and upload to a 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. Remember, you can only upload 7 worklog video per day. //// NEXT SLIDE

All these video are put in the worklog sections, //// NEXT SLIDE

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. //// NEXT SLIDE

Following that we have the task section. //// NEXT SLIDE

Here, you will list all the task you have work on and //// NEXT SLIDE

the time you spent on each task. //// NEXT SLIDE

When the task is complete you will add a done tag before the task name, otherwise we leave them open or empty //// NEXT SLIDE

After that comes the Proposal section. //// NEXT SLIDE

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.

Lastly, We have the Feedback section. If you have any input or feedback to an ongoing discussion. You can always leave them here. //// NEXT SLIDE

Proposal and Feedback section are 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. //// NEXT SLIDE

Once done, you copy the comment link, //// NEXT SLIDE

and update the output's comment mentioned in your top-level main comment.

Finally, you can log the time in your contract hackMD file.

Video four

• 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
• 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 four script

Welcome to the fourth video. In the last three videos we went over the GitHub structures. Now let's have a look at how that works with Figma. //// NEXT SLIDE

On the left here you see the Figma pages. //// NEXT SLIDE
Each page here represents a different component. //// NEXT SLIDE
When you open a page, you will see artboards/canvases where your design resides.

And each canvas contains a header section. //// NEXT SLIDE

This section have a component name with the version number //// NEXT SLIDE

which must match the canvas name and the output expected to be produced in the github issue. //// NEXT SLIDE

Followed by the date when it was updated, //// NEXT SLIDE

and a link to the GitHub issue where this component are created. //// NEXT SLIDE

Below that we have a small description about the component updates. //// NEXT SLIDE

After that we have the list of dependencies //// NEXT SLIDE

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. //// NEXT SLIDE

When you make a different version of a component. You deplicate the same canvas, //// NEXT SLIDE
change the version name, //// NEXT SLIDE
the updated date //// NEXT SLIDE
and description of update. //// NEXT SLIDE
Once done you can modify the design in your new canvas.

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?

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. //// NEXT SLIDE

We will duplicate the current canvas, we keep everything the same //// NEXT SLIDE

but this time we add a deprecated tag in the header, //// NEXT SLIDE

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. //// NEXT SLIDE

That's all for the 4th video. We have one last video remaining where we will talk about how we link Figma to GitHub

Video five

• 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 five script

Welcome to the last video of this series. We will be finishing on the subject of how we connect Figma and GitHub together. //// NEXT SLIDE

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. //// NEXT SLIDE

To link the Figma file to GitHub output. Simply goto the component page, //// NEXT SLIDE

right click on the canvas name, //// NEXT SLIDE

go to copy/paste as, //// NEXT SLIDE

then select copy link. Then you can use that link for the output file on GitHub. //// NEXT SLIDE

//// NEXT SLIDE Simply select edit on GitHub comment, //// NEXT SLIDE

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 //// NEXT SLIDE

Lastly to publish your whole project. Click on share button on the top right conver of Figma, //// NEXT SLIDE

click on publish to community, and then select publish. //// NEXT SLIDE

From the community page you can always get the share link under the Share title on the bottom right corner. //// NEXT SLIDE

Now, we come to an end of this series. I hope you find this knowledge beneficial, if you have any questions do let us know and if you have any suggestions we are also open to hear them. For now, thanks for watching and take care.