 Hi, welcome to OpenJS-Rail 2021. My name is Tim Lai, and this is my talk on take the leap in the open source. This talk is pretty much for anyone. Since regardless of experience or expertise, it can be intimidating to get started in a new open source project. You might be the first time contributor or stepping into a much higher visibility project that you are used to. Whatever the reason, you might not feel so qualified to contribute to open source. First, a little bit about me. I've spent most of my career helping people and companies grow in both technical and non-technical ways. My current role is with Smart Fair, and it's to help make it easier for developers to use Swagger tools, such as Swagger UI and Swagger Editor. Previously, I was a VP of Engineering and Lead Engineer for Notary Camp. And prior to that, I spent many years at Intel working with clads of all sizes to holistically grow their expertise, whether it's technical, marketing or any other business-related activity that was needed to grow. So that's why we're here today. How do we get started and develop processes in a holistic manner? Over the next 20 minutes or so, I'd like to share some of my experiences on how to get started, make impactful contributions and pull requests, and create a roadmap to success. When you get into something new, whether it is a new project or a new job, there can be many new traits, factors, or changes considered, like what you can see on the screen. And I think what my head is hiding is single-user versus enterprise. So I can share a story about me. When I joined Smart Fair, I had to learn about the various Swagger tools to build and release processes, as well as the Open API specification. I was also joining an entirely distributed team. Although that was something I was very comfortable with and used to working with. In addition, although I was familiar with the technologies behind the Swagger tools, such as React and Redux, there are so many specific implementation details and nuances to get comfortable with. So this might also sound familiar to you and that's why we are here today. There's so many new things and it can't seem intimidating to get started. So the first thing to do that I would advise is just to take a deep breath. Everyone here today has expertise to contribute. We all know how to solve problems. So is this specifically how to break down problems into smaller bite-sized tasks? It's like building a house brick by brick. But like building a house, you probably don't know how to do everything yourself. You might be an expert in something like plumbing, but unfamiliar with something else like roofing or putting up drywall. Even if you are a good, good general contractor where you probably can do all the basic things yourself, there's still most likely experts who can do specific things faster and better than you. And that's okay. There's always more to learn and improve and everybody has different skill sets. But that said, you can still go and build that house. So now that we remember that we are all capable, let's talk about what we can contribute and what contributions can be impactful. The short answer is that all contributions can be impactful. Now, most people probably look at their expertise and see what they match with what I call core features. These are things that include like the front end, like React and Angular, or the back end like Node, Next.js, Spring Boot, or Coa. Or even UI design with various design tools to help you implement your UI. But there's a lot more than what I consider core features. For example, we have expanded tool sets because once we have an application, we need to be able to bundle, build, and distribute the application. And ideally, we also have continuous integration and deployment as part of the Rural Lease workflow. The second major topic that people think of when they are trying to figure out if they can contribute is if they are a subject matter expert or some in-depth knowledge of the specific technology. So I have to be a React expert or I have to be an Express expert or I have to be an expert with open API. And the fact of the matter is that it really depends on the project and the project needs of how quote unquote expert you really need to be. In this case of Swagger UI, depending on what you're working on, it might be very valuable to be an open API subject matter expert. I can say that when I started though, I was not in a subject matter expert with the specification, but there were definitely other areas that I could immediately contribute. So next in terms of contributions, there are tests. So there's unit tests and end tests and ideally continuous integration that integrates all those tests. You might be using or working with a project when you realize that a project might be locking quality tests or coverage and tests or even a framework itself for different types of tests. In this case, you could start from the ground floor by building the test framework and infrastructure. Another area for contributions is code quality. And this is not about delivering code necessarily, but this is around to reviewing code or putting in tools to make sure style guides and other workflow checks are followed. So like tests, many projects could use helpful tool in infrastructure on code quality to make it easier and more efficient workflows for developers. The next topic is around documentation and community management. The reason I bundled these two together is because historically people think of documentation as about how do I start with a project or how do I build the application on my system? But it can be a lot more than that. In the case of Swagger UI, there are documentation about the open API specification, there's documentation on configuring and customizing the Swagger UI experience for your end users. And we have documentation on the extended Swagger UI itself to meet your specific needs. And then again, more generally, there are contribution guides, style guides, as well as documentation around use cases and examples. And so with community management, if you have something like customization features in your application, you know, and if you have documentation for it, it might not be quickly found by some users. So people might be asking and creating tickets asking, how do I do XYZ themes? To which you can contribute by saying, hey, you can go to this particular area of the application to do whatever you're trying to do. So you as a power user can share your knowledge and help with the community. Another example is familiarity with past issues, where you can help direct a person to know or resolve tickets. And if a question is asked often enough, perhaps it could be added to a FAC or a Wiki. So with these examples, you can see documentation and community management, again, depending on the situation, it can be very related. And finally, the last topic about contributions is that you don't actually have to write code. I've alluded to it in documentation and tools and things like that, which regarding tools, you might have to do configuration or subscripts, but they are not necessarily all code base. So to recap about impactful contributions, there are a lot of different areas to contribute and it really depends on the project. And if you'd think about it from a software engineering perspective, this slide pretty much covers anything that might be needed. Now, there's always some specific expertise needed to make something better and more efficient, but that's where you come in because you have a lot of expertise to contribute. All right, so let's talk about effective pull requests. Now, anyone can open a pull request and the pull request can pretty much be for anything. However, the key point for me for an effective pull request is, might ask the questions, is this pull request easily understood? Is this pull request easily evaluated and reproduced? So doing things like you're really focused on mentally sized pull requests is very helpful because you are limiting your scope to be what can be easily tested and validated against existing systems. Now, this pull request also needs to be effective, right? So things that go into an effective pull request include follow the product style guide, include the supporting tests that you are adding as a feature or fixing, providing documentation to recreate its effectiveness, and then ideally include before and after screenshots. So all of this work to create a pull request is done to make it as easy as possible for maintainers and reviewers to evaluate your proposed changes. In general, and definitely for the first time contributors, expect to receive feedback on how to make your pull requests even better. It's not so much for all the grammar or required fields in a template, but for the clarification and suggestions and for changes to be more durable and effective. So an example of this is that you might make a change to render some data more accurately, and you provide a test to demonstrate that the code change works. But during testing, a reviewer might discover a related problem that may or may not have been caused by a code change. Regardless, project itself might be missing related functional tests that you are not aware of. So you might be requested to update your code and pull request to also adjust the newly discovered graphic functionality and or tests. Another topic around pull requests to make them effective is say, if you're a power user of a particular application or tool, you can share your knowledge in other people's pull requests. You can help clarify other people's pull requests with additional examples. And these examples could be about how to reproduce something in a different manner or these examples could be also used as part of the proposed test suite to validate against. You can also link to other issues and pull requests that are a work in progress or already resolved. This might help with duplicative efforts and it might also help start a community conversation and I'll make it a pull request more effective. And note that this type of contribution does not necessarily mean writing code yourself, right? Maybe you do some snippets, but otherwise it's more of a collaboration process. The last topic about pull requests is around awareness of impact to upstream and downstream projects. Now, I think it is unrealistic that you should be expected to know every combination or permutation of how everyone else might be implementing the application. But I think a good analogy here would be working with teams in your job. You are a part of the team and there might be multiple teams in your organization and you might be also be working with partners from a third party company. Basically anything you could do or anything you do could have an impact on other teams. So similarly here with pull requests, your work could have an impact on other projects. So again, this is where tests and test coverage really help. But we also just talked about possible gaps in test coverage. So despite any existing testing framework as well as your own work to provide tests, problems might still arise. And if this is a situation, well, clearly it's not your fault, right? And as you get more experienced with the project, you might be able to be more proactive in identifying potential impact or issues. But for now, the key is just to be aware that this is a possibility. And so in your pull requests, if you've already done everything you can think of to alleviate some possible concerns, this goes a long ways towards getting your pull requests merged. So let's talk about the last major topic here, which is around creating a roadmap to success. And there's a lot of different ways to become successful and become more successful. And one commonality between all of us is that we are all here to solve problems. And for many of you, you are already working in an agile environment and used to the terms like sprints, stories and ethics. And for those who are less familiar with it, in a nutshell, stories are described the need that is resolved with the desired outcome. They are the tasks that need to get done. Ethics are a collection of stories used to describe features and benefits to stakeholders. And sprints are a defined period of work time to get one or more stories completed. And a general idea is that we can't see all the detailed tasks and stories ahead of us, but we know enough to identify the important things to work on right now. So going back to building a house example, there are many tasks to complete in order to build a house. Some tasks can be related to each other and some have dependencies on others. So if you start with plumbing, you might not be able to complete the plumbing work because maybe you put in the pipes first and you have to wait for your cabinet guy person to build your sinks before you install the faucets, right? So when you jump into open source project, it's very similar, right? You want to accomplish something like building a house. It could be adding a new feature to your favorite application or it could be a fixing a set of problems that causes your users issues. Or it could be just some technology that you're really interested in learning more about. Start with a small brick, a story, a single story. And as you complete more and more stories, you'll find that you're making progress on ethics. So just like there's different types and sizes of houses, there are different approaches to jumping into a project. In the case of Swagger UI, I can share a couple of stories. The first one is my story on boarding with Smart Bearer. So I was less focused on learning about the open API specification right away. Instead, I was more focused in learning about the Swagger UI plugin system because I knew other people used it to customize the Swagger UI experience for their own end users. So I wanted to get in depth and get my hands dirty, if you will, to get working on a demo project to demonstrate and gain understanding of the Swagger UI plugin system. Now over time, I did gain knowledge about the open API specification, started working on features and bug fixes, and got involved with community management as well as took ownership of the release cycle, although not necessarily all in that order. I will say that all of this did occur in my first three months. So what started at small, in my case, a single EPIC to do a demo project, grew into multiple EPICs very quickly. In a different onboarding example, a fellow Swagger maintainer joined the team with expertise in tooling and algorithms. So he decided he wanted to add value more quickly by improving the tooling to make them more efficient and more consistent across all the different Swagger projects. Now his longer job focus was to become a subject matter expert with the open API specification so that he could go work on improving the performance of things like the Swagger UI parsers. We look at just generally improving performance. So there's one final story I can share. Now I'm gonna use accessibility as a specific example, but you can substitute any subject you like. Yeah, again, it could be design, it could be a piece of, it could be like a react specialization, whatever it needs to be, but I'm gonna use accessibility for now. So suppose I'm a consumer of an application or tool and I discover a list of accessibility improvements that could be done. Now the application works well for me personally, but it would make my users happier if I could make an impact on the application's accessibility features or lack thereof. Well, from a pull request standpoint, I can start small by focusing on just one element. I create a pull request and following the things that we just discussed to make an effective pull request, I go through that process and see if the maintainers are interested in such improvements. Now hopefully the answer is yes. Now there may be some back and forth in collaboration to make sure everything meets the expectations of the maintainer or the project, but eventually the pull request is accepted and merged. So that's fantastic, but I have a whole list of improvements. So I start working on the next item, create a pull request for that. And then I work on the next item and pull request, make another pull request for that. And eventually the maintainers might notice that I have a particular interest and accessibility. And so I might start getting paint on any accessibility related question or issue. Now, while I don't have to answer any question or fix every new issue that comes about in this project, it's not necessarily my responsibility, what is important is that I am being recognized as a subject matter experts. So hypothetically, eventually I might get invited to be part, to have a bigger part of the team, perhaps become one of the official maintainers of the project. Alternatively, or in addition to the another hypothetical example would be, might lead to a job opportunity, either with the project owners or by another contributor who has noticed my work and could use my subject matter expertise. In any case, the good thing is that there isn't any expectation that I need to stay and maintain my work forever, right? Because I've already done a good job making effective contributions, right? I made it concise, clear, provided tests for other people to build on. And I can still work on other features or projects that interest me. So I'm not just limited to one specific project. And that's the cool thing about open source. You can work on as many projects that interest you. They can be large or they can be small. You can contribute frequently or on a one-time basis. Your work might lead to new roles and responsibilities. You might learn about new technologies and solutions. Basically the opportunities are enlist and it's really up to you. So some closing thoughts. In open source, everything is transparent for the world to see. So be kind and be great to work with. Because it's a community that makes the open source great. So the better we collaborate, the better the tool application product it becomes. And then from a direction or growth perspective, it's helpful to understand what is important. So that you have a goal that you can work towards and maximize your impact to the project or the team. And finally, technology moves fast. Now it's a common misperception that with new technologies, you should just throw out old technologies. But the truth of the matter is, new technologies build on lessons learned from the past. And so open source gives you a pathway to learn and keep up with interesting new technologies and interesting new solutions. With that, thank you very much for your time. I hope that this talk has given you some useful tips and ideas. And I encourage you to take the leap into open source projects today.