Training Students in Free Software Development through GNU/Linux ecosystem contributions

This session is a training student in free software development through the uh GNU Linux ecosystem contribution. Uh it's a uh Paulo Mary and David Tadro please talk start. Hi everyone. Uh can you hear me well? >> Okay. So hello everyone. My name is Davidu and today I'll be presenting the talk titled training students in free software development through GNU Linux ecosystem contributions. Um the authors of this talk are Palomidis and myself. Uh you're going to have to trust me that this is me. I look a a lot a lot more adventurous and with short hair and a lot less pale but trust me this is me and we are both from the Institute of Mathematics and Statistics of the University of S. Paulo unfortunately Paulo couldn't be here so I'll be presenting this talk on behalf of us and throughout the talk I'll be referring to my institute as emus which is this acronym so before I start with the actual talk I just would like to give you some quick questions to provoke you don't worry I won't be demanding participation a lot in this talk but I would really appreciate if you actively Think how would you answer those questions, right? So the first one is really simple. Uh what is a good introduction to free software for newcomers? And I say this is simple because given this high caliber audience that I have, I assume most of you have already been confronted with this question. So you probably have an idea of an answer, but in reality it isn't quite as much an easy question to answer. So the next one is what core skills are required for you to succeed in any or at least most free software projects. So imagine that you have a set of skills that if you have those you're probably going to s succeed in most project of course disregarding the effort for you to learn the project specific stuff like software stack or particular development workflows. So the thing is are there core skills like those and if so what are those core skills and finally can we train a group of newcomers through free software and foster core skills while doing it in a relatively short period of time. And this is the objective of this talk to present how we try answering those questions by training students in a university course. And a quick but really most important disclaimer is that we do not argue that our approach is infallible or that it can be universally applicable or anything like this. So the goal of this talk is to only present the experiences we had with this training and also the things we learned along the way. So here are the contents of this talk. First I'll give you an overview of how this training was structured and then I'll go into the details about all the phases of this training and then talk about of some of the resources and the preparation we had to do in order to make it happen. uh we then move on to some of the things we learned. Uh you can can consider those as our results and at the end I'll present some final remarks. So starting with the training overview the first thing is where did it took place. So as I mentioned me and Paulo are from the Institute of Mathematics and Statistic of the University of S. Paulo and this is the building a picture of it. It isn't the most high quality image you've ever seen, but I like the angle and the color. So, this is it. This is what we call IMUSP. But to be a little more bit more specific, the training actually happened in this building right here, the CCSL. And at the end of the talk, I'll come back to it and explain what this acronym stands for. But keep in mind that it has something to do with free software. And in what shape did this course took form um as a one semester uh university course? Sorry, what shape did this training took form as a one semester university course that in our system roughly amounts to four months and the course was named free software development and it its objective was to introduce both conceptually and practically free software to students and do this with hands-on experiences. So the course was composed of undergraduate, graduate and specialist students and by specialist students I mean someone that is neither enrolled as a graduation or as a post-graduation student. Um as in any course we had in-person meetings that were composed of the usual lectures where someone stands in the front of the class and exposes knowledge. However, we focus much more on workshops which essentially go on the other way. So students sat around tables working together in an activity breaking this classical centralized way. Uh some people call this a lab class. So it's nothing too fancy, nothing too new. And the course was divided into three phases plus an initial one. And when did it happen? We actually already had two offerings of this course. One in the first semester of last year and another in the first semester of this this year. So we just finish it and to just give you a landscape of the demographic of the students that we had there were 25 plus students in each offering and if we aggregate those those offerings we got around 75% of students being undergrads. Uh in general the students had really basic skills git skills. So they could do a git add a git commit maybe a git log with some fancy flags here and there and also say push to a remote branch into gitlab or github but they lacked experience with more advanced stuff like rewriting a branch using git rebase or doing good git practices in general. So around 65% of the students claim to be familiar with the concept of free software which is good and by familiar I'm not talking about knowing all the types of licenses or even the four essential freedoms just having a marginal understanding of what free software is. Nevertheless, around 85% of the students claimed to have never contributed to free software. And just a quick spoiler alert uh at the end of the course every single one of them did in various ways multiple times of course as the own title of my talk uh says we devised the course around GNU Linux. So contributions were done in the context of Linux kernel support in to Linux development dist packaging and so on as we will shortly see. So moving on, we're going to dive in each of the training phases, we kickstarted the course with a small introductory phase that was very singular if we compared it with the other phases. So we were much more focused on lectures to expose free software conceptually to students. So even though most students seem familiar with the concept of free software, we had to make sure that everyone started from the same point and had the same knowledge. So we introduced the free software definition by the free software foundation going through the four essential freedoms and whatnot. We then explained the concept of software licenses and the type of licenses in this realm and gave some examples of it. As Git was created in the context of Linux development, we highlighted to show people that even though they may not know or even care about free software, they were using a tool probably daily that was a product of the necessity from a free software project. And we then show the ideas brought in the essay the cathedral and the bazaar from Eric S. Raymond and how he used the Linux kernel to characterize what he called the bizaar model and distinguish it from what he called the cathedral model. However, beyond Raymon using this essay as a way to promote the concept of open-source software and bootstrap the open source initiative that in my opinion maybe I think this is a good great place to say this that it's a way to take free software and strip it from its political stance. He just observed Linux development model and didn't actually participated in it. So this screenshot here is what I found to be his only patch to the kernel, but as we can see, it was only done in 2010. So part of the idea of the course was to take the path that Raymon didn't take and make students actively jump into Linux development. Okay, before we move to the next phases which contain the actual training part, here are some of the common characteristics to all of them. Indeed, we did split the training into phases. So phase one started before phase two and phase two started before phase three, but there were times like phase one activities were happening when phase two or even phase three was still occurring. So workshops were a constant throughout the course and no phase was an exception and mentors were there to support in any way inside and outside the class. Okay, phase one was about contributing to the Linux kernel project. And some of you may think that this is kind of a radical idea considering that most students were complete newcomers to free software and that the kernel is considered as one of the most difficult projects to contribute with many movie parts and maybe some outdated workflows. Right? So if you think this I won't discuss with you. You're probably right. This is and was a radical idea. But as I intend to show you, this isn't a bad idea. So just to ensure that we are on the same page here is a really streamline and washdown explanation and view of the Linux kernel development model. So when we say the Linux project we actually mean this umbrella that is composed of the many sub projects called subsystems. So when you send a contribution to the Linux project, you are not sending it directly to Torvos but to a subsystem maintainer/ community that upon approving your contribution only then it will start propagating it up the hierarchy by sending it to the maintainer above it and so on until it reaches the G repository called the mainline which is the one maintained by Linus and that's represents the official release of the kernel. And another important aspect of Linux development is that it uses email as a medium to propagate contributions which are called patches. So sometimes in this context a contribution is generally called a patch set. So a set of patches related, but even though you can send like a single patch, sometimes it would be still called a patch set. And this is an example of a patch that I sent with a simple code style cleaning. Uh you're probably not going to be able to see what's written here, but the idea that is if you look closely, a patch is essentially a commit converted to a plain text email message with the commit being the subject of the email. And the commit body and code diff, in other words, the actual change as the email body. This relation between a commit and a patch is so real that we can seamlessly convert it into a patch using git comments and vice versa. Now going into the actual activities of the phase uh students started by doing workshops that were structured around tutorials on Linux development. So this went from setting up a testing environment to learning to build and deploy a custom kernel from source to playing with the building compilation configuration and also some basics about character device drivers. [snorts] uh as I mentioned because the Linux development has so many contexts we decided to set the scope to a specific subsystem which was the industrial input and output or also known as IIO subsystem and this decision was wasn't random at all because a veteran IO developer was the one who produced those tutorials based on a set of tutorials from another veteran Linux developer but we get into that and This IO developer also helped us in the last part of the phase which was to actually submit a patch set to a subsystem. So after all the preparation and the learning the workshops all students chose something to work on from a pool of curated issues that included IO stuff but also issues from other subsystems like the AMD GPU and display. However, instead of them directly sending the contribution for the real subsystem maintainer and community, students had to go through a screening step. So, they first send those contributions to us for us to review. And I say, the mentors and the idea was to filter out rough but really natural mistakes that newcomers do and also give students more confidence when sending the actual patch set. So after it was accepted and I say quote unquote accepted because we really didn't try to play the role as the maintainer just to rough out those common mistakes. We gave the students the green light to send it for the real review processes and then they engaged in the real review uh with the maintainers of the subsystem. However maintainer as mentors still gave support throughout all this process. Okay, going to phase two. Uh, it revolved around contributing to a project in the Ginu Linux ecosystem. And what I mean by a project in the Ginu Linux ecosystem is one that is closely related to it or in some sense supports its development. So for example, some of the projects that we pre-selected were Gignome and Git, which if you remember was created by Torvos in 2005 to support Linux, and Kworkflow, which is a developer automation workflow system for the Linux developer. And maybe you never heard of it. So if you are interested in learning more about it, I invite you everyone to see my dedicated talk on the subject on Friday. And in this second phase, we let students loose and stopped holding their hand so much. They had to the freedom to choose the project from the pool of the pre-selected projects, but they also could go around and choose a project for themselves with the only requirement being that it should be related to GNU Linux. And here workshops didn't stop at all but students didn't follow the same journey like in the first phase where everyone did the tutorials and everyone sent contributions to the Linux kernel and they had to be much much more autonomous at this stage. So they had to seek out their own issues discover how to engage with the community they chose to contribute and also to learn the project specific stuffs like the workflows and the software stack. However, with that being said, mentors were still close and available to support, albeit in a more passive way, as the students had to bring the problems that came up from their own active engagement with their chosen project. Last but not least, far from it, uh phase three was about contributing to debin packaging. So in it we had the privilege and also the pleasure to team up with four awesome members of the the Dabian Brazilian community which were Jo Costa which is here in the audience, Akila Medu uh which is here also in the audience. Both of those helped us in the first offering. So thank you guys and also Lucas Kanashir who is here also and Shai Milada who I think is not here but thank you also that helped us in this second offering and to be honest we mentors didn't do much beyond interfacing between them and the students because they completely prepared and conducted the lectures and workshops. And it was was really really interesting because even though this phase was shorter than the others and much more self-contained, they managed to introduce the Debian world philosophy and dynamics while providing great uh practical experiency through software packaging in the context of Debian. So thank you guys once again. For the training to work, we had to gather a variety of resources and space that could house the course activities. So, we needed a place where we could do the usual lectures, but also the workshops. So, in this picture, you see the classroom that we use in its lecture mode. So, everyone is in a chair paying attention to an expository class, which by the way, I think was Joan class on Debian packaging. But for the same classroom, we had portable tables that we could quickly open and rearrange the chairs to create an environment that much which was much more suitable for our workshop sessions. So, as you can see in this picture, probably not so well, but the only uncensored person right here is me uh helping someone with something which I don't quite remember because we mentors help a lot of people with a lot of stuff. But the idea is to illustrate this dynamic that was the core of the course and also the workshops that students gathered around helping each other to do activities counting with the support of us mentors. And speaking about mentors, these were the people who played this part. So Paulo Males, Hafel Pas, Marcelis Pisto, Lucas and myself. But I would like those were actually the primary mentors. But I would really like to bring attention to Marcel Shibich and Hodria as Shimich was that IO developer that I mentioned. So the person who actually devised the tutorials that we used in the first phase and generally helped us in this phase and cicada was the one I call the other Linux developer that made the original set of tutorials from which she built upon. We also had to deise teaching materials. So things like the tutorials themselves, slides, pads and any other reference were used to cover more concepts and the le uh to complement the lectures and the workshops. So for example, this is an part of a pad that I produced that aim to give simple and straightforward guidelines on how to develop a patch to Linux from cloning the right kernel tree to sending patches using git or car workflow for for instance. And to keep track of the progress of students, we used monitoring mechanisms. However, we aimed them for being lightweight as the course was focused much more in having the students getting their hands dirty and experience free software in practical terms. So, we didn't want to overflow students with things like tasks or recurring deliverables. And the two main monitoring mechanisms that we use were blog posts that students had to write that follow kind of a log book format. So these posts were about the things that went right, the things that went wrong and observations in general. So on students also did presentations in the form of quick pitches. So mostly happened before and before the start of the next phase and at the end of the course and probably the most valuable resource we had were the expert collaborators. So people that were specialists specialists in the many areas that we were touching upon like the Linux development itself, GNU Linux distros, Debian packaging and so on. uh and as I mentioned collaborators did many things like prepare and conduct lectures and workshops but also supported as students and us mentors alike. So once again I'm going to take the opportunity to thank everyone. So sorry it's going to be a long thank you but everyone that participated with with us deserves so Melissa Wayne Magalis Antonio Olivera au Joa Alexandri Abidu Lucas Kalashi Charles Me and everyone else who collaborated with us. Uh I think I got everyone but I do apologize if I am forgetting someone. Okay. So before this the start of the training of course we had to prepare the course plan with the phases activities and some of the deliverables yet Paulo always says that the only thing we are sure about a plan is that we're going to have to change it. So a essential ability that we had to have is adaptability. So sometimes a phase would stretch more than we thought it would. Sometimes things would work in a way we didn't expect. So we had to adapt a lot and going to topic number four. So here I present some of the things we learned. In essence, you can see those as our results. But I won't dive too deep in the data and the scientific part of it as this isn't the focus of this talk. So once again, I'm going to promote another talk I'm going to give tomorrow about the scientific part of it. So if you are interested, I invite everyone to see that tomorrow. And the way we got our insights was by collecting and analyzing data from three main sources. The first one was the mentors observations that were recorded throughout the course and after it. And speaking from personal experience after a semester of closely accompanying students, we had a solid understanding of how much they evolved and where they evolved. Secondly, we ran a voluntary survey for the students at the end of the course to aggregate their perspectives in hindsight. So they were looking back to everything they did throughout the course. So for example, some of the statistics that I showed about the demographic stem from these surveys. And the third data source were the blog posts themselves which had data that was much more raw but at the same time more contextualized to when the blog post was written. So by triangulating the sources we find out that we found out that starting with Linux development was indeed a bold move but at the end of the day had many positive outcomes. But I mean I don't get me wrong the first phase was chaotic in both offerings and in the second offers offering we did prepared so much and said oh this time there won't be chaos but chaos came anyway. So uh students have to overcome many challenges like not being familiar with GNU Linux systems or using terminal or CLI tools and there were like many strange problems from setup because we were messing around with the kernel and virtual machines. But at the end of the day, this support that mentors and the collaborators gave could solve mostly all the problems except of course users of Windows Subsystem for Linux, which we didn't help. Now, jokes aside, even in those cases, we help them by convincing them to at least do a boot to a GU Linux system. And this may seem like a joke, but if you're trying to take something out of it uh and try to do something similar like this, we do really uh recommend staying away from Windows Subsystem for Linux. There are ways to do this. But at the end of the day, we found out that it isn't just much worth it to to use it. And we learned that from all this chaos, gin gin Linux and free software in general was much more demystified as students didn't seeing it more like a obscure thing or distant. So they were much more like, "Oh, I thought this would be really stressing and I was scared of diving it." And at the end of the day, they said, "Oh, it isn't much of a trouble." So, okay. But most importantly is that starting with the Linux made students a ton more confident and autonomous to the point that they claim that they felt uh confident enough to contribute to any project. And a funny thing that we also observed is that as the course evolved, they became less and less dependent on us mentors and even started to help the other colleagues. Throughout the the talk, I kept stressing that we focused on mentorship and on-site workshops because from all the three data data points, we confirm that those were paramount for the success of the students and possibly the biggest strengths of the course and beyond that when activities had to be done outside the workshops like engaging with the patch set development of phase one or doing the contributions of phase two. The students that were present in the workshop reported that they found it easier to do the assignments at home. In terms of skills, both hard and soft, we detected that students left the course with a solid foundation of Git and overall good practices and some struggles that I just mentioned like having a difficult time using a G Linux system or interacting with the computer through terminal and using CLI tools were generally not a problem at the end of the course. Um students learned that good communication is key and acknowledged that this skill goes a long way in terms of succeeding in free software as a contributor. But on the other side, they also mentioned that good communication was a desirable characteristics for maintainers and the community in general, which I don't think this is much of a surprise, right? But a curious curious thing that we didn't quite expect it because there were some strange projects that had the requirement spec specifically in phase 2 that had the requirement of being related to Gino Linux. We we detected that the specific skills for the the project didn't matter much in the end because everyone contributed to many different projects and although they had some problems that are natural for you when you are learning to contribute to a project everyone could accomplish to do this. So this is kind of a curious result you can say. Uh and also uh finalizing with the Dian packaging that was much more much shorter and self-contained was really really important because it displayed how free software is all about the community. So the people who are evolving it and maintaining it. So it fixated the idea in students that the most important thing in a project is indeed community and it also gave a comprehensive view of the whole Linux ecosystem as at the end students had experience all the different layers of it and also the concept of a distro was dismystified as it realistically showed how one is maintained and how the choice is taken gave each dro a unique flavor. going to the final remarks. Uh so first how we came up with the idea of the course. Back in 2019, Rodrigo Cicera and other members of Flus did a 10-hour hackathon. I don't know if I can call a 10-hour session a hackathon, but anyway, uh that was called the kernel dev day. And the objective of it was to produce and send a contribution to the IO subsystem. So this simple initiative was the seed that sprouted in what ended up being the free software of course the free software development course that I was showing you. Uh also I emuspy has a long history and deep ties with three software. So the just mentioned flusp is an example as in its own name which is flaws atusp. We can detect the flaws word that if you are not familiar with it it means free li and open source software. So we have an extension group for it. Um there's also the so-cal ginu Linux network which is a computer network that is in production at imus since 1995 and runs debian. So it's it's really interesting and that hosts many services that are essential for the imus community. So for example, all capstone projects are submitted to the gin Linux network and whatnot. And as I promised h at the start of the talk, this acronym CCSL in free translation goes to free software competence center and that is that building inside where our computer department is located and where all the activities of the course took place. And I mean I could go on and on citing some of other examples of this bond between the institution and free software like the Linux install fest that Flu organizes every year to help people test and install Gino Linux in their own hardware. But the point of this slide and the slide before is to give you some kind of a disclaimer that even though our results may be of value, we have the privilege of having this longlasting baggage. So this could be a factor on why we kind of successed uh was successful in our approach. Um just to illustrate to you a bit more how was our experience I'm going to show you a sequence of uncensored pictures not uncensoring this the sense of viewer this question but that I didn't censor the faces of the the students like in the other pictures that I show you. uh this slide and the next ones won't be in the uploaded version. So I think it's just to illustrate to you what the things we were done doing. So, some of photos of the workshop. Uh, here another take of the classroom. Sometimes the room that was this one which was our main classroom wasn't enough. So, we had to occupy the corridors and other places of CCSL and it wasn't uncommon for people to come by to us and say, "Oh, what's going on? What's happening?" And it was a good opportunity for us to introduce free software. So this was kind of a good side effect so we could uh advocate more for free software. Uh here's a picture of Ter and Shala and J also here in the J is coming up a lot in my presentation and they were talking about uh continuous integration in the context of Linux kernel. Another shot of the class in lecture mode. Uh here's Melissa Wayne talking about the work she does at Egala with graphics and GPU drivers in the kernel. Uh here is Magal explaining the work she does at Canonico and Ubuntu. Oh, this is really nice. Uh I think it was the 2023 edition of the Linux install fest. So as you see there are many people here sitting with laptops and we had like a bunch of live boots and installers. So this is like a tradition in our institute. U more workshop photos the main room but empty. And here is where we stashed the tables. So they were really close to us. So we could do like even not only uh workshop sessions and lecture sessions but we could do hybrid sessions in the sense that we started with 30 minutes of expository classes and do the other one 1 hour and 10 minutes in workshops because it was really easy for us to rearrange the chairs and open up the the the legs of the the table. And finally I think this the last Yeah. and Charlie and Kanashi conducting the Debian packaging workshop. And to end this talk, like the previous speaker, I would like to read an excerpt from the freedom by Cecilia Meresh, which was which is one of the greatest Brazilian poets from all time that reads as and I hope I don't butcher it. We are then creatures long nourished by freedom, inclined to sing it, love it, fight for it, and certainly die for it. In short, to be free is to be responsible, to reject the condition of being an automaton or remotely controlled, is to proclaim the liinal triumph of the spirit. I suppose that's what it is. And okay, so this is what I had prepared for today. Uh actually given that I have quite a little bit of leisure time, I'm going to show you some interesting stuff. Oh, that I have prepared. So yeah, this is one of the many patch sets that I just did a quick sampling of the of the some of the artifacts that were produced throughout the course. So this one is from a student that did quite lot of interactions with the maintainers. So they had this is a version six. So they had like many iterations of review and you can see that uh he engaged a lot in reviewing and the funny thing is that he didn't quite really knew what Linux was. He thought it was oh this is the thing that runs on Android right so he didn't quite had the grasp and at the end he could like do a really robust change. Uh another thing uh we didn't just do not there is nothing uh wrong about it but we we didn't just focus on trivial changes. So for the example we had a student that send a patch to reduce duplication and at the end he removed 400 lines of code from the AMD GPU driver. So it was of good impact right? Uh ah here is the the pad that Kanashid and Charlies Meada gave to to us. So they prepare a whole list of packages to people to finalize the packaging. Of course they prepared it a lot for us but it was really nice that they had the this experience of sending a contribution to Davia. Uh we had also a student from the first offering that started contributing to Gnome. So uh he did quite lots of contributions to the point that he contacted the maintainer one of the maintainers of Gome who is George Stravasc which was a Brazilian and he even ended up came to coming to Imusp to give a lecture. So this was really interesting. Uh we also had let me see what was okay. We also had some bad experiences like toxic behavior which I won't focus too much but just to show you that it all it ain't all just roses right because this was an example of a student interacting in a issue. Let me see if I go down here. We're like, oh, no one's willing to fix, but I don't really want to focus in it. But just to show you that's all always the other side, right? And for example, all of these closed uh pull requests were submitted from students in the phase 2 to K workflow. So yeah, we we had quite a a var variability of things we did in this course. But yeah, this is everything that I planned to talk. So thank you so much for the attention and I'll be open for questions now. Thank you so much. [applause] Hi. Well, uh Oh, thanks. Erh. So, well, congratulations for this work you're presenting. It's very impressive. Erh, one thing that well, you know, we that work at the universities, the first things that jump to my mind is the administrative bureaucratic health that we often have to traverse. Uh, was this course a course granting credits? How do you manage to have a course with both undergraduate and graduate students? And well, how how was that part? we have that as a complete separation and it's well very very tough to propose something like this. >> Well actually funny enough it is quite common for in my institute for us to have courses that mix like uh under undergraduate graduates and especially students alike. So this isn't really uncommon for us in the sense that I would say in the bachelor's of computer science which I've done I would guess that 30 or 40% of the courses are hybrid in this sense. So this wasn't much of a problem. Uh but yeah, we did kind of a really specific thing with the evaluation. So we didn't have tests. But this is a specific part that you asked about mixing graduates and undergraduates wasn't quite a problem. It was it is quite common in our institute. Yes, >> if I can follow up. I know the I know the institute. Um the thing it's as if it were two different courses. Uh in the graduate level they required to present more like for the university perspective. It's like they have different evaluations. So the level of an undergraduate the how they are evaluated is one way and the graduate are evaluated in another way. So you could have two courses but they actually run on the same space. >> Right? >> And it makes sense. everyone benefits but at the end it's as if they were different courses. >> Yeah, thank you Ta. I think uh she answered better than me because this is the reality. We do kind of the same activities but uh in those courses it isn't also common for people from the postgraduation to have to do uh more robust things. They don't have the chance to uh fail and do a final test to recover. So although courses are mixed up, yes indeed at the end of the day it's kind of two courses in parallel having the same class sometimes even splitting classes. So yeah, thank you to because I didn't answer it right. So you talked about um [clears throat] so you talked about workshops on site. Um, so were the students partially in their homes or or across the country or how was the setup there or were they permanently resident around the university and could attend in person most of the time? So what was the setup there? Yeah, that that's kind of a limitation because we didn't were like uh too much strict in the sense that you should be here in every workshop but uh you you needed to be present in at least like 80% of the classes. So yeah, we people had to be present in person. Uh now that you mentioned it, we can we could adapt it. But one of the things that I'm also going to talk tomorrow is the importance of this in-person workshop and whatnot is to create kind of this simulated community. So people sitting around tables much like that camp, right? So it can work uh not only uh distributed with people doing uh meetings and and other stuff but also asynchronously. It could happen but I feel like it loses a little bit of the purpose of the c the course but yes this is kind of a limitation of it right. Hi. Um so um uh we discussed the course before and I it's really intriguing and surprising to see the opposite end of yeah we maybe let's not go from the shallow depth to a deeper thing and more so learn like learn more of the technical aspect of it. What really interests me? Well, what is my concern or well my focus is did people do you think uh like I remember you mentioning something about some people from this course eventually switching to Linux distributions full-time or learning to actually use their systems to more full potential with uh other free software. Do you think that other parts of people's life also changed? Like I in one of the slides I believe uh of a screenshot of the pad you had prepared. Um there was a screenshot of there was a contact information for you and it was still like a telegram handle. Uh yeah this one. So like it's good to see it's a pad hosted on rise up which I appreciate but uh it's not like a Google doc or something but I think uh I would like to inquire like do you think people changed their social habits like did people communicating over emails for the Linux uh development actually changed to start using emails for uh their personal stuff? Um, I wouldn't say that it was uh too much impactful in the sense that people that were just accustomed to WhatsApp and other messengers started like using IRC or email so much. But I can give you an anecdote for someone that quite analogously with the one who didn't actually knew Linux. Uh that uh she didn't quite understand how email worked. So because patches are sent through email in in the kernel, they must be plain text. So some uh email clients like Gmail and whatnot, they don't quite render well. So she was saying like oh this maintainer is answering me with blank reply I can't see the reply and then we say oh we have to teach people to go and click with see the original m format right and I can tell you that it mutated a lot in this sense but for sure people started to using Linux and it became kind of a joke that uh in the final presentation or during some of presentations when people said oh I never used Linux we started learn using Linux everyone applauded so one more one more to the team so yeah this is it but to answer more shortly yeah we had kind of impact but in the sense of using email and whatn not I can't tell you for sure right >> time's up oh I have time okay so my question is um you mentioned that the phase is the different phases overlap. So what why why was that? Uh I missed the detail. >> Okay. No, the thing is because uh the final part of the phase one phase one lasted around two months in both offerings. So the last two weeks we had also workshops but they were much more focusing oh see this pool of issues and try to contribute it to and after the two weeks we started phase two. So there was some buffer time for maintainers to reply and also to uh say maybe the review was this is good but change this a little bit and the people changed it and the reviewer or the maintainer lasted a week or so to reply again. So there were times where people were still working on a contribution that was started in phase one but ended around phase two or phase three and the same goes to phase two with general contributions. So we had times where the pitches for say phase two contained updates from phase one. So they kind of over overlapped in this sense but the activities were yes they were containerized in this sense. Yeah. >> Thank you. Okay, this is the time is almost up and uh uh thank you the do session. Thank you.