Sustainable Growth of Global Communities: R-Ladies' Next Ten Years

Transcript#

This transcript was generated automatically and may contain errors.

October 31st, 2012

So, hello everyone. October 31st, so probably if you think about this date, you will think about pumpkins, candies, or costumes. But October 31st is also R-Ladies' anniversary. So, the first ever R-Ladies' event took place in San Francisco on October 31st, 2012. So, this means that last year's was R-Ladies' 10th anniversary. Happy birthday!

So, if you're here, you probably already know that R-Ladies' is a worldwide organization that promotes gender diversity in the art community via meetups and mentorships in a friendly and safe environment. But it started small. Only eight people showed up to the first event. It was Halloween. But today, we have 231 chapters in 63 cities, and we have organized almost 4,000 events.

So, this means that the past 10 years have been years of growth. And this has been possible thanks to the work of people organizing chapters around the world and R-Ladies' that engage in social media, in the Slack community, and in the different initiatives that the community organize. But it has also been possible thanks to the work of the global team, the people that help us to maintain and develop our technical and social infrastructure.

So, our 10th year anniversary was also a moment for farewell. Claudia, Erin, and Hannah stepped down as organizers. Thank you. They led us through 10 years of growth.

So, a new leadership was needed. And there's always people that fell into this kind of task. So, these are the five people who decided to engage with this. So, we have Mo, we have Avery, Yanni, Shannon, and me, Riva. And that is why we're here today, to talk about how we're envisioning R-Ladies' next 10 years. And what we're thinking here is about how to sustain the community. How our efforts can work towards sustaining the growth of this community.

Good programming practices for community management

So, we're people who love to code. And we were thinking in the last year, what if we use good programming practices to manage our programming community? For example, modularity, refactoring, and testing.

So, what about modularity? You don't want a function that is that big. What you want to do is to make it in small chunks, so it's flexible, you can maintain it easily, and you can develop new features. So, what about communities? You want to do the same. But this is about workload, obviously. You don't want just one person taking all the work.

But it's not just about workload. There are other things involved. For example, if you have a team that's working on their website, and they're only working on their website, they don't have to take care about other tasks, they can focus their effort on feature development. So, making your website cooler.

And it's also important in terms of participation, because not everyone can engage as an organizer or as part of the global team in the same way. Not everyone has the same time patterns to commit. For example, you may have some volunteers that have three hours a week that they can devote only on Friday afternoon. But you have other people that prefer to work on small chunks of time. So, they can maybe go to the computer two times a day and work there around 10 and 20 minutes.

So, if you have a community that can offer people different ways to engage, they can be part of the team and help you and all your community with the work. And there are some tasks where you need people that have these time patterns. For example, you want someone moderating a community that engages not just one day, three hours, but that's there many times a week.

This is also important for the ways that people can participate. So, sometimes you want to participate in a community for learning new things. So, if you want to learn how to code, more about coding, you might want to participate, for example, in the website team. But if you want to, I don't know, engage in things that are related to social skills, maybe you want to be part of the mentoring team of our ladies. So, this gives space for everyone.

So, one thing that we are for sure going to keep working towards is have a modular global team. So, this can help everyone to participate in meaningful ways.

Refactoring workflows

So, what about refactoring? Sometimes you have code that works, and we want to keep it that way. We don't want to touch it. And the same happens with projects. So, sometimes you have a project that you really love, you really care about the vision of that project, and you really don't care the kind of work that involves to keep the project alive. And that's because you have the vision of the project in front of you. So, you're really committed to that.

But it's good to think about how we can refactor our workflows as community organizers to make everyone participate in meaningful ways. So, refactoring your workflows is not only about making your community more efficient, but it's also about making the time that people are committing as volunteers in your community more meaningful. Because you don't want people committing time that can be, that's only about repetitive tasks that can be automated. You want them doing relevant things.

So, refactoring your workflows is not only about making your community more efficient, but it's also about making the time that people are committing as volunteers in your community more meaningful.

So, as an example, we can explain what happened with the R-Ladies directory. So, the R-Ladies directory is an initiative that's very related to R-Ladies mission that help us showcasing what R-Ladies do around the world. And it's an excellent antidote to all my panels.

So, for example, in the directory, you can learn about, for example, if you want to engage someone in Botswana that know about computer science, there's Simi. Or if you want to engage and know someone that's working in open environmental science, there's Julia. Or you want to know people that are working with R in ecology, you can find Benedicta. Or people that are working in health equity, you can find Sylvia on the directory.

So, the directory, this is how the directory used to look on the webpage. So, to add your entry to the directory, you can, there's a form there that you can use. And there used to be this message. If you want to update your profile, just fill the same form and drop us a line in the comment box saying you want to update your profile. And there was this extra option. Or you can just email us at speakers at rlates.org with any relevant information about yourself. Easy. Yes, easy. Because the project was starting, and what you wanted was people sending their data so you can showcase them in the directory.

But what happens behind the scenes with this workflow? So, you have a spreadsheet, and people start submitting their entries. And you have to take this information and put it on the website. And you work in these two entries. So, you're going to put a color to remember that those are already on the website. And you keep working. And then this one is not really well, so you're going to work in this one afterwards. So, you put another color in there. So, you remember that this one has a problem. And you keep working. And then you realize that this entry, in the comment they put this is an update, so you have to treat this one differently. And then an email arrives, and you have to take the information from the email and put it here so it can go to the directory.

So, this workflow worked. So, it worked for years. And it could have kept working. But it has some problems. It's difficult to maintain. There's a lot of space for human error. So, you don't want someone submitting their data and you not uploading it to the directory. You can schedule the work. So, maybe you decide that you want to work on the directory on Fridays, but you receive an email on Monday, on Tuesday, on Wednesday, about people wanting to upload their data. And because you're only working on maintaining the directory, you can think of feature development. So, how to enhance what we have there. And this is a task that has a high risk of burnout.

Because what the directory does is really awesome. It helps showcase what our ladies are doing around the world. So, maybe you don't care that it's a repetitive task, copy and pasting information to the website. But things happen in life. And sometimes, under certain circumstances, you're not seeing what the bigger picture is. And you realize that you're only copy-pasting information and don't understand why. And this is like the perfect recipe for burnout.

So, last year there was an opportunity. Mo was leading the team to turn our website from WordPress to Hugo. And this was an opportunity to think again about the workflow that we have for the directory. To think in a way that people can work in it, and it's meaningful, and we can end with the same result.

So, we still have a form. The form is there. People still submit their data through a form. But now we're working with our table. And now people choose an option. That's a parametric site. If it's a new directory entry, if this is an update, or they want to delete their entry. And now we're using GitHub Actions. So, GitHub Actions are a way to automate the workflow of taking the data from the form and moving it to the website.

So, basically, in the directory repository, we have a folder with our actions. There's the workflow. There are a lot of workflows. But one is about updating, taking the data from our table and moving it to the website. This is a glimpse of the workflow. But what's important here is that it runs on Friday. So, it's scheduled. So, people in the team know when the data is going to appear in the repository.

So, basically, what the workflow does is that it takes a couple of R scripts that get the data from our table, that validate the JSON files, and then the action create a pull request. GitHub Actions allowed you to customize the commit message, the branch name, the labels that you want to add, the title of your pull request. And the experience of the team at the end is very different because in the previous workflow, this is what they were dealing with. And now, on Fridays, a pull request appears with all the data ready to be committed to the website.

So, now the task, the focus of the task is on the review, not in copy-pasting. The task can be scheduled, and people have time for planning features for the website. For example, how to filter the entries that are there on some other awesome stuff that the website and the director team are always thinking about.

So, refactoring workflows is an opportunity also for learning. So, we like to solve problems using code. So, refactoring your workflows is not extra work, but it's work that probably people in your community will want to be engaged with because they're going to learn something new about programming.

So, if you want to be in next Friday's pull request, you have to go to ourladies.org slash directory dash update, and your entry will be updated.

Testing workflows through onboarding

So, a way to discover that your workflows need a little bit of refactoring is testing your workflows. So, we always want to ensure that our code behaves as expected. So, we want to do the same with our workflows. We want our workflows to behave as expected.

So, I'm going to tell a little story. I became part of the global team two years ago as part of the Slack monitoring team. And this is a task that I jump into very easily because I was already a person who was using Slack. I know how the code of conduct of our ladies work because I was an organizer. So, it was very easy to me to know how to perform this task.

And a couple of months later, there were people needed for the meetup team, people who manage the meetup accounts of all the chapters. And I fell. I wasn't able to successfully start doing this task. And I was wondering why, because there's very good documentation. So, there's all the goal of the task, all things that a meetup account manager needs to do was very well explained. But I didn't know how to become the person that can use the documentation. So, there was a gap between me and the documentation that I didn't experience when I was working in Slack because I already was familiar with that.

And I discovered that the problem was not with the technical infrastructure, but with the social infrastructure. So, for example, to use that documentation, I needed some credentials, but I didn't know who I need to ask for the credentials. And the person who gave the credentials didn't know that I was in need of them. So, we were basically testing in production. And the problem of testing, this is absolutely valid, you can't do this. But the problem of testing in production is that in some cases, what happened is something failed. And in this occasion, with perspective, I know that what failed was the workflow. But at that moment, I thought that I was failing because I wasn't able to complete the task that I was expected to do.

But at that moment, I thought that I was failing because I wasn't able to complete the task that I was expected to do.

So, designing onboarding processes can help you to test your community workflows and documentation. This is an excellent way to realize that the way that your workflows are working is what you expect. So, this is very important. This is time you want to spend in.

So, I'm a serial volunteer. I'm very good at jumping into volunteers' positions. And there's another project that I participate in that's called Programming Historian, where we publish tutorials about computational tools for people in the humanities. And in this project, we have an onboarding process that's basically opening an issue and saying people how to engage with the project. We have very good documentation. So, all the tasks that people need to know are there. But we onboard people because we need them to become the person that can use the documentation.

So, in this issue that we open, we welcome people because we're nice. We explain what the project will do, what the programming team will do to onboard you. We explain people what they should do to be onboarded. And that allows us to people becoming part of the team with no problem.

So, at Our Ladies, we start designing onboarding processes. This is the first one where we try to explicitly mention the task. It has three hearts. But this first version has a very complicated problem. We hard-coded things. We hard-coded people's names. And you never hard-code people's names on your documentation. Because, for example, last week, we discovered that Hannah was stealing our documentation. And people were going to ask her to create GitHub repositories. And we want Hannah working on tidy models, not creating repositories for other people.

So, now we are improving our onboarding processes. And now we only mention teams because it's easier to maintain. So, every time we onboard a new member, we discover new ways to improve our documentation and our workflows. And we're going to keep working on that.

So, obviously, we ask ourselves, what if we automate part of the process? So, now we have a GitHub action that we dispatch it by running our workflow manually. And what we do is that we put the team that the person is getting onboard, the name of the person, and their GitHub handle. And when we run this workflow, what is going to happen very fast is that it will take our issue template. It will take the information from the inputs that we put there. We will get the user ID, check if it's already in our organization, invite the user to the organization, wait for the user to accept the invitation, add the user to the corresponding GitHub team, combine the templates, and replace placeholder, and finally create an issue to welcome someone new to the global team. So, that's all you have to click some buttons, and the template is there.

Takeaways

So, as we said before, we love coding. And in this past year, we've been thinking how we can use these good programming practices to improve the work that we're doing at Ladies' Global. And the takeaways here is that designing a model community is a good way to distribute work, and to distribute work in a meaningful way. Refactor your workflows. It's important to avoid repetitive tasks. And on the long run, make your process easier to maintain and avoid burnout. And creating onboarding processes is a good way to test your technical and social infrastructure to keep all your processes run smoothly.

So, let's bring the joy of programming to our community management, and hope you can take some of these ideas and put them in practices on your own communities. Thank you.

All right, Reva. In the last 30 seconds, can you say anything about how you're handling knowledge transfer as you're going through leadership transitions? That's a very good question. So, a couple of years ago, the Art Consortium helped us to finance creating our Ladies' Guide. So, we have a knowledge base that is available for everyone. So, the transition, so in terms of knowledge about the organization, we have that as a knowledge base. So, I think the most difficult things have been like bureaucratic things that are involved in an organization like that. Banks, for example. Banks. Okay. Fantastic. Let's thank Reva again.

Sustainable Growth of Global Communities: R-Ladies' Next Ten Years - posit::conf(2023)

Transcript#

Good programming practices for community management

Refactoring workflows

Testing workflows through onboarding

Takeaways