 Hello everybody. Welcome to our very first LFX mentorship showcase. So my name is Shwakan. I am Cardinal Maintainer and Linux Fellow at the Linux Foundation. In this role, I get to learn, continue to learn and share and then also, more importantly, enable others to learn and share. So that's really awesome to be able to do that. When we start learning a new area or starting a new wanting to learn a new project, we're all faced with the same problems, all of us. Where do we start and what, first of all, we have to figure out which project we are passionate about, right? Which project do we want to contribute to, which of the open source projects appeal to us. And after that, we're trying to figure out, well, hey, how do I get started with it? And then next comes in that where do we, where can we find resources to be able to start our learning and start contributions? So once we learn enough of the project, we're wondering who is there to help us? Can I reach out to one of the community members and ask a question? Do I have, can I ask intelligent questions even? We're unsure when we are starting out. So at the Linux Foundation, we have several resources for you to be able to go explore your learning paths on the Linux Foundation training site. And then you can not only explore your learning paths, you can also take free courses and explore training options. And then another overview for you is listening to experts speak about the areas, several areas in ranging technologies, software engineering, open source, criminal specific topics in LF live webinars. So you can do that. And then once you have that idea and you go, okay, I want to take my learning to the next level and work directly with mentors when you can apply, take advantage of the Linux Foundation mentorship program and apply to one of the projects to be able to work with your the mentors directly. So now, say you applied, you graduated, you completed your program, what's next for you? This is what we are doing in, in terms of connecting you, connecting the graduates to with the, oh gosh, connect, connecting the graduates with our employers and employees looking for, employers looking for new talent. Sorry about that. I don't know if you saw the something technical glitch looks like on my desktop. Okay, so this is the next step we have here in terms of connecting our new graduates with people looking for talent. So that's where we are. And first of all, I want to acknowledge and our mentors without them, our program is not possible. So we have next up will be, I'll be handing this off to our graduates to speak. And Peter, you can go ahead and start your presentation. I'll stop sharing now. Okay, so I will begin now. Okay, so hello, everyone. My name is Peter Pawlowski. I'm from Poland. I'm 22 years old. I'm a third year computer science student in Kraków. How I got here? Well, my mentor was my, well, was teaching me at the uni. So he told us about the whole thing connected with mentorship. And I sent my CV. And now I'm here. So you can see me. Okay, I was working with Hyperledger Iroha. Hyperledger Iroha is an open source blockchain made by Sora Mitsu and then made open source. It differs from other blockchains because it has no default support for smart contracts, for example, and it uses a set of predefined functions to modify the ledger. Well, so my task was to modify the queries. So modified client libraries to enable the new queries or modified queries rather, and to modify the internal database querying. Yes, and it was planned to add about five pull requests, modify docs, provide examples, and may whole think available for other people. Yeah, there are some technologies I have to learn in order to get things done. Iroha uses protobabs for communicating with clients and for internal communication. It is written in C++ main code, and it uses Go for Barrow integrations, and Barrow enables us to use Ethereum virtual machine in Iroha so we can execute some smart contracts code. Also, it uses Python, Java, and JavaScript to client libraries, and Docker is used for testing in some of them. But getting into this mentorship thing, it was not only getting these technologies mentioned before, but also getting into the whole hyperledger ecosystem, where you know you can know something, knew something new about other blockchains, read white papers, read some use cases, and make your knowledge wider and broader about business logic, not only coding. Yeah, it was also my first project in open source and my first big project, like not made to my university. So I was meant to attend to community meetings, participate in the community, read docs and know what's in them and what's not mentioned, to use GitHub not only to share code, but to test it and to make everything clear and visible for others so they know what I'm doing. It was whole thing is open source, you know, so you have to meet the code quality, cover everything in tests, make everything clear and visible, as I said before, and you have to let others to use it. So provide documentation, make examples, and make everything, enable everything to everyone. Okay, because it was a mentorship and I'm the mentee, so there have to be some mentee mentor. He's not with us today, I think. His name was Grzegorz Bazar. He's teaching assistant at AGH University in Krakow, Poland. Yeah, and he let me know about the whole thing. Working with him was some kind of new and very interesting experience. We hold the weekly meetings. He helped me a lot with understanding the code. So yeah, he has some previous experience with Iroha. He uses it for a few years. So he led me into internals of the code, how it's worked internally, the algorithms it is using. But he was also great, you know, with some tricks like dealing with communities. So to communicate with everyone and let everyone know what you are doing, ask the questions. You know, there are some tricks when you are working with other people and he showed me them and it was great experience. He was also the first person who was making the reviews of my code. So he read most of the error code. He was also reviewing ideas like we were working and I probably came up with many ideas but not all of them were good enough to be taken into coding stage. So he was the person who said, yeah, you are wrong here, here and here and you can came up with something new which is going to be better. And I think that it's time to say thank you Mr. Grzegorz. I'm very grateful for your job and you were a great piece of help for me. Yeah, I think that I appreciated it very much. But it was not only him as a mentor, but it was also the whole community who was working with me, I can say, and was supporting me actively. They hold a weekly meetings in which they talk about the code, the development and you know, in what direction Iroha is going to be developed. I also have some contacts with Iroha core team developers. So, you know, there are some things that even my mentor didn't know and I have to ask them. So for example, about messaging format, etc, etc. Also the community was a great help with exploring Iroha code because these are people who work with Iroha for quite a lot of time. So they knew about everything probably. And it was also very interesting to, you know, work with previous community, previous mentorships because people already made some internships into Iroha and they added many interesting features and it was great to read it, read the code they added and also know how other features work. There were some, you know, small disadvantages I could say. As language barrier, you know, you are, it's your first big project, you are calling into meeting and they are talking with some strange accents that you can't understand. But these are small things rather and yeah, I still make everything positive. So they are very small. Okay. And after I came up with all these things and the code was written and the whole thing was going to the end, I can look back and think about my achievements. So all pull requests that were planned were merged into main code and they were released in Iroha Windpoint 3 release. Also because I ended my job like two months before November, I was able to add some extra work. So I decided to work with Barrow integration. So with enabling executing Solidity code in Barrow and making it in Iroha. So I was also able to make extra pull requests with Barrow integration. I presented my work to Iroha community so I can get some feedback. Did my work was useful? Are they using it? And yeah, it was, it was useful. They are using it. That was very great to me that my work was not empty. During the work I also found back in a client library. That was not meant to be, but it happened. I modified the documentation. So it's now clear how things work and how you can use it. And also I provided examples in all three libraries. Providing examples were pretty interesting. I can, you know, you have to write everything in some programming language, each different. And it was interesting. When I look into Iroha, Iroha is alive. It's a small community, but they are very, very lively. It's great. And there is still work to be done. I probably every month I got new idea about what can be added to Iroha. I'm looking forward to read more use cases because I think having business logic is important. But also to get my knowledge wide and broad for other blockchains and for their usage. And also to explore deeper. You know, you have to always look deeper. So understand more and more and more. And it gives you a wider perspective. Yeah. So I think the journey does begin. And there is still work to do. I'm thinking about writing maybe some academic work. My bachelor's degree connected with blockchain technologies. But you know, it's a future. Yeah. And maybe some business usage. Like if I can get some job connected with blockchain or came up with my own idea and my own company, that would be great too. If you want to see my work, it's all provided on this presentation. But it's, you know, whole things are on the wiki page. You can check everything there. But I also provided links to GitHub issues and comments I made. Yeah. And if you have any questions, you can always contact me on this mail. I provided on the first slide or second, second. Yeah. Maybe someone have some questions. I think we still have some time. Like about a minute. Okay. So that's all. Thank you all for listening to me and see you, I hope. Okay. Hello, everybody. My name is Phil Potter. I'm going to talk to you about my experience with the mentorship program. So a little bit about myself. I work for Omi. We're a smart charging electric vehicle platform in the UK. I'm a back-end developer for them. And we also sell our own chargers. Obviously, my talk is in a personal capacity, but they're very happy for me to be here. They're very supportive. Yeah, I've left computers since my childhood worked as a very long time for an IT technician, did a computer science degree. And I just really wanted to take my passion for Linux a lot, a lot further. So I chose the Linux kernel bug fixing mentorship. The main reason for this is I wanted to learn more about the kernel itself, how it's put together, how it's structured. This basically involves finding automated bugs via the sysbot slash syscaller service, fixing them, and then contributing those fixes back to the kernel projects. Now, this was not as easy as it sounded at first, quite scary, hence the purpose for the mentorship. So I mean, I talk a bit about the skills that I gained. So one of the first and most important ones I'd say is, obviously, the main purpose is learning more about the internals of the Linux kernel. By the very nature of sysbot and syscaller, I was looking at patches or bugs, sorry, for many different areas of the kernel. So the network in subsystem, I think my first bug was actually in FP Dev. There's an EXT4 bug I found, a few scuzzy bugs. Literally, there are hundreds of bugs on there, and a lot of them are quite low lying fruit, so to speak as well, which was quite nice to get a sort of a feel for the process. Yeah, I learned things like simple debugging of, sorry, simple decoding of stack traces, kernel memory sanitizer, all stuff that gave me a much better feel for how things actually work internally. And it just made me, generally speaking, a better C programmer. Now, another skill I gained was actually participation within the process itself, within the kernel community. So sending your patches by email, commenting on other patches, the way it's done, get send email, all the various tools that have to be used to participate in this process, obviously not immediately apparent. Now, I've obviously sent a few patches before this, but going through this process really helped me with that in terms of getting used to the tooling and understanding feedback, working with it, changing things, and generally becoming more proficient and more efficient and making fixes faster, and making more of a difference, I guess, to the community. So another skill, believe it or not, obviously working on unstable kernel, shall we say, and then testing patches, generally not best to do on a production machine, right? So a lot of the time I would use virtual machines for this. This just had a side effect of making me a more efficient user of desktop Linux, right? I happen to be sort of using a laptop at the time as well to test a lot of patches, but generally speaking, when you're getting stack traces and kernel loops and so on, the system as a whole will often die, and so it's useful to be able to debug it from a virtual machine perspective. Also just backing up my work, email backups and stuff like that, becomes really second nature. So I really came a lot more proficient at that as well, and yeah, just again, we came second nature. So I'd like to talk about my experience and I'll start with my mentor, Greg Crow Hartman. I can't say enough positive things about him. The guy is crazily busy. He's a stable maintainer, staging tree, you know, just before the talk, they opened up the maintainers file in the mainline kernel. Greg has listed 18 times in that file. He's been super helpful to me. You know, I say in my bullet point there that he's answered all my questions, and some of them have been pretty naive. You know, coming from a very novice position, Greg's been super helpful, never patronizing, never rude, really encouraging, you know, and this is all the more impressive to me given how much work Greg has to do. I mean, I spoke with him and he told me one day that he'd had over a thousand emails to deal with, and I imagine that's an average day for him. So to do that and be patient with people like me is fantastic. Actually talking to Greg, getting to speak to him was amazing for me. You know, he's like a rock star to me. I've been following him for years and the other kernel developers as well, and so it was a real honor for me. Surprises from my experience. So just how helpful people work, right? So I obviously was very apprehensive when I first started contributing, right? Not so much for patches that I knew were obvious fixes, but more for systems that I wasn't so sure about. And some of my patches were totally the wrong approach, right? And the compulsion there is to think that people are going to, you know, insult you or mark you down or whatever, right? And I have to say, my experience in the kernel community has been so positive in that regard. People are so helpful. You know, I even recall one chap emailing me on my patch to say, no, this is the wrong approach. This won't work. And then 30 minutes later, I think emailing me some suggestions and codes to actually do the job properly. Like people have been so helpful and encouraging and welcoming. So I mean, just don't believe what you read online about how aggressive things are because anything but true, like everyone has been so supportive to me. Another surprise, just the variety of things I actually ended up doing. So I started with bug fixing. And then around halfway through that process, the University of Minnesota controversy came up with some individuals attempting to deliberately introduce vulnerable commits into the kernel free. Now, there were several hundred of these and they all got reverted. And I actually got to help check some of the patches over. And in some cases, even improve them significantly. And the feedback I got, particularly from Greg on that, was fantastic. And there was a statement from the Linux Foundation about that as well. And to have my name listed in that list of kernel contributors was a big confidence boost to me. And then I ended up actually working on the RealTech R8188EU wireless driver. I've had a big part to play in that in terms of importing a new kernel source into the drop into the staging tree and continuing to work on that as and when I'm able to. So it's all been really good fun, the amount of stuff I've actually got to do. And that's helped me to carry on with the process after the mentorship. The third surprise to me was just how much more I could get involved. Right. So a few months ago, Jen Satzbo on the mailing list basically said that he wished to hand off the uniform CD-ROM maintenance ship as he had so much other stuff to be dealing with IOU ring and then many other projects. And I just put myself forward thinking now, you know, nothing will happen. And crazily, I was accepted. And that that was just a huge confidence boost for me. Just just being part of the community in such a such a visible way. I had a phoronics article mentioned me and all sorts of things. And that was really, really exciting. So future goals. I want to obviously make as many patches as possible. You know, I really enjoy contributing, getting my commit count up, but not just for me, but because I want to have a positive benefit on everyone else. I want to learn even more about the kernel itself. There's still a lot of areas that I can do a lot better on. And I found it really interesting digging into the to the lower parts of the stack. You know, working with people, having people say to me, good job. And indeed me contributing and commenting and hacking and then, you know, signing off on other people's patches has been been really fun as well. And then, you know, finally, I'd really like people to get involved in the same way that I have, you know, the process has been so helpful to me, so welcoming. And, you know, it's really taken the mystique of kernel development and getting into the community and so on. And and it's a fantastic idea that people should should throw themselves into. So thank you so much for watching and listening to me. I want to thank Greg again. I want to thank the Linus Foundation and everyone at Linus Foundation has put this program together and indeed for continuing to sort of shepherd the top echelons of the Linus community to begin with. If you want to talk to me, email me, LinkedIn and that's my website as well. Thanks. Thanks for listening. I'm really, really glad that I was able to talk to you all. Thanks very much. So hello, everyone. I'm Lucas. And today I'll be presenting about my mentorship project, the common expression elimination for the salon compiler and other optimizations. So a quick introduction about me. I've just graduated in computer engineering. And I'm particularly interested in how the software interacts with the hardware. So before the mentorship, I did an internship with compiler theory at Google. And it I really enjoyed doing it. It really caught my attention to work with compilers. So I decided to apply to the Linux mentorship to be closer to low level programming and how computers work under the hood. So my project was around the Solane compiler, which is a Solidity compiler written in Rust. It targets a few blockchains such as Solana, so Stratton, you was. And it is a front end for the LLVM infrastructure. The LLVM, however, does not exploit some traits of the Solidity language. And it allows us to make several optimizations inside the Solane compiler. So my goal of this mentorship was to deep dive into compilers, especially how computers work under the hood. So my mentorship had three milestones. The first one was to detect and remove unused variables. So here on the right hand side of the slide, the variable V is undefined. The second one would be to raise warnings for undefined variables. So variable P here is undefined, as I declared it with no value, and we might read it having no valid variable. And the third one would be the common sub-expression elimination. So expression A plus A times B is repeated throughout the code, and I remove it from the intermediate, so the intermediate representation, and exchange it by a temporary. So my mentor was Shen Yan, he's the creator and maintainer of the Solane compiler. We work together doing design discussions, so every optimization for a compiler has many trade-offs. And these discussions were very fruitful because Shen has deep knowledge about compilers and computers overall. And we also work together reviewing code. So Shen reviewed most of my code, but sometimes when he changed something, they intersect what I was working with, he asked for my advice for my review. And I am very grateful for Shen's career recommendations. He gave me a very cool advice if I wanted to keep working with compilers in the future. So some valuable skills I gained from his mentorship is that I had responsibility from day one. So my contributions were partially released while I was working with Solane. And to be honest, I got cold feet because I have the feeling that something might not work as expected. So I also gained skills reviewing code. So some users interacted with my features in the Solane compiler, and they opened GitHub issues regarding what I was developing. So I had the responsibility to interact with the users and review their pull requests as well. And lastly, I became a better Rust developer. So learning Rust during the mentorship was kind of a challenge because I came from a C++ background, which has a completely different way of managing memory. So I had to take some time aside to learn Rust and understand how it manages memory to develop my algorithms in the Solane compiler. So what I enjoyed the most about the mentorship was the knowledge I gained with compilers. I dove into how compilers work, especially when I was implementing the commons of expression elimination. It was a very complex optimization to implement. I gained better knowledge about how to analyze design alternatives. So compilers are optimizations, algorithms are naturally very complex. And we should be careful to know what to prioritize. If either we want to prioritize a better code generation or more speed or less memory usage, we need to have a clear discussion on that. So Shen, my mentor, provided me with the open-mindedness to view other approaches and to think about possible outcomes for my design alternatives that were not originally planned. So some valuable outcomes from this mentorship is that I had a clear introduction to the open source community. So working with Solane was my very first contribution to open source. And I also made new connections during the mentorship. Most of my connections came from the blockchain community, but also some of them were previous maintenance from the Hyperledger organization. And I am very grateful for making these new connections because they helped me define which career path I'm interested in and what I wanted to follow. The last valuable outcome was the career advice. So Shen Yang, my mentor, provided me great career advice and opportunities. And we are still discussing something about compilers as I like working with Solane and compilers in general. So after finishing the mentorship, I was left with some aspirations regarding the open source community. So the first one is that doing this mentorship incentivized me to keep contributing to open source projects. I want to keep working with Solane. And I also want to get involved in other open source compilers or the post stories that use compiler theories for some kind of optimization, like the LLVM project, the Thanks for Flow, and the Triton compiler. And as I've just graduated right now, so I want to start my career as an engineer. And what is good about doing this mentorship in your senior year is that you get provided with many opportunities to work with something you like. So the mentorship has opened me clear ways to start my career as a compiler engineer if I want to. And I'm very grateful for the mentorship in my mentor to have provided me with those opportunities. So this is it. So thank you for your attention. Hi everyone. I'm very excited to be here today. I'm Desmond and I am A. I'm a final year student at Brown University and I really love systems work. So if anyone ever wants to talk about distributed systems, database systems, or operating systems, I'm always very happy to talk about them. And today I wanted to talk about the mentorship program I participated in. The last summer I was under the Linux kernel mentorship program. And under this program, we worked in the Linux kernel with the goal of addressing some of the many bugs found by dynamic program analysis running in the cloud. I think Phil talked about had a great presentation just now giving an overview of the program. And the goal really was that in taking a look at these bugs were one, in a deeper understanding of the kernel, and two, hopefully fix many bugs, which is always great for everyone. And today I specifically wanted to talk about my experience making a third open source contribution to a project. And what I mean by this, specifically, I'm going to first take everyone through a short overview of open source journey from my perspective. And this differs from everyone from person to person, but a very simplified view will be that where somebody who comes and joins the community, they start participating in discussions, they start contributing, and then they start, and generally we see that their contributions grow in terms of responsibility in terms of technical depth in terms of engagement in the community. But this, this picture is a bit simplified. And what I found, because I've been a big fan of open source philosophy for a long time, I tried to drive management projects. What I found is that there's usually this gap that a lot of people don't talk about. Usually we have a lot of great resources talking about how to get started, contributing to open source. There's a lot of great blog posts, great resources on they making your first pull request or getting started talking to the community, making, or how to grow as an open source contributor. But oftentimes, and I've tried this for a couple of projects, I've even made my first contribution, usually I make a documentation fix or maybe I implement some small feature. And then sometimes I'm able to make a second contribution where I take a longer existing issue and try to fix it and try to participate in the community. And maybe after a few weeks or a few months, that contribution lands. But usually I feel like I get stuck somewhere, right? So I've made a national contribution, I've thought of growing a bit as a contributor, but not really sure how to keep growing as a contributor. And so today I wanted to talk about how the Linux kernel mentorship helped me make this leap past this roadblock. And that brings us to what I mean by this presentation title, which is making a third contribution to the Linux kernel. So not being literal, but as an idea of making a contribution beyond your first initial contribution. Now, this is a story that is possible, not just by my own effort, but really only possible thanks to some of the mentors that really showed me how this process is done. Sure and Greg were the official mentors for the Linux kernel mentorship program. They're both Linux maintainers, they're both fellows at the Linux foundation, and they compiled this amazing list of resources, just showing how to get started just from getting the code base, how to make your first patch, how to test the patch, how to work with the community, and also how to grow as a developer. How do you get stack traces? How to understand them? How do you get traces in the kernel itself to learn more about the kernel? And also the great fortune to meet Daniel along the way. Daniel is the maintainer for the Linux sub-system in graphics. And he was an official mentor for the program, but he has a really great informal mentor where he really showed me the ropes on how to be a Linux kernel developer. He would review, fortunately, unfortunately, he had to review a bunch of my patches. He pointed a lot of advice, resources to look up, and was just overall a great encouragement on the process. And so I really wanted to take this time to say thank you to my mentors. This was really a transformative journey and really couldn't have experienced it with all your help. And just to give a brief overview, it's really hard to squeeze a whole sum of lessons from my mentors, but a brief overview of what they did that really helped and really helped me understand the process of going past that sort of roadblock that I face in joining a larger open source community. I tried to steer it down to four points, specifically in two different dimensions. The first is the technical dimension where my mentors provided a lot of learning resources that talked about on how to contribute technically, what to read up on to solve specific bugs. And it also gave a lot of very valuable feedback. So on the notes I took, on the patches were submitted, sometimes I would submit a patch that I didn't realize would break the kernel. And then they will point out that, okay, this is where it went wrong. Here are some continuous integration systems running the cloud. How can you test them and how can you improve when it patches? What other options are there available in terms of say kernel, kernel structures that I wasn't aware of that can help improve the patch. And this really helped break through the technical barrier in terms of making the contribution. But it's not all just about technical stuff when contributing to open source because a lot of the time there's sort of emotional barriers as well that get in the way of working out highly technical and creative work. And so my mentors really did a very good job. They really encouraged me all the way. And this is really great because I think I can speak for a lot of people where we work on projects that are larger than ourselves. Sometimes there's a lot of doubts like how are we actually helping? Are we creating more problems for people? And just hearing from the maintainers that our work is valuable and helping, it just really gets you of the emotional barriers in terms of being able to contribute effectively. And lastly, they also gave a lot of very useful career advice. And this is great, not just in terms of understanding more about the industry, understand what we have learned. And also it's very helpful for finding a job. But the really powerful thing about this is when someone comes up to you and gives you career advice, it kind of makes you feel like you're part of the community, like you are a Linux kernel developer and you have a future in the open source community. And this is very powerful. It really helped along the way and was just very validating. And just taking the lessons from my mentor and try to extrapolate. So how can we take these lessons and how can we make contributions outside a structured mentorship program? Some of the things I learned from my mentors that really helped and I think applies to everything, not just to open source projects, but to life, to the universe and everything that anyone wants to do out there. It's really a bunch of different steps that have to take place. The first is to get really interested in the project, because again, it's not just a technical work that we're doing. It's very creative work that you need a lot of energy to push through, but sometimes when you get stuck or where you're not sure how to proceed, to getting interested is very important. Do this by talking to friends, talking to people in the community or reading blog posts out there. Second is to follow the conversation, something that really helped me and I've applied this to all sorts of aspects in my life. Now I was that during my mentorship program, I followed every single email that came out of the Syscaller Google Group discussion. And what they showed me and what during this show me was that I could see how other people tackle problems and discuss bugs in the Linux kernel and I could see that I was part of a larger community that I wasn't the only one struggling to solve bugs. Number three is to just do something. Sometimes we get stuck, not sure how to make a large or impactful contribution. The first patch I submitted to the kernel was just removing a non-existent link in some documentation page. And even though it was a small contribution, it was really thrilling to submit a patch and just release it out to the world. And that got me really excited to continue working on the kernel and it was just great all around showing me the process and helping in the emotional aspect of things as well. Fourth is to find mentors. If you can, if you're an opportunity to find a structured mentorship program, it's always great. But there's always a bunch of informal mentors out there. Everyone in the community is great and everyone wants to help. I'm always so surprised at how generous everyone is in terms of offering advice, in terms of offering feedback to patches and contributions I made. And the last step in the formula is to stay in the game. Sometimes you get stuck or you just have to keep going for it. And even if you're experienced, if you're stuck, if you're a beginner, I think it's always helpful to stay in the game and it need be go back to step one, get interested, start seeing what other people are doing again, try something, get feedback and to keep following this loop. And I feel like this is quite a winning formula for making progress in any project and becoming part of a larger community. And I like to think it worked out well. By the end of the summer program, I made a couple of contributions. I participated in a bunch of discussions and contributed to a bunch of different subsystems and I really feel like I finally made this leap and became part of the larger kernel community. Looking forward, I want to follow my own advice that's to stay in the game. I realized that one really needs to make time for open source. I found that in the past few months, through the other things in life, I've not been keeping up too well with open source contributions. But I really wanted to make this a bigger part of my life. And along this way, I want to, one, deepen my knowledge of the Linux kernel to understand how everything fits together. And two, I want to help people start their own open source journey because I think this is really a transformative experience. I want more people to be very experienced. I've been encouraging a bunch of friends to get into the game. And last but not least, I want to make more friends in the community. So this is me saying hi to everyone watching this presentation. I can always be contacted at this email or by Twitter. And thank you so much to my mentors, to the community, and to everyone for listening to this presentation. Hello, everyone. My name is Wei Yao. And today, I am going to talk about my mentorship experience with the Linux Foundation. The project that I worked on is DRMan and GitHub verifiable credential registry. So the web link shows the details and the code base of our project. Okay, so about me. And again, my name is Wei, and I currently am a PhD candidate at New Jersey Institute of Technology in United States. I'm currently working as a research assistant in the blockchain lab at NGIT. And my research areas are blockchain technologies and deep learning. A quick review of the project that I am working with the Linux Foundation. So our project is to let me tell a story about this project, because you can think about such a scenario that if you want to buy a bill from a bar, and you have to share with the staff, your driver license that you are over 21 years old. So at that time, when you present your driver license to the bar, you will have some of your sensitive information. For example, your address or some else will be linked. So at that time, you want to prove you're 21 years old, but also keep the credential, the confidentiality of your credential. So our system is to help you to make such a system to build, to make this security and digitize that. So we are creating tools to build issues and holder and verifier for the whole system by using the technology of the blockchain and the use of GitHub and GitHub to build that repository. So my goal of this project is to first of all is to understand the blueprint of the whole framework. And then is to we are going to develop the open source product to share with the community. And also I would like to contribute this to the community. So about the entire framework, so you can see on the left side of this figure, there are some entities in this framework. It's like a general framework of the asset side. So here, what we have done is to we created the issue and by using GitHub. And also we integrated with the distributed ledger by using the half ledger indeed and the half ledger areas to to enlarge the whole project. About the programming, programming skills. There are so many, there are so many progress. So many skills are involved in our project. For instance, there's many open source projects are integrated into the project. And also we need a bunch of programming skills to integrate the different platform. But the most important here, what we have learned is Shields, Grip and Python and JavaScript. About the experience that I work with our community that we have learned. So first of all, we are using the GitHub as our code base repository. So I have, so we have to, we have a summit about like, I mean, at least like 10 pull requests from the original repository. And also we use GitHub as a version control. And also if we have any questions, we can post this on the, to the hyper ledger community and the latest foundation community. There's, there's a lot of expert and they are there willing to help us. About my mentoring experience, I would like to thank to my mentors, mentors, Mr. Veena, the Panistakian, Mr. Aram Parakash. Their professional skills have won many of the mouse and are surely a great inspiration for me. So Mr. Veena, he's an expert in cybersecurity in India. And Mr. Aram, he was the previously mentee in this program. And then this year, he continues to contribute on this project and help me. So it was a very, it was a fantastic experience that I work with him. We are Mr. Veena, he's located in India, and Mr. Aram, he was, he was in Sweden, and I'm in the United States. So even, even just the distance is super far, but we still can, you know, we feel that super good is that even because if I have any question, I can just post a question to on the WhatsApp or, or using email and they will response me like very, you know, I think I did the first time they can respond to me. I'm very appreciative to, to leading me to getting involved into the open source community. What I have learned from this project, so the most important thing is that it's the first of all, it's like, so you're always doing your research first and then never afraid to ask any questions in the community. And also you, you cannot, you cannot just read in the reference, but you have to get your hands dirty to, you know, to do the programming. But the last analysis, you just have fun to join the big family. About the future of my plan. So, so first of all, based on our progress, we, we feel that this project can be extended to, to work with some other open source project. And the next one, we would like to promote this project to, to as a research project to, to the hyper-legal community lab. And also, I would like to contribute to the, to the community, like, like my mentor, Aaron, he did. And also, I would like to be an expert in this blockchain area. Okay. Thank you for everyone. Thank you for the audience. Thank you for Linux Foundation. And thank you for my mentors. Thank you. So, thank you, Wei for sharing. And hi, my name is Han. And today I'm going to talk about my Linux Foundation mentorship journey in integrating blockchain technologies. And so a quick short introduction of myself. So I was a Linux Foundation mentorship program mentee during last summer. And currently I'm enrolled at UIUC. So I'm currently, I'm a graduate student at the University of Illinois. And I'm super interesting in software engineering. And currently I'm including my capabilities in software, software engineering with my graduate degree. And so this is a picture of myself celebrating the new year Eve with my friends. And a quick overview of my mentorship project. So basically, what the mentorship project, the project, the huge project that I enrolled in was called Hyperledger. So it is a collaborative open source effort backed up by Linux Foundation and big firms like IBM, Fujitsu and so on. And but even within Hyperledger, there are lots of blockchain technologies. The one that I interacted with are called Iroha and Cactus. So Iroha is a straightforward distributed ledger technology that's great for asset management. And on the other hand, Cactus is a framework. And there is a blockchain integration to design to integrate different technologies. And that's great for asset transfer. So that makes them a great fit because imagine that you pair asset transfer and asset management together. And so my mentorship project was about developing a connector plugin for the Iroha and Cactus integration. And the picture at the right bottom just shows a block diagram for my integration. So basically, the one that's sitting in the middle was just my connector plugin. And my connector plugin takes a request from the cactus. And it sends a request to the Iroha ledger. And also, it receives the feedback, the response from Iroha and then send it back to the cactus. And finally, cactus deals with communication with the users. And for my project, my goals are to understand the architecture of Iroha and Cactus. And also, as I mentioned earlier, develop a connector plugin for the Iroha and Cactus integration. And on top of that, I also develop a documented example of integration between Iroha and Cactus. Last but not least, so this has to be due with a full request because this is open source and open source community. And I want all my work to be inside and full request and have my full request get approved and reviewed by the maintainers of the community. So talking about what I learned, so first of all, I really learned about the internal infrastructure of Iroha and Cactus. And I really had to have a really deep understanding of the infrastructure of the two ledgers because I had to integrate them, understand their characteristics so that I can have to do the real integration. So first of all, even for the cactus framework, and that was a really huge project. And I had to understand all the like the project, the cactus framework structure and organization and develop my own toolings within the cactus framework. And as you can see from my first example, this is just like a one snippet of my code that's sitting inside the big cactus framework project. And also along the developing, and I had to understand the coding standards and meeting other requirements along the way. And also on top of the software developing, we also, we have to the developers, we want to conduct the unit has and the integration test to validate that their works succeeded. And in my example, in my internship, so I utilized the tape for framework because my project was using the TypeScript. And tape was a wonderful two to unit testing and integration testing the TypeScript calls. And as you can see from my second picture here, so it shows that they are like six test suites, and around like a one night ish test cases and they all passed and completed. And there's also code coverage, as you can see from the screenshot. And also during this process, I really learned about new technologies and some old technologies that I already had interactions ways. So for example, my this whole project was using TypeScript and Node.js. And Node.js was just JavaScript being used to develop backend software. And they are really new to me. And prior to this mentorship program, I had almost zero experience in TypeScript and Node.js. But this experience really transition me to be a capable developer in developing TypeScript and Node.js software. And on the other hand, I probably I had some experience with Docker and REST for API. But in this case, I had this like an industrial hand on experience with Docker and REST for API. And I was able to learn some really advanced Docker techniques. And I used those Docker techniques to slim the Iroha Docker image size by 85%. And also for the REST for API, because the Node.js or the JavaScript, JavaScript was dealing with REST for API. And I had to deal with REST for API every day by day. And I really have a more in-depth understanding of REST for API after this mentorship program. And also last but not least, I had a really deep understanding of the open source software development cycle, because I was involved into it for three months. And specifically, I contributed two pull requests. And for these two pull requests, all of them have been reviewed and approved by my mentors and by the cactus maintainers, because my code go to the cactus repository. And finally, all my contributions have been passed all the tasks and passed the criteria from the maintainers. And they have been finally being merged into the cactus framework. And talking about my mentors. So I have my two awesome mentors, because I was involved with both the cactus framework and the Iroha ledger. So my first mentor is Peter and he's an active maintainer of the cactus framework. And on the other hand, Greg is my second mentor, and he's a core contributor to the Iroha community. And the way that we work together was that, so basically, I believe that that's for all the Linux Foundation mentorship programs. So all the mentees is going to have a weekly checking meetings with their mentors for around one hour. And during that meeting, and during that summer, I, every week, I do presentations to my mentors to show my progress and receive feedback from them. I also look for their advice for like the short term girls, like for example, like what should I develop for the coming week. And on the other hand, so beside the checking meetings, so I use Telegram, Rocketchats, emails and to communicate with my two mentors. And sometimes I also attend the dropping sessions with Peter so that I can get some hand on experience and hand some hand on tutoring from Peter. And also, as I mentioned earlier, my two mentors review my calls and my pull requests. And they also provide the overall guidance throughout the three months. And here I want to present a huge thank to my two mentors. And now I'm going to talk about the three surprises I had during this overall mentorship program. So first of all, as I talked about briefly just now, so the technical guidance from my mentors were really helpful. And specifically, so as I illustrated priorly, so I almost have zero experience with high speed and OGS. And initially, I was also kind of overwhelmed by the technical jargon used by the blockchain community. And so it was early June, and I was really kind of frustrated by all the like the technical terms and the some of the technologies. But my mentors really helped me. So as I talked about just now, so I frequently use like a communication tools. And I also visit my mentor, one of my mentor, Peter's pair programming sessions, so that I was able to improve day by day and learning all the like the architecture of the cactus and Iroha framework. And on the other hand, was able to learn high script from my mentor Peter. And these technical guidance from my mentors really helped shape me to be a really capable developer throughout the way. And I was able to approach the project and finish the project really efficiently. And I was able to almost finish the project like before August. And at the end was like around three weeks. And that was like August. I was like doing some wrap ups and core reviews and documentation with all my mentors and maintainers. And as I talked about just now, so I also received help from the maintainers. That is to say, so I received some Azure guidance from the open source community. And also on top of that, so I also attend the Iroha community meetings frequently. And I really want to thank Sarah and she's the I believe she's a coordinator for the Iroha open source community. And sometimes I have some really in depth questions about the Iroha ledger and my mentor Greg, he's really not in that area. And so what Sarah does is that she I asked her questions, I just sent her my question. And she's going to find the Iroha developers that's working at that field or that area to come and help me or get like their answers to me. And when I whenever I have frustration or have struggles with understanding the architecture of Iroha and the this really this Azure guidance from the Iroha community really helped me to keep my pace and keep my efficiency throughout the software development. And here I still want to show great thanks to my mentors and the open source community. And also last but not least, this mentorship experience really has an lasting and positive impact throughout even throughout the for this last half a year. And I believe that they are going to have a really lasting and positive impact in the future. So for example, so in it has a really positive impact to my coursework. And I'm going to take I plan to take a blockchain course next semester. And I believe that this blockchain mentorship experience really helped me to have a more in depth understanding and will help me with that cost. And I also plan to take a distributed systems. And I also take some community communication systems, communication networks costs, and all of them have some interactions with decentralized protocols or decentralized systems. And my experience and my understanding of taking away from this mentorship program has really will help me and has already helped me to understand the distributed ledgers better and help me to have a deeper understanding throughout my journey. And also, I believe that this mentorship experience gave me more opportunities. For example, while I was doing my job searching, because I'm looking for internships, and some of the employers really look for candidates with skills or experience in developing software on the Linux platform. And my experience at Linux Foundation really helped me stand out among all the other candidates. And also, this experience really helped me to have more exposure to other opportunities. For example, I'm able to speak as a speaker here. And this is going to help me with my other skills like public speaking. And here I want to really present a huge thanks to the Linux Foundation to host this event and help everyone have a really well-rounded experience and a great experience throughout their mentorship program and even after their mentorship program. And after my mentorship program and I had these aspirations. So first of all, this mentorship program helped me to transition to be a software engineer. So the reason is that for my undergraduate, my major was electrical engineering and mathematics. And prior to that, prior to this mentorship program, I had not that much experience with software developing. But this mentorship program gave me really an immersed exposure to developing software and really helped me to validate that my true interest is in developing software. And I would like to be a software engineer in the future. And the second inspiration is that I want to get more involved into the open source projects. So throughout this past journey, I made some contribution to the open source community. And I'm really proud of that because my contribution is downloaded by people every day. And my contribution is being shared, being impactful and influential and helpful for people over the globe. And I want to continue that momentum. And I want to become more involved in the open source projects so that in the future, I have more works, more calls being shared over the internet and being able to help more people over the world. And last but not least, I want to, I have this aspiration that I want to speak at more open source conferences because I want to share my experience and so that more people will be more interested in the open source projects and in developing and contributing to the world through like the open source projects and open source software. And that's going to really help the world a better place. And that's pretty much it. And thank you for everyone for listening to my presentation. Hello, everyone. My presenting topic is from almost giving up on computer science to being open source contributor. So let me talk about myself. I am Oswin Timalsina. I am a full-stack developer intern at Louisiana Small Business Development Center. I am an FX mentee of Spring 2021 at Cloud Native Buildpacks. So let me present telling my story. I always had an interest in problems-holding specifically in programming. I joined for Bass versus Computer Science and was doing my best. But I was not getting my, I was not getting any opportunity. So frustrated and exhausted, I almost gave up and thought that I cannot do good in computer science. One day I heard about open source project and the collaboration culture from one of my classmates and Instantly got interested in it and started researching about the topic. Then I got interested, then I got introduced to the LFX Mentorship Program. I applied to it, got accepted. And when I was in my senior year, the journey began. In the Mentorship Program, I worked with Buildpacks, which is the CNCAP incubating project. In a layman term, Buildpacks help to transform your source code into a runnable app image that can run on any cloud. During the Mentorship Program, I set a few goals with myself. First, learn about open source culture, CNCAP, Cloud Native Buildpacks. Second, learn about Git and GitHub. Third, get most out of the learning opportunity. First thing I worked on was to learn about the Buildpacks. What it does, how it works, setting it up and getting an overview of the technologies that are used in the project. In the meantime, I adopted a habit of going through documentation and depth learning. Then I worked on a feature extension which was about developing a Buildpacks registry namespace notifier. It is an automation to notify Slack channels or averaging the repository with GitHub Action. Here I got to learn about Git, GitHub Actions, and automation. Next, I worked on an issue to design and implement Buildpacks registry search. I had previous experience with React, but had never worked on React with TypeScript. From this, I got exposure to React TypeScript and how it can be integrated with Ruby and Rails application. Hence, I also got to learn about Ruby and Rails and its model view controller architectural pattern. Finally, I worked on investigating APIs and corrected outdated API documentations. By the end of the internships, all my goals that I mentioned in the previous slides were checked. I got introduced to open source culture, CNCF, CNCF Buildpacks. Technically, I learned in detail about image containerization, container orchestration, Git and GitHub. I also got to learn about automation and GitHub Actions. Similarly, I also got to work on Ruby and Rails React TypeScript. During the previous process, there are plenty of other things that I learned from my mentor and the community. It was a great experience in the mentorship program with my mentor, Joe Kotner. He is the software architect at Salesforce and a founding member of Buildpacks. He guided me throughout the mentorship program and made sure to provide a smooth and great learning experience and environment. Every time he was curious about what are the things that I wanted to learn and work on and was open to any doubt and confusions. Moreover, I got to work and connect with many other contributors, also got to meet the community in community meetings. I felt welcomed in discussions and post on Slack and GitHub. Any doubt and confusion were warmly addressed by contributors and project maintainers. I'm still connected with my mentor and he has been helping me with career guidance. Now, let me talk about my dream for the future. I'm planning to contribute more to the Buildpacks and open source project in general. I want to make people around me aware about Linux Foundation, LFX Mentorship Program, CNCF and CNCF Buildpacks and let them know about the perks of getting involved. The Mentorship Program has again revived me of dreaming big, not giving up and the student mindset to always keep on learning. I want to be a lifelong learner. So to the future mentees, I want to share some suggestions. First, communicate regularly with your mentor and the community. Try scheduling weekly calls if possible. Second, challenge yourself with learning new tools and technologies. If you are stuck, mentor is always there to help you. Third, have fun and enjoy the process. Share yours and listen to others' life experiences. And last, I want to thank the Linux Foundation, the LFX Mentorship Program, CNCF Buildpacks and my mentor Joe Kutner for helping me and giving me an opportunity. It's such a nice and amazing learning experience. That ends my presentation. So right now, I'm looking for a full-time position as I have graduated from college. If you have any career opportunities available, please feel free to reach out to me. These are the ways to connect with me. Thank you so much. All right. Thank you, graduates. Those are awesome presentations. And you have shared your experiences with all of us and I am glad to be able to be part of your journey, helping you all at the Linux Foundation and also on our platform, Linux Foundation platform. And thank you to our sponsors. Without them, we won't be able to do what we do. Red Hat, GitHub, Intel, IBM, they have been supporting our mentorship efforts since the beginning. Thank you all. Bye.