Molly de Blanc – Gitlab for Collaboration Beyond Code

I now have the privilege of introducing Molly de Blanc. Molly is a strategic initiatives manager with the GNOME Foundation. She works with GNOME and their open source software to coordinate and collaborate on a lot of different things.

And one of the things Molly's passion to share is how GitLab is not just a technical tool, but it's just a collaboration tool all around. Let's check it out. Hi, I'm Molly de Blanc.

This is "Collaboration beyond code". You can find me at Twitter @mmillions or mdeblanc@gnomeorg. So if anything comes up during this talk and we don't have time during the Q&A, you can email me afterwards or tweet at me and I'll respond as best I can.

So I'm the strategic initiatives manager at the foundation. I work on partnerships with other organizations, I do activities along with our friends of GNOME program, And some other initiatives that we have going on. I work with the advisory board, which is super awesome, and you should probably join it.

So I work at GNOME and I like it a lot. I have other credentials, too: I am a web developer, I work on the the community team and I also do some stuff with the outreach team. The community team does Code of conduct response and enforcement and the outreach team works on doing internships with programs like Google Summer of Code and Outreach.

I used to be on the Open Source Initiative for directors where I served as president and in general I've been hanging around free and open source software; I've been using free and open source software for less time than I've been hanging around it, actually, but for quite a while now. One of my favorite pieces of software is Git, and I'm here to spend a little bit of time talking about Git and GitLab, and I want to talk a little bit about my history with it. So when I was in college, I, I used to have files with names like class name, final class name, final final class name, final two dash one dash final, which is to say is a very complicated way of saying I tried to take a facsimile version control by deceiving many files again and again.

Copying and pasting all the content and working with them that way, which might have been. Technically easy, but was very inefficient. So one day I sitting here with my friends who are all statisticians, economists and history majors and talk to them, and they were talking about using version control to write their papers.

They also all use latex, which I was not using at the time, and and I had no clue what version control was. And they explained it to me and they explained that there was this way to take your papers, that you were writing to save them as they were to kind of store them. And then any major changes you made, you could just add onto that.

And if you made a major change and you didn't like it anymore, you could go and check that out, which sounded super cool to me and really useful, especially because it made it a lot less scary to do things like delete giant chunks of text, which you might want to do, and I frequently wanted to do. So I tried to use git and I found it incredibly complicated and proceeded to not use it again for a very long time. Later on, after I moved to Boston, I was basically the office manager for a little bit for Ksplice.

Mostly what I did was the books and ordering and some paperwork stuff about how the company is interacting with the state. And they use git for their finances so that we could revert changes if any mistakes were made and also we could store locally and on a server, which seemed really cool and made a lot of sense. So I memorized a list of commands that I typed into a terminal.

I, I kind of knew what these commands meant because I understood basic things about how computers work, and I could grasp the concepts of what things like "pulling" and "pushing" and "committing" might mean in this context. So I memorized these commands and I actually still use the exact same workflow. Just I have a much more nuanced idea about what that means at this point.

After that, I had another job at a tech nonprofit where we did all of our work, almost all of our work on wikis, and you could either modify the wiki directly or you could have it stored locally and work on it using git... Work on it and then you git to like push and pull things so that they would go up to the server. And I'll talk a little bit more about that kind of dynamic layer.

And all this is to say that I have been using git in some capacity regularly for a long time. And I actually, during this process, started using it, do my own work as well. I do a lot of writing for fun.

I write scripts like not like scripts, but like comic scripts and film scripts. I do a lot of fiction and nonfiction writing. I write a lot of essays.

And I found it useful to use version control to both keep track of how it changes, but to use it also as a way of backing up my writing and ideally having access to it in different places and from different machines and being able to kind of transfer where I'm working without having to give up what I'm working on and having a canonical version of it. So when I learned that GNOME was using GitLab, I was like total plus one. This is awesome.

Like I get to use this thing it's going to be great. It's totally going to make my job easier. And, you know, at the same time, Debian also uses it.

So I was like already familiar to some extent with the GitLab interface. So for me it was like really cool. And I like that.

This is where I say I don't like the title of this talk, and it was actually suggested to me very generously that I was allowed to change the title of the talk, but I wanted to keep it because I wanted to have this slide, not only because Mandarin books are pretty, but because I think the way my experience using version control is framed is, I think, very useful to consider when we think about what it is. Version control... We, you know, we default talk about it as this is how you write code these days.

This is how you write code now. I remember hearing some anecdote once about these two guys in I think Texas who drive like hours to meet each other in the middle of Texas or somewhere in that part of the country to exchange disks of code that they were working on together. Well, we don't have to do that, and people don't have to do that anymore.

But for me, using version control, using git was never about code. I don't write code. It's been about issue organizing, it's been about sharing responsibilities, it's been about collaboration and connection and working with people all over the world, which is really cool.

And version control has enabled me to do things like writing collaboration and sharing things I've written. I've worked with documentation. I've worked with design documents and annual reports and all sorts of different kinds of things.

So I don't like this framing that we need to think of it and GitLab as providing resources beyond code because we should just be thinking of it as this resource and collaboration tool in the first place, regardless of what your needs are. So I want to talk about GNOME and provide some examples of specific things that we do and specific things that I do using it. This is going to provide a few recent examples of things that I've worked on in the past few weeks, few months, a few weeks to hear references to wants to just give you a general idea of things that we do and that I've done.

And this is by no means comprehensive. And I hope just kind of gives you gives you some inspiration for things and how to use tools you might be using in other ways. So this GNOME's, this is from the GNOME annual report the GNOME Foundation annual report.

These are pie graphs. At first I was really confused about them being pie graphs because the center is don't have pie slices, but they're pie graphs. They might have a term like circular pie graphs.

Anyway. Not relevant right now. The point is, these are examples of what kind of work is being done with GNOME and on our GitLab instance.

We host our own instance, which is super cool. So we get to do all sorts of fun things with it. So this is some of the stuff.

These are mostly, but not all technical and coding -- I should say coding. They're mostly coding contributions. This highlights who some of the top committers are, and it's like people who do lots of things.

But in that big blue section on it, which is the biggest section in case you have trouble seeing the color blue, the big blue section is the the everyone else. So that includes things I've done and things people have done that doesn't that don't involve writing code. So lots of cool stuff is happening that has nothing to do with code.

Let's talk about it. Trip reports with repos. So we write when we go to a conference, and this is something I would say that the foundation does a decent amount of.

We write trip reports when we get back. So trip reports cover all sorts of things. There are there's information to create blog posts.

There are there's a space to share photographs. There are links to coverage. It also includes information about if we ran a booth, if we talked with the responses to those where there's a little template.

And one of the things that happens is sometimes only one of us goes to a conference, but sometimes we go to a conference with volunteers and we have, like I should just say, volunteers, volunteers and contributors, people who are super involved with GNOME, people who are like these huge integral parts of the project. Because GNOME is people as we like to say. So we have these trip reports and let's say let's use them as an example FOSDEM is this big conference that takes place in Brussels every year in February, which is the best time to be in Brussels?

I love it so much. I wrote a song about it once. And so when I write a report.

Especially in a case like that, it turns out that there are multiple people who have things to say, we have multiple stakeholders in what happened. So what's cool about doing something with version control and with GitLab is because we have this piece, like we have this thing hosted in a place that's outside of our own computers. I don't need to pass my report to Rosanna, our director of operations, or Carolina, brand manager, or our programs coordinator.

You know, it's just in one place. Everyone has access to it. Everyone can modify it.

We can do it asynchronously. We can read it at different times. We can work on it on our own and then deal with multiple changes if we change the same sections.

So it's really cool to have this way that we can all work on something at once that's less laggy. And that doesn't require actually emailing a document to each other and trying to keep track of where or what the canonical version is. So I think that's pretty cool and I found it super useful.

Conference organizing: we just had this conference called GUADEC. It was awesome, super fun, highly recommended, videos online. in GitLab was when I was passed one that said "pick keynote speakers".

And that was the issue title and there were some, but there was like a deadline on it was assigned to someone. But the comment section was the big thing. And in the comments section, you we were just like listing names of people and information about them, people who we thought might be good keynotes and really have something interesting to add to the conference.

Now, once I dug a little deeper into this, just out of curiosity, at this point, it turns out that there were all sorts of issues for all sorts of different parts of the conference organizing process. And, you know, we had things like "design a logo". We had things like, you know, "figure out about T-shirts".

So so most of the conference was to some extent being organized with issues. One of the things that I mentioned in the description was some things we'd like to have happen. And I think we really great if we could assign an issue to multiple people and apologies if you can already do that.

But I didn't see that functionality earlier today when I was working with it. But that would be super cool. So we.

I have been using it for a lot of different kinds of organizing just beyond the conference as well. Earlier today, I made a bunch of issues for the Diversity Inclusion Team, which included things like update this section of the wiki, like organize the time for the next meeting, figure out when this other important thing is going to happen. So it's become a pretty integral part to how a lot of processes are being done, where we're going to try out using it for our publications calendar to keep better track of when we want to have things published up on our Web site where it's going.

Is it going to the engagement blog? Has it going in the news section? Maybe social media, we're still discussing that one.

But trying to integrate this in the same way someone might use Post-it notes. This is not just relevant because everyone is currently working from home because we're in a global pandemic, but also, you know, GNOME is a tiny place from a foundational standpoint. There aren't many of us and we all work in different places.

And we don't just work in different places like, oh, there's some people in California and there are some people on the East Coast. But the whole conference organizer, Christie she lives in Albania. And I spend a lot of time trying to talk with my boss, which I'll talk about soon, actually, who lives in England.

So. With our small team in different places, being able to share, you know, share issues like one would share, you know, students organizing, it's really handy and it's really nice. And it's also useful because you might not always be able to talk to someone in real time when you're thinking about a topic or when you're thinking about something that needs done.

So you can just make an issue for them and pass it to them. And that's great. I like it.

OK, fundraising wiki. I love wikis so much. I understand that not everyone loves wikis.

I understand that a wiki isn't always the right tool for your problem, even though I hope it is always the right tool for your problem and sometimes act like it is. Wiki's: Really cool. So on our wiki, we have a section for fundraising and certainly the section is divided into different parts, which each of which covers a different aspect of fundraising practice.

So we have a list of grants that are possibly of interest to the project. We have a list of projects that are things that likes very specific things that grants could be that could that could do with funding that would make a difference. We have we use other tools for some other things, but we have all these sections that people can work on.

And we have in addition to that, like all sorts of other documents that tie into this process. Now, what I've done is I've clone the repo for local access, meaning I can work on it on my own computer regardless of where I am, and regardless of whether or not I have Internet access and then push it back up later. I find this a super useful because sometimes the Internet is really distracting.

And also, at least prior to recent months, I spent a lot of time on airplanes or trains and I was able to do lots of work and work on this on my computer, even if I didn't have Internet, which was great and is great for many people who have issues with connectivity issues or they don't have a lot of bandwidth and like their Internet access is pretty low speed. So one of the things I really like about it is that there's private public functionality. So we use it, we use our GitLab instance for lots of different kinds of things.

So I have a private fundraising repo that I work in, which is mostly reports and documents. So one of the things that's really useful about the reports that are ready for the public yet. I think so far we've shared everything at the right time when things are done.

And this is really useful in part because my boss, as I mentioned, was in England. So sometimes he wants something and I am not around to give it to him and or he needs to he needs a change to be made to something in a timely manner. And I'm not around to do that.

Sometimes it's really nice to just be able to share what, like something that's a work in progress so that you can get feedback and as you develop it. So that's really cool. It's really great that we can work on these things with private repos and we can work on these things in public repose and have stuff going on at the same time and then move things between different sections of the of of of our GitLab, especially if you store it locally.

And then it's as simple as moving files. Cool. I'd like to move more of my work to GitLab, actually.

I have some things that are in different places around my computer. I have some stuff on nex cloud. Some stuff I'm not going to be able to move to git, but I would like to because it rests in like CRM software.

We use it for management of different projects we work with, different keeping track of who's gotten what emails, so, you know, not everything can go there, but I'd like to put more of it there. And one of the reasons I'd like to put more of that there is to break records and for succession planning. Succession planning is super important.

I love my job, but I also recognize I'm probably not going to be doing it forever. And then at some point someone else is going to. So it's really great if I have this record of the things that I've done so they can see what's happened.

And like, if you're good with writing comments, it's even better like comments as in commit messages. If your commit messages are like really thorough, that's super awesome because then you can see what you were thinking about when you left off something. But also the next person or somebody else you're working with at the same time can see what you were thinking about and respond accordingly, whether that's like right now or whether that's in the future when you're no longer around.

That being said, socializing tools is hard. You know, I love git, as I've said repeatedly, but it's not always easy to get everyone to use it. It's not always easy to get someone to use a technology in general.

If you if any of you are working on a project that uses IRC or mailing lists and regularly has conversations about whether or not you can still use them, I would recommend raising your hand. I can't see you raising your hand, but I'm imagining like a sea of people with their hands up in the air and it would raise my hand at this conversation point. So getting people to decide to use something and to agree to doing it and to become comfortable with it is not an easy process.

Right. It's you know, anything I do in git is accessible; this is like a cool reason now; anything I do and get around the GitLab is accessible by my team, whether that means my foundation team, whether it means the diversity inclusion team or other teams I work with in the GNOME project, it's still something everyone can see, which is really great because again, I don't need to send files to everyone. We can work from a single canonical document, and that's super cool.

The downside to to to things being accessible is not everyone's comfortable. If you remember at the very beginning of this talk, I mentioned how I decided it was too hard when I first interacted with yet, but that's different now. I understand, though, that still not everyone's comfortable with it.

And I think like a good user, interfaces make a really big difference. I think that a lot of user interfaces could be better designed for people who don't come in with extensive technical knowledge and a comfort with these tools. It's easy to review, collaborate and audit things so everyone can see stuff at the same time, but sharing your work is really scary, right?

Whatever you're doing, like even, you know, either a lot of confidence in some of the work I do, but I'm still scared every time I share something. I'm scared of people not liking it. I'm scared of having made a huge mistake and I'm scared of it like just being bad.

So that's something that we can that like that's an US problem, not a technical problem, but it is a real social problem. So we need to think about how we create workspaces that are comfortable for everyone where sharing your work is like not scary but exciting. And you're going to get like everyone's going to be really cool feedback and you're going to learn lots of stuff and you're going to feel good about yourself.

And that's the thing that we can work on. org And you can see what kind of stuff we've been up to. So now there is some time for questions again, you can email me or ask me on Twitter or ask right now, so thanks.