 Hi everyone. I'm here to talk today about the Gitflow design, which is a Git workflow for design in open source projects. I think it can be a bit technical. It will depend a little bit on your knowledge of Git. I'll try to give some examples. This is focused for designers or maybe for open source projects that want to increase their chances of onboarding designers into their projects and try to make it easier. Just a small overview of me. I'm Diogo. I'm a UX designer based in London. In my day-to-day time, I work as a UX lead for PokerStars. On my free time, I contribute to the RTL app, which is a node managed for Bitcoin Lightning Network. I've also just started contributing to the Torr project, which I was quite excited about. If you want to follow me on Twitter, Diogo R Sergio, if you want to send any emails about today's talk, you can use that email and the slides will be available online. So I'll just talk my talk and giving a bit of an overview of the situation in designing open source projects, and what my experience has been so far over the years. This might not be true for everyone, but I think some people will relate, as it's quite the difficult process for a designer to want him to contribute to an open source project, and actually getting to do it. The whole process is a bit broken, and I think it's mostly because the separation between design and Git and Git is where all the development happens. So there's a huge gap between designers and the development teams. Although it works, I think it's really far from ideal. That's why we see projects having difficulties finding and establish a design team, and I think everyone will benefit from having an easier way of integrating design in their projects and possibly having a design team, better products, happier end-users. But yeah, let's have a quick look of what happens today. So usually a designer probably will start, how can I contribute to this project? Maybe they will go on the project page or even just quick browse social media. Maybe just after that, you open the project website, you try to find anything relating to how you can contribute to the project. In most cases, it will point you towards the Git repo, which is very much focused on development, which is not great, and usually there isn't any design guides or any kind of help that you can contribute to these cases. But usually you can find the link to, let's say IRC or Slack channel. So let's say if you really want to contribute, you will go there. But we are already starting to introducing a lot of friction points. For example, IRC is an example, it's quite common in open source projects as a way of communicating. But for designers, they might not know what IRC is or they don't know IRC. So if you want to onboard users, this might be a drop-off point because they don't care or they wanted to contribute, but it's so much effort that they just go away. But let's say that you really want to contribute to the project. You actually create the account. You mentioned on the channel that you are looking to help with design work, maybe because of different timelines. No one's there to talk to you. So you'll have to wait. Let's say on the good case that someone is there, they might point you into another channel, maybe a design channel, or they might point you to speak to a design lead which is in charge of design so they can tell you a bit more about that. So let's say you get in touch with that person or you join the channel, and probably again you will have to wait because it's a communication. We are depending on humans and it's not always easy to coordinate. So I think by this point, people might be tired of waiting and it's quite a complicated flow, it's an IRC waiting for someone. And if the stars do not align and everything goes smoothly, this can be another drop off point. So we are already having a lot of friction points. But let's say that the designer managed to speak with the designer in charge or join the channel. Then comes another barrier. You'll need to give you like an introduction of how things work, tell you the location of the design assets. If you are lucky, you'll be using some sort of cloud storage, the Dropbox, Google Drive. If you are unlucky, probably they are using local files so you need to ask designers for files which is another break off point. And then when you finally get the files, you end up seeing that they are from proprietary software. You don't have license to use that software. So you'll have to ask maybe for someone to export the files to you. And that's just more issues. But let's say you get all these, you get the files and you speak with the design manager and you kind of think, okay, I'm set. But so you think. The next step is you trying to understand how do you start? Usually there isn't a standard workflow. You just need to talk with people. What needs to be done? What is the team working on? Is there a roadmap? Is there a ticketing system? If TS is usually outside Git, so another ethic. Is there any style guides or guidelines that you can use or that you can follow? What's the review process? Who does it? When does it happen? Can you see the history? All the decisions made until now about the project. So I think it's quite difficult. And I mean, there has to be a better way of doing this. And I think the main issue with this is that the design process is not self-starting. You are depending on a lot of factors. And he has quite a few human dependencies, so you'll need to wait for them. And I think that can be a point of failure as well. So this is what I came up with. It's called Gitflow design. I put it together when I joined an open source project which was fairly new when I was the first designer. So I thought it would be a great opportunity to set up a workflow that solve all the issues I was having and I found over the years. The foundation is Git for this workflow. It's self-starting, so you don't need to wait for anyone. You can just go on the repo and read the documentation and start doing it. There's no human intervention before you can start contributing and it's just there 24-7. It relies heavily on documentation and on the workflow, but I think that's a good trade-off. So yeah, it's basically a design repo. It sits side-by-side with development, which is great. But it's tailor-for-design. It will have everything you need to get started. You don't have to fish information or talk to a lot of people. Everything will be there. It has minimal dependencies. The workflow is documented on the repo help files. You will have contribution guides that will take you step-by-step on how you can do your first contribution. And everything is just there for you to start without any help. It uses open file formats, which I think is quite crucial, so that everyone can collaborate without proprietary software. Although you can still use your sketch and Figma's, the main focus of this workflow is using open file formats. You can do exports to open file formats from those great softwares. I think it increases collaboration between design and development because now these two repositories can be linked together. And yeah, there's no gatekeepers. There's no points of failure, so just go on to the repo and start. As I mentioned, it's quite fearful for designers. The word Git, just as a quick overview, Git is a version control system for tracking changes in source code. It was created by Lonus Linus Torvalds, which is creator of Linux, and it was mentioned by him as a global information tracker. So you are in a good mood. It actually works for you. Angel thing, and light suddenly fills the room. Or if it doesn't go your way, go out there, idiotic truckload of shit when it breaks, which can happen. But in this way, we are using a quite simplistic way of using Git, so you don't use all the dependencies, so it's a bit easier. So why Git? Well, it's because that's where all the development happens, and if it's possible to be in there, I think it just makes sense. Even though it's made for source code, I will show you the benefits so we can use it for design. It's a place for everything, files, documentation, guidelines, accessible to everyone, free to use, and development can be linked together. It has controlled versioning for your design files, so no more final final. It has editable history, so you can just look at all the decisions taken over the year, what was the discussion, the why and the reasons. So that's quite helpful. There's no loss of information. The review process is open to everyone. It happens in the open, nothing goes behind the scenes. The issue system can be linked together directly to the development repo on vice versa, so an issue created in the development repo can trigger an issue on the design, so this creates a lot of seamless work between development and design teams, and you get all the benefits from Git, task management, and project management tools. It relies heavily on a good folder structure when you organize the project. This is just an example of what I use, but the main focus here is just that we have the design folder, and then we have each feature that you work on as a subfolder, and then you have UX and UI, or others if you need. Key important points in this is that we have the UX and UI, and we have the exports. In this exports folder, we create the export images of all your artboards, and this is so we can take advantage of Git image diffs, so once we start using Git, we can have side-by-side comparisons of what changed in those commits, so in this case, I changed the order of the CTIs, and we take advantage of Git functionality, like having it side-by-side, you can swipe, you can see the differences, and these all come for free. And also another important folder is the source files, so we keep a folder for proprietary software because we want to keep all the information, so nothing is lost, like Sketch or PSD, but the main focus is creating these open file format folders, for example SVG, and Aura for OpenRaster, so this is an example of open file formats of SVG, vector file created by Inkscape, OpenSource, which is an OpenRaster file for GIMP instead of Photoshop, they are both based on XML, which means that they are essentially source code, and this means that they can be tracked in Git and used for versioning control, so what developers have for their files, we can now use for design. And you might think that it's starting to look quite complicated, but I think you have a little bit of work when you set it up, but then it just runs, and the more you do it, it becomes quite second nature. And I also think that designers can learn Git, and I dare to say that designers working for OpenSource projects need to know Git, and I mean, it's like any other tool that you learn, I mean, we jump from Sketch to Figma, we learn all these tools, but when the word Git comes into conversation, everyone is so scared, and I think it might be like this in the past, because Git was very common line focus, you have to go onto the terminal and type your own commands, so it was very techy, but this day and age you have desktop applications that do all the work for you with really nice user interfaces, so I think there's no excuses not to learn it. Git flow design is based on a branching model, this is becoming a bit technical about Git, but this is for example an overview of the workflow, we have the master branch that records all the history, we have the design which serves as an integration branch for all the features, so I'll just give a quick run through of the process, we start with master and design, let's say I want to work on UX for feature room, feature one, I create a branch, I'll give it UX, feature one name, it's based on design, I'll go and start working on my files, I'll commit and push so everyone can see and give me feedback, once I'm happy I create a pull request, this identifies the design team, if the design team is happy with the work, they merge it onto design, at this point UX is done for feature one, so this means that the UI work can start, someone picks up the UI, they create another feature branch, UI feature one, they start working on it, they commit, they create a pull request when they want the work to be reviewed, it goes to the design team, everything was okay, it gets merged onto design, at this point both UX for that feature were signed off and they are on the design branch, so now the design team can create a pull request and merge it onto the master, and this means that the feature is finished, so now the development team can pick it up, this is another overview just saying that feature branches can start at any point and they can go up to design but then come back to be reviewed if necessary, and this might be quite difficult if you think about branching and all these terms of Git but I'll just give a quick example of GitHub in 10 steps, this is GitHub which is an application for Git but you can use any and the user interface they have is quite nice and it's easy to use it so let's say you start the application, you want to clone repository from the internet you put on the URL of the repo where the Git flow is hosted you clone it we have no local changes we haven't done any work, I can see there's branches over there, so I click on branches you can see what other people are working on, but I want to start working on my own feature, so I can create a new feature, I give it I'm working on UX, UX working on Lightning, give it the name it's based off design it's okay, no changes I can see now that the Git repository was cloned on to my machine I can go into the folder, start to create my own and start to create my own files and working on them if I go on to the application it will show all the changes I've done, all the files that I've added if I want to when I'm ready to commit I just give it a title and I click commit to UX Lightning it goes on to the Git, if you want to publish for other people to see your work you can publish the branch and it goes on to to the GitHub website so everyone can see let's say you continue to work on the file it will change, it will see the differences between the changes you've made and this is quite beneficial, so you can see on the previous commits, for example in this example in order of CTA, now I changed it and when people are reviewing it, they can see straight away on the application and this is quite nice and then when you are ready, you work on everything you've done and you are ready to submit the work for the for the design team, you just create a pull request it opens the GitHub page, you just give it a title you say what you've worked on and that's it it seems like quite a workflow, but once you start using it, this GitHub you start to see that it's quite easy to do and the more you do it the easier it becomes and just some things that I'm planning on working next using GitHub, LFS, large file storage for example to use for those big proprietary files which they are not tracked in Git, so they can become quite big and just make the repo exploding size ways of using shared master components so we can use those across the design team, so we can share components they don't have to redesign everything from scratch every time and possibly using GitHub pages to create a design system, maybe in an automated way that it can just pick up the files from the master branch and some documentation and creates a design system automatically and everything comes for free and maybe also create pages for let's say developer end of specs so it gives you all the CSS and all that for developers so yeah and that's it it's quite a complicated flow but I think it brings a lot of benefits because everything stays in Git and we are trying to get design and development come close together, so I think yeah, it's beneficial thank you I'm going to ask everybody to please not to leave the room and the other questions as well okay yeah yeah there's ways of you might have an example here but yeah sketch files for example is proprietary although and I explained this in the in the repo more in depth in all these types of files for example sketch files can be unpacked and inside is just JSON files basically so you can unpack sketch files track those and then when you want to use a sketch file you can pack it yeah I think the issue the key point is that if you work on sketch you still work on sketch when you're finished working you just create an SVG as an open file format and include that in the folder and you just keep sketch for yourself as well I use abstract actually for a couple projects but as you said it's proprietary you have to pay for it and as a same issue happens outside Git so developers will not be aware of what's happening and they need to install the app they need to create accounts so it's another barrier yeah yeah definitely and this is where development teams can help out for example the whole this whole process can be a nice user interface so you don't have to rely on the desktop app can be more design focused yeah more questions yeah it's not easy I think it's a trade-off especially because we are using Git we are trying to avoid a lot of conflicts between people working on the same project so we kind of break it apart and so we break it apart as features so everyone works on something separate so there's no clashes I don't think this if this answers your question yeah anything else and I think this process can be used by designers you can go to an open source project and kind of pitch in this look let's create this for your for your project I'm doing a lot of designers I'm ready to do the work or just open source organizations that want to bring more designers into their projects as well yeah just another question when you were showing a Git so right there was a simple case is it useful to do like a rebase once in a while or something like that result conflict so is that something that it's you experience become quite tricky this is where you need to have a lot of knowledge in Git in this example in the Git flow I try to keep things easier as possible for designers to kind of jump in I think as once they start adopting the project and working on it and by working with Git daily they start to learn more and more possibly they leave the Git flow desktop app and use the common line and they start to learn a bit more but yeah it's quite tricky especially with clashes and conflicts between files yeah although those open file formats like SVG and Nora they are based on XML if you are not using any bitmaps inside which can be useful if it's just vector files you can work quite nicely you can even change the you can see the differences in code for example I change the font and you can see that the font changed there so it's just a piece of code but yeah it's tricky but if you keep it if you keep it simple I think it's useful yeah and then we can move from there I think it's changing the mind of designers that Git is not that hard and we can jump in and be side by side with development and after that we can start building on top of it yeah thank you