Transcript
Unknown Speaker 00:00
Hello, everybody. Welcome to Introduction to GitHub. I'm Chris Ciccone. I am MC and member since 2015. And I'm really looking forward to this session. First, I'd like to hang on a second, I've got to find my I'd like to thank Microsoft registration Assistance Fund, sponsor, axial Ignite sponsor, and all the other sponsors listed on the program schedule. And I welcome you. And there we go. Okay, so we have slide one up. Okay. So this is our old title for today's session, but we've had to make a few changes is Jerry Moore can't be with us today. So am I software architects, architect, shel Olson has agreed to step up and help.
Unknown Speaker 01:14
And sorry, I wouldn't get this on a separate thing. Sorry. Okay. Okay, so shall I'm Charles have revised the session. It's now introduction to GitHub with an expert and an amateur. But it's still for cultural heritage professionals like us. Show Wilson is a coding cultural heritage professional here to share the benefits of using text based formats and get to create and share content more broadly. And Charles Walbridge is lead collections photographer at the Minneapolis Institute of Art, or Mia, he's worked at miaa for more than 15 years, and the work he does including still photography, 3d scanning, conservation, photography, image data standards, and environmental sustainability. And I would like to add on a personal note that I, my first FCM, was in Minneapolis, and I attended a really great photogrammetry workshop in the miaa photo studio, and that's where I met Charles for the first time. So I will turn it over to you guys. Thank you very much.
Unknown Speaker 02:30
Thank you, Chris.
Unknown Speaker 02:32
Thank you, Chris. Good morning. Um, hey, I'm Charles. I use he him his pronouns. I am, as a description, I'm a middle aged white guy with short brown hair, and my, my beard used to be blonde, and now it's now it's mostly gray. My, my virtual background is the photo studio at Mia where I am not, I'm actually in my in my basement office. Um, I wanted to do this session because I wanted to have a basic understanding of GitHub and and how it flows. And I don't have actively have a need for it in my work right now. But I can see how it's really going to be useful for me, and, and I know from Shell's work that we use it a lot at me. And so I want to know more about it. And again, Jeremy sends his regrets the the GitHub, but one of the GitHub repositories that he's working on is called coding for ch and it's, it's one of his many projects, and he's using it to share code that might be useful for, like, archive mass digitization. So let me know if you want to want to talk more about that. And let's, uh, let's go forward, Jill on today in our, in our session, we're gonna we'll talk about GitHub concepts, and then we'll follow a super simple project, just to see what steps you might go through and what the interface looks like. And then we'll bring some new contributions into a project to make sure it works. And then we'll try to go live and have all of you or a few of you contribute to the project. So if you if you're watching the slides, now, you can just you can just follow along, even if you don't try to set everything up for yourself on GitHub right now. Um, and if you're following along, you can you can log in, and we'll do our intro, and we'll show that project and then we'll ask you to actually contribute to that project. We think we'll be able to pull in your contributions through GitHub and also from the chats and and we'll, we have confidence that that will work when we go live. But we'll leave this project open today and tomorrow to the end of the conference. So we'll aim to keep pulling in new content until at least then we don't want to get bogged down and getting every single person to contribute to the project in the next hour. So if it's not working, try the chat in the in the q&a, but, but don't stress about it. And let's go over to you shall.
Unknown Speaker 05:12
Okay, hi everybody, I hope that everything here is working with the webinar, you should be seeing our slides and my little virtual head up in the corner. My name is Cheryl Olson, my pronouns are he him pay them. And I'm a software architect at the Minneapolis Institute of Art, where I work on the website sort of database, data transformation, things to get everything that the museum has out into the world for people to see it. I'm going to spend a few minutes talking about git, which is a program for managing versions of things. And GitHub, which is a platform built around get to centralize sharing and collaboration on projects. This is a really interesting topic to me, I sort of I work with it all day, every day. And it has some really huge benefits to the work that I do and how I keep track of what is happening. That's coming from a software development background. But it's also really relevant to developing any sort of content, any sort of authoring or editing project that I see a lot of them happening in my Museum at different ways and different workflows. And we've, we've tried using it in a couple of different ways, and had some successes and some failures with larger team. So we can talk about that a little bit at the end to what is Git. This is the Wikipedia version. The definition of what Git is, it's sort of jargony. And I'm going to go through each of these terms in bold to dive into the important features of git, it's a computer program that you, you download it on your computer, like any other program, and you run it alongside projects that you're working on. To manage files, it was created about 15 years ago, and it came out of the project. Linux, which probably everybody right now has a device somewhere within five feet of them running the operating system called Linux. Linux got to be so big and so complex that they kind of they ran out of version control systems that existed 15 years ago, there was there weren't enough good options. So they actually sat down the developers of Linux, and they created this system called get primarily because they wanted it to be fast, they needed something that had a free license, the system they were using, before they wrote get had some copyright problems crop up to switch from it. And there, there weren't any other adequate options. And they decided, they would just go ahead and they would write their own system. So Git is a distributed version control system. It sort of looks at all the stuff that you've got in your project, mainly files, mainly files built out of text, commands and lines of code or lines of writing, and it keeps them all together, it tracks different changes that are happening. Doing software development means you're constantly going in sort of changing things, making new features, writing new lines of code. And so that's a lot to keep track of even for one person. And then when you get to a project like Linux, which has hundreds and hundreds of diverse contributors. That's just impossible to do. The way that it used to work in element is you would sort of talk to your colleagues or your co workers and say, Okay, I'm working on this file. So nobody else, nobody else can work on that file, you would do something called a checkout, you would say, this is my file, I'm checking it out for the day, I'm gonna make some changes. And when I'm done, I will check it back in and then it's sort of open for anybody else to go in and look at. And that just doesn't scale that doesn't work on a large project. So Git is a system to sort of streamline that flow of managing, who is looking at what pieces of source code in a system, who is doing, who's making changes to them when those changes happen. And here this definition, is talking only about source code, but it applies equally to any sort of source content. So it can be source code, it can be lines of code that are building a software project, but it could also be you're writing regular English language. or other language documents, it could be a website with all the web pages and their content, their images.
Unknown Speaker 10:06
It also is really good at tracking changes in any sort of plain text file. So that means you can, you can capture data in it really well using data formats that are primarily based on plain text. You can even track Word files or Illustrator files, or videos or images, git has some special features, and you can build special plugins, forget that know how to go into specific file types and really understand what that file type is and how to track small changes in different files. So it has a lot more applicability than just for computer programmers writing source code. The thing that it is really good at is this idea of tracking changes. So one day, you have a project and you sit down in the morning, and you're going to work on that project a little bit, you're actually making all of these changes, some small, some big, some things are moving around, maybe some things are staying in the same place, but being changed. When even working by yourself, Git is really useful because it sort of it captures all those changes and how they're happening individually, but also as a larger group. So it makes it really easy to see from version a, version B, what has changed. And then another big thing of Git is that it is focused on enabling non linear workflows. This doesn't mean that it is bad for following linear workflows, but that it's trying to go beyond the idea that there's a single pipeline of uni directional changes happening. So a lot of the content editing that we do in the large organization that I work for, is sort of a traditional editorial publishing system where somebody writes content, and then they send it to somebody else, and that person edits the content, then they send it to somebody else, and that person edits the content again, and it kind of goes down the line. one person at a time is working on any given article or a project. And once that project is done, it's sort of wrapped up and it's finished, and it gets put on a shelf that gets printed in a book, or it gets created as a website, and it's set in stone more or less. So this, there's no part of Git that makes that hard, that will work just fine using Git, but Git was created, primarily to serve a workflow where things are kind of all over the place people are making changes. Maybe nobody even knows who that person is, there needs to be a really serious review process for every change that happens and changes need to be able to lay in on top of each other. So one change might get made. And then another change that started off on an older version now has to incorporate the changes that have happened in the meantime, from when it was originally started and to when it was finished. So it doesn't necessarily go from A to B to C, it could go from A to C to B to x in sort of a very jumbled workflow. And another part of that is that a lot of these projects are distributed people are all over the world are all over. in different fields, they're not all necessarily primarily working on any given project, someone might step in for one small change that they want to see in a project and just sort of offer that up as a as an opportunity for the people maintaining the project who are focused on that one project to incorporate it or not, they're just saying this is something that I found useful. I want to I want to send it into you. In case you might find it useful, too. And there's a whole process that goes along with that with saying, well, maybe it's not useful to us. But we can see how it would be useful if you do these three or four things and it sets up a whole dialogue of back and forth on how can all of these changes be merged back in the best way possible. So to wrap all that up get is a program it's like a lot of other programs, you kind of just download it onto your computer, and it serves to enable this distributed version control system within the projects that you're working on. It tracks changes in files and in groups of files. So a project is essentially just a folder with a lot of files in it. It looks at all the changes that get made from one version to the next. It also keeps track of who made that Those changes, and when did they make those changes,
Unknown Speaker 15:04
and is really good at when there are a lot of different changes out there that are floating around, and maybe some of them. conflict with other sets of changes. One of its specialties is to merge changes back together seamlessly. So nobody's work gets lost, everyone can kind of have their own version of the project. And when they go to merge all of those versions back together, there's a whole process for recombining things in a way that doesn't step on anybody's toes. I think the metaphor that really worked for me is using Git is like attaching metadata to each step along the way, as you go building a project. There's a concept called a commit, which is kind of how you, we'll talk about that in a minute here, each step of the way, you commit your work in little bits. So it's a way of sort of journaling through the progress that you're making, and recording little journal entries or diary entries. And it means that when you go back to look at a project, the way that those changes happened is made very visible. there's a there's a log of all the changes that have happened from when the project started to the point that it's at right now. And it's it's like a way to digitally archive your daily work process. And so those are all of the really great features that Git has. There are some downsides. It was built by a bunch of computer programmers, which means that it's extremely complex. And that makes it pretty hard to learn the learning curve is steep. I have said that it's a program that you just download to your computer, but it is a command line interface. So you download it on your computer, but the only way that you can really the the first interface that's presented to users is typing commands into an obscure tool used by computer programmers. And that's pretty hard. So this is where we get to GitHub. GitHub is a online platform that was built around get to sort of wrap up all of those rough edges to make it a lot easier. When GitHub first launched its motto was to enable social coding. So people who are doing this computer programming work, could kind of showcase their projects, share them with other people, and everyone could kind of they could come together and work on things and a lot of ways. It's like Twitter or Facebook, for computer programmers, you get a profile picture, you set up some basic information about yourself. And then you can put all your projects up there, and go find all of your friends projects and help people work on things that they're interested in working on. So some of the great features of GitHub is that, if nothing else, it's a place that you can back up your projects, git makes it really easy to send the work from your local computer all the way up to GitHub and have it hosted there and go back and forth. Having the work up on GitHub makes it really accessible to other people who are browsing through or interested in contributing to a project. And then like I mentioned a minute ago, it provides a really insightful history into how a project works and what's happening. And it can be a great learning tool, even to go in and look at how somebody else is doing something. It's all sort of, it's almost like you can rewind in history in the history of a project and press play and see exactly how something was built. And GitHub is one example of this idea of a platform built on top of get there are a lot of other companies that run their own versions. We're gonna focus on GitHub here, because it's the most commonly used. Most people know what it is. But there are a lot of alternatives out there. So we don't want to we don't want to give the idea that GitHub is the only thing available for these uses. There are a lot of systems that you can sign up login and have a place to do the same tasks. So that is a really quick introduction to what Git is and what GitHub is. And now we will move to Charles to talk more about it. Charles, are you muted I think
Unknown Speaker 20:03
Thank you, thank you, I tried to unmuted myself and just a minute ago, and I couldn't do it. And so I knew I was stuck here all by myself. Um, so moving on to GitHub concepts and terms, um, repository is the most basic element of GitHub. And it's easiest to imagine as just a projects folder, it contains all the project files, including its documentation, and its stores like show was just saying all of all of the all of the each files revision history. And repositories, or repos can have multiple collaborators. And it can be public or private. And you will, when you're looking at a repository and GitHub, you'll see it as a top level in the in the GitHub interface, and you'll see the files that it contains. And a commit is the Oh, sorry, we're moving on the commit is the most basic element of Git is the next most, it's not the only basic element of git, it's a group of changes that are somehow related. And they, they come with their own metadata, that's the commit message that describes their content. Each commit is saved in GitHub database. And importantly, so is the relationship that that that that commit shares with all the other commits. And in the next slide, we have an example of a repo from Mia. And this. This shows us that our our username is artemia. And our repository name is his collection in this case, and we're looking at the master or the main part of the repository. And it contains folders and documents, including readme.md. Down at the, at the bottom of that little window there. That's displayed as a file icon. And it's also displayed its contents are displayed. At the bottom of the window. In the middle column of that central panel shows you the most recent changes the commits that have happened to that file or folder. And then Next up, we have a branch, you know, in a branch is a parallel version of a repository waiting for my slide to catch up with me, a branch is contained within the repository. And it doesn't, it doesn't change the primary or the main branch. And it lets you work without disrupting the live version. When you've made the changes you want to make you merge it back into the main branch. So when you make a main branch, you take the entire repository that most most of the time the folder and its contents and you essentially you make your own copy of it, then you do your work in your own branch. And when you're ready to bring it back in, GitHub will check to make sure you can put everything you've done into the main repository without any conflicts. If you can merge without messing anything else up, then the owner of the repository can can accept or pull your changes back into the main branch. And if you can't merge without messing things up, then you have some discussing to do with the owner of the repository, and GitHub has tools for that, as well. Next up for concepts in terms we have markdown and markdown is a is a simple file format. And, and text approach, like Doc, and RTF and txt. Um, it's easy to just type in plain text with just a few extra characters to call out what you're doing. Um, GitHub markdown is called GitHub flavored markdown. And we have a couple examples of that for you. So like you've seen in many other formats, you know, you use a single hashtag for big headline and multiple hashtags for smaller headlines, asterisks for italic text and a couple of colons to separate out any of the emojis that you can think of as long as you know how to spell them. So markdown will actually show articulated lorry as this, this little tiny semi truck. And markdown is particularly useful in GitHub, because every repository has has that readme.md file, and GitHub reads this file and it displays it to you in the main directory of your of your repo. And here, we're in the same repository that we saw before. And we can see that the master branch of this repo contains three folders and for five documents, the last of which is readme.md. And then the readme doc is displayed with its markdown rendered as links in bold text, and so on. Further down in the view of the repo.
Unknown Speaker 25:04
So this is the actual raw text of that's in the markdown of that file. And so you can see that shell is used square brackets and parentheses to call a website's, the greater than symbol calls out a line text. And the the double pound sign plus y becomes a headline. And now, here's our simple diagram of, of the flow in in GitHub. And we'll show this in action in a few minutes. And our code or our text or our project is moving from left to right in this diagram, and the main branch is the one that everyone is working on. Just in October of this year, GitHub finally switched the name of the name reposit of the main repository from Master to main. And so you might see an old instructions and repositories where they're still using the old terminology, but everything that you make that's new will use main instead of master as the primary branch. And so our line breaks off here, because you have an idea for a change. And so you make a feature branch from the main repository, and now you're working on your own copy. You write your own changes, and when you're satisfied with them, you let the owner of the repository know they're ready by submitting a pull requests. And then you're asking them to pull your changes into the main repository. If you need to you discuss your changes. And then when the owner of the repository is ready, they'll pull or merge your changes into the main repository. And then your change is part of the main branch going forward.
Unknown Speaker 26:52
Charles, there's a question from one of the attendees asks, Is there a max file size? For example, if I wanted to host a website with a pop up video? Can I host the entire thing on GitHub and buy a domain name?
Unknown Speaker 27:13
What does the domain I'm trying to think how the domain name will? We'll catch up with that. And let's let's make sure about that with Shell I don't think there's a maximum file size for GitHub, but it gets like we've, we've considered loading a lot of 3d data onto GitHub and it at this point, it's not practical just for storing files. So let's ask shell about that. Because our next slide is is him talking and additional concepts for for the GitHub has added to the Git flow. So
Unknown Speaker 27:48
so I can, there is a maximum file size that GitHub sort of enforces, but doesn't really enforce that hard they get is designed to host mostly plain text files. So when you start putting images and videos into your Git repository, it takes away some of the speed, the advantages they get has around being really fast and the things that it does. So you, you can do that. And I saw Greg in the chat, chime in, there is another sort of an add on service that GitHub has built, where it allows you to host any size of file you want. And it sort of adds a layer to get the program running on your computer to manage those files a little bit differently than it manages normal Git files. And then because it's all tied together with GitHub, they can also count how many megabytes or gigabytes or terabytes you're storing and charge you adequately. So it's all part of GitHub, commercial extensions to how Git works. So that is possible. And there's also GitHub has a service called GitHub Pages, which is used to create web sites, web pages and hosting. We're actually going to talk about that in about 15 minutes. And it does have a way that you can add a domain to your website and host it all within GitHub. And it's a pretty cool system. So we can talk more about that at the very end. But we'll give you a little preview of how that works here in section two of our presentation. So Charles did a great job of talking about GitHub, and sort of what it adds to the to his version of command line. Git did a lot of computer programmers like me run every few minutes when we're working on a project on our local computers. The big thing that it does is it really enables it makes it easy to work with a lot of other people because it takes everything out of a text base user interface and puts it up on a website with Excellent user centered design, I mean, maybe not excellent, but very good user centered design to make things easier and make people kind of go through this flow that Charles explained where the idea is, you're always starting from the main branch of repository, and then kind of creating your own copy of that project and making any changes you want, and then submitting those changes back to the people who are in charge of the project. You can kind of go through this is called a pull request. And it's a process of saying, here's what I'm working on. Can you review it? Can you give me pointers? Can you give me some direction on how I should continue working on this, and then at the end of that process, everyone gets together and they say, this is looking really good, let's let's get this merged is sort of a phrase, that means we're at a good place, everything is compatible now between this new change and the existing version of the software, let's bring them back together, let's merge them back into the main branch so that this new feature is now a part of the overall project, and everyone can get the benefits of it. GitHub adds some other features like issue tracking. So if you have a problem, you can go to GitHub, and you can switch from the code view of a repository to the sort of problem view or question view, that issue tracking view, you can just post an issue with the repository and the people who know how to deal with that issue will come in, and they can answer your question or help you fix something that's not working. It's also this platform where a lot of people have accounts. And it's kind of a, it's the place where people go by default to look for new software. If I'm working on a project, and I need something specific, I might not want to build that myself. And there are probably a lot of projects on GitHub that are tailored to doing what I want to do. So then I can go look at all of those and say this one looks like it will fit exactly what I want to do. I can evaluate it, I can browse through its GitHub activity, its issues and see if it looks like something that I will enjoy working with, and I can grab my own copy of it and build it into the projects that I'm working on. We've talked about branches, which is one way to sort of one way to copy the existing project into your own little sandbox. There's another concept that's very similar called forking. And what a branch is, is a branch is a different version that stays within the same repository. What a fork is, is creating a copy of the original repository and making that my own individual copy.
Unknown Speaker 33:02
So at a simple level, to make a simple change, I can create a branch of a project and work on it and send those changes back into a branch. On a team when you're working with your own trusted colleagues. Most people don't fork a repository to make different changes. The project team works within a single repository, creating branches that then other people can jump in and collaborate on. But when you want to kind of take a project and really make it your own project or make your own version of the project, you can also do a very similar copy. But instead of creating a new branch within the existing repository, you actually create your own independent repository. But some of the cool things that Git does means that there's still seamless interoperation between two different repositories, it's very easy to take a branch from one repository, make a pull request on that branch and send it back to the original repository. So Charles,
Unknown Speaker 34:09
oh, sorry, back to me. I was taking that question from the chat and moving it into a slide later, but I'll do that in a minute. Let me just paste this. Let's fall. Here, we're going to follow some simple changes in a repository. Let me minimize this chat window. I'm in our next slide where we're creating a file called Joe, will you advance that's fine. Um, here's a little screenshot of us creating the file called basho. One inside a repository called MC n Haiku test. And and we're filling in with a with a bash. Oh, hey, Haiku. And as you can see, it's the first three lines in that new file that we've made. You can see that because it's because they're numbered. And then in the next in the next screengrab, we've had GitHub can compare our new file, we've move up move ahead show, we've had GitHub compare a new file to the whole repository to make sure it doesn't conflict with anything. Um, so it's showing us all the changes that can detect. And we're seeing that in green, we've we've changed a file by creating it. And it's got three additional or new lines in it. And notice that it, it has three little green squares right there, because that later gives us an idea of the size of the changes we're making. In the next slide, we've added another Haiku to the same file. And GitHub is telling us that there are four additions, including including that empty line line four. So this is how you visualize the additions that someone wants to make to your repository or to your file. And, in the last one of the super simple workflow, where we've deleted the the Haiku that includes the swallow, and we're and and so that has become red. And we're adding the dragon fly Haiku and that appears to us in green, you can see that the line numbers are the same, which is another indication that we're replacing a haiku and not adding a third one to this file. So that's a simple visualization of the things you see when you're when you're collaborating and GitHub. And sorry, you can't see the indicator here. But there's a space within GitHub, where you can see what all the previous changes were. And you can roll back to them if you if you want to. And that's super handy. So that's our super simple visualization of the of the change workflow. So let's either take questions now or see that in action for a couple of minutes. And did I Yep, I pasted that one into our notes. Shell, I'm just going to read it to you. How does GitHub inform about intellectual property if I make use of an existing project or content out there? And Shell's got a good answer for that? I'm sure. All right. No, he does. Yeah.
Unknown Speaker 37:15
So yeah, that could be a whole entire presentation. But a lot of GitHub is centered around this idea of open source code. So most repositories will have an explicit license attached to them that says how you can reuse the code. So that's one way is a lot of the code is out there. It's intended to be shared, it's easy to make these branches and forks. So the license file is kind of it's, it's treated similarly to the readme, where you, you put a certain license into your project, and GitHub attaches that to the the whole interface that it has. And as far as intellectual property goes, there's a whole legal framework that was in the news, actually, very recently around American copyright law on what happens if someone has posted copyrighted content on their GitHub that belongs to me, I can go and I can make a legal claim to GitHub that that is infringing on my copyright. And GitHub then has to obey American copyright law about what they do next. But that's that's a whole other complex system that I don't really want to get into in this check. There are there are systems in place to handle that.
Unknown Speaker 38:43
Cool, and I'm taking the other question out of the q&a. And I've moved that to our questions slide at the end. So we'll, we'll move forward with that.
Unknown Speaker 38:53
Okay. So we've sort of indicated that we're going to do this little project and the idea that we came up with is to make a collaborative Haiku generator. So we've got a project set up on GitHub. Now we'll share the link to that in a second. I'm gonna have to figure out how to change my screen to share that project instead of these slides. So it'll take me a second. Charles, do you want to talk through a little bit?
Unknown Speaker 39:27
Yes, and I'm gonna
Unknown Speaker 39:30
switched.
Unknown Speaker 39:31
I have the I think this is the random Haiku URL. That looks right. Okay. Yep. And then the other link that I have, let me see where my chat is. This is that's not it. Hold on. I'll be right back. We'll get there. I'll get that into the chat.
Unknown Speaker 40:02
Okay, Does everybody see? 2020 get Haiku?
Unknown Speaker 40:09
Yes.
Unknown Speaker 40:10
Okay. And so this is the little playground we've created so that everyone who is interested can go test out some of these features. It's a repository on GitHub that we worked to host under the Museum Computer Network GitHub account. And it has a readme MD file with a haiku. And a picture of this famous Haiku poet named basho. And this Haiku here actually is not a haiku by Bashar, I wouldn't want to embarrass him. by claiming that he wrote this, this is a randomly generated Haiku recombine from different haikus that Charles found. And so we have a folder in this repository, called haikus with a few markdown files. And these markdown files have basho haikus in them. And what this repository doing is reading all these haikus and shuffling them together, and then recreating a semi randomized Haiku. You can see here is the raw source of this file. It has a list of 50 basho haikus. And what we're going to ask people to do here in a second is to log into GitHub, go to this repository and create their own haikus. And we have a few examples that are ready to go here. And we will, as we see these come through, go to the pull request page that GitHub creates. And start merging these so that everyone who wants who's interested in participating can have their own Haiku included in this repository. So as I was talking there, I just went to this pull request that was created URLs with a haiku from Carla. We can look at what was different about that. And it says that there were changes to these two files. This file here, haikus slash carla.md was added with a unique Haiku. And there are some other changes. And if we go back and look at the main page of the code, we'll see up here that the latest change was to merge pull request number five, which is the one that included that Haiku from Carla, if we go into the haikus folder, D there's now a file called Carla MD. And the next step to this is that we also have this repository set up to build a web page that's based on these haikus. And whenever a change is made in the repository will update this website with a new random Haiku. So here's the example of the Haiku. We can go in and find another pull request. And read a little bit about it, we can look at what files have been changed, we can see here's the example of a new Haiku as we're doing this, on a large scale with everyone participating, we want to remind people of the MC n Code of Conduct to make sure that nobody is submitting content that might be offensive or hurtful to others. And if you're a haiku master who can sort of make haikus off the top of your head, we encourage ncn themed or current of Haiku to be submitted to this repository. But these three lenses, they look good. So we can go back here, merge this pull request, and then Kevin's Haiku is now included in the repository.
Unknown Speaker 44:02
And shall if I may, it's, uh, it's quarter after 12 here in central time, and I think we can, I don't think we need to merge all of those pull requests. Let's, uh, let's see if we can get people writing some Haiku and, and get those into so do you want to skip out to? I'm going to call it our slide number 38. And where is no, actually I'm going to say it's slide number, our slide number 41. Where we have instructions for for people to start writing their first few, or I'm sorry for everybody to write their haikus.
Unknown Speaker 44:44
Yeah, I will jump to 41.
Unknown Speaker 44:50
These are all the things we just did in GitHub. Those were backup slides in case in case that didn't work. So this is I'm going to paste that into the chat as well, you'll see that that's a slightly different address. But that is the that's the address where when you're logged in just making sure that's a different one. Okay? When you're logged in, you can go go to this address and add add a file here.
Unknown Speaker 45:28
Yeah, and the great thing about Git is that this is distributed nonlinear workflows, we don't have to do all of this in the next 15 minutes. So we'll kind of, we'll wait for pull requests to come in. We'll merge a few as they happen. We can check back to this random Haiku generator, when I refresh the page, it shows that there is a new Haiku generated from the number of haikus that are included. Make sure that's in the chat.
Unknown Speaker 46:01
And shell that also, um, you also have that setup to refresh every three minutes, right? Yeah, so well, it will do both.
Unknown Speaker 46:11
Yes, it changes when new content is sent into the repository, and on a regular schedule, just to rotate through.
Unknown Speaker 46:24
Cool, and I see eight current poll requests right now, I don't know if any of those are new. Doug Peterson. Look at that. So the very number 16. There is brand new.
Unknown Speaker 46:39
Yeah, I think a lot of these are new. So yeah, we can go through and start merging them.
Unknown Speaker 46:48
Thank you all for participating. Oh, thank you. Um, thank you, Diane. And and Chris for noting the the structure of a haiku. And you will notice from some of these older basho, Haiku that the he wasn't following that, because it wasn't writing in English, you know, these, these are all translated. So they are they vary a little bit, but they they still sound good when they're randomized. So
Unknown Speaker 47:18
Charles, on shell, there's a, there's another question from Rachel, and the q&a panel. I'm wondering if you want to answer that now or save it for later. It's about what's two questions. One, is there a way to follow other GitHub projects? Yes. And the other question is, if using GitHub to create a project documentation, what are the pros and cons of using GitHub versus creating a wiki to do version control?
Unknown Speaker 47:48
That is an excellent question. I'm going to move that forward into our questions slide. Thank you, Rachel. Um, and then we'll go back for the first one. Let me find our questions slide.
Unknown Speaker 48:10
Good. Um, yes, you can, in a very similar way to how you follow somebody on Instagram, you can follow other GitHub projects, so you can star them, you can watch them, I can't remember the exact terminology. Um, there's a watch and an unwatched in the interface. So you can be in this case, I'm looking at my GitHub interface, and you can be notified of all conversations you can, you can be notified of new releases, you can be notified if you're mentioned directly. And so all of those are available in GitHub. And again, that's a GitHub addition on top of the the Git base. And I see that shell is adding pull requests like crazy in that in the back. And then this other screen. Thank you. And I have both the chat and the and the q&a open. And Rachel, I've moved on GitHub versus creating a wiki into into our very last slide. So we'll get to that in just a minute. So randomly generated a coup, trying to add Thank you. Thank you all for participating. This is actually working out well.
Unknown Speaker 49:32
Yeah, much shell pulling this stuff in and real time. I think that's great. What do you see Shall
Unknown Speaker 49:39
I see them coming in? I think we've got about 10 minutes left. So maybe we should go back to the slides and keep working. But we'll keep merging in these pull requests later. And the link to this random Haiku generator is pasted in the chat for everyone to check in on.
Unknown Speaker 49:56
And we'll post that on the on the slack and I'll probably tweet it. That kind of thing with the MC n hashtag. So we'll we'll do all of that, as well. Um, yeah, I think that's great. And and shall if I have a minute, I will.
Unknown Speaker 50:14
If I see any haikus appear in the chat, I will bring them in through my interface. And I'll keep I'll keep pulling them in. So record presentation. Now, I gotta rearrange a Windows wrap up. Okay, let me catch up to you. So today, we, we talked about git, we talked about how GitHub is different from git, and we did that very simple flow. And then I'm really pleased that we brought those all those new haikus in and that, that this is working in exactly the way that that we were hoping it would work live, because, you know, there's always a couple of technical glitches that, uh, that you have to overcome. So I'm sure one of the notes we have here is, how is this working with your, with your non GitHub colleagues at at Mia for, for collaborating on projects?
Unknown Speaker 51:19
Yeah, so as a computer programmer for a long time, I've used Git so much that it just feels like second nature. To me, it feels like everything should always be a git repository. And that's, that's not right. That's not necessarily a good approach to starting a new project. But we have worked on a couple of projects at the Minneapolis Institute of Art with a larger team than just the computer programmers, and had some really good successes. I think I saw Greg in the chat earlier. If you're still here, Greg, our Quire publications are going great. We have a designer who's actually stepped into the role of a GitHub coding digital publication creator. And that workflow has been very successful. We have a few projects that are sort of internal CMS that are managing data and content, where GitHub is sort of it's a quick and dirty, I don't know, maybe not quick and dirty. That's that has bad connotations. But it's a very easy to get going with sort of CMS content management system, where we set up exactly how the files should work sort of similar to this Haiku generator. And we've trained participants in those projects, who are less technical, who are definitely not computer programmers to write and edit this markdown content and manage files within GitHub. And it's a it's definitely a different approach than starting a wiki or starting a WordPress site to manage content. For our main website, we use WordPress and WordPress has so many features that are specific to websites that we probably won't back out of our main website being in WordPress and start editing that content and get anytime soon. But it's worked really well on the projects that we have tried it on. And there are a few projects where we tried it and it didn't work. So we moved the content from those GitHub repositories, maybe back into something like WordPress.
Unknown Speaker 53:31
Suzanna, I'm trying to figure out why you're not seeing the same thing. As I am. Create new files each file.
Unknown Speaker 53:38
Is she on the same? Did she click on the link that the tree link?
Unknown Speaker 53:46
Ah, right. We're running two different links there one, contain three in it. And that takes you all the way to the haikus folder. And one of them is the top, an upper a further up link in the repository. So right now I have let me finish this Add File and that turns into creating a file.
Unknown Speaker 54:10
Okay, I see a question here in the q&a from an attendee with a cultural heritage institution that already has a digital asset management system, use GitHub to archive for posterity the original image and video files for a particular project. What department position in your institution would manage ownership of GitHub? So those are that's two questions. For us. The technology department manages our GitHub we we have a few administrators on our account, some technical I'm one of them and some of our broader staff for billing, handling, billing and that sort of thing. And to the first part of the question, GitHub is probably not going to be a digital asset management system anytime soon. We mentioned earlier that there are ways to submit large, bulky image or video files, you do have to pay for that. And what GitHub is great at is tracking the changes over time in a project. And it can do that for images. If you have an image in your repository, and then it changes when you're looking at it. And GitHub, it can show you on the left, here's what the image was before. And on the right, here's what the images now after it was updated. But I don't think in the scope of a dams that would be that might not be as useful. And if you're talking about putting original image and video files in the file sizes could be prohibitively expensive. Once they get into GitHub. There are some projects that are taking Git and starting to branch it off into that sort of dams like functionality. There's one that's very interesting, that creates a storage system for large files specifically. And so I would, I'm very interested in the possibility of that happening. But right now, that's not what GitHub is really trying to do. So I think that is my answer to the question.
Unknown Speaker 56:20
Cool. And Shall I see that we have just two minutes less than two minutes left? So let's hit our links and resources page, or slide. And we'll get back to that one last question if we have time. But we should also say thank you all for joining us. Thank you shell for for stepping up and helping make this presentation super interesting. And in not very much time. So thank you. For me, in particular, thank you for doing that. Um, Chris, can we will you figure out how to how to move this conversation on to slack? And we'll look for an update from Chris on slack about that. And then we'll, and we'll figure out how to tweet out, you know, a couple of links with it with the hashtag. I'll do that in the next little bit.
Unknown Speaker 57:11
Oh, yeah, I'll create a slack Slack channel for this for this presentation. And you can look, it'll, it'll show up, you can look for it. Give me about 20 minutes.
Unknown Speaker 57:23
Oh, yeah, absolutely. Absolutely. Yeah, I'm just I'm sorry, I'm speeding up because we have a hard stop. Yeah, no, no. Right about 1230. So we will figure out, oh, we're gonna have to save these chats in these Q and A's. And we'll bring those questions forward into slack. Thank you all.
Unknown Speaker 57:41
One last really good question if you have time. reko did you answer that? Well, we'll drop recommendations in the the Slack channel.
Unknown Speaker 57:52
Yeah, there's some recommendations, links and resources on this slide. And we can put more into slack as a useful place for people to go further with this if they're interested.
Unknown Speaker 58:03
Okay. Thanks, y'all.
Unknown Speaker 58:05
Alright. 1230 Thank you.