Yes. Do you hear the sound? Yes. We will start today with Matiasi and his goal with the super-translator. Should you have any questions, please feel free to ask them here or in the matrix online, also for the folks who would have seen it online. Thank you. Great. Thank you for the introduction and thank you for coming. It's the first session, not after the party but still, yeah, first session, so I definitely appreciate it. So what can you expect from today's talk? It will be about adopting existing agile methods for environments that are generally big, big projects and bigish teams. So in the first part of the talk, I will try to bring us on the same page. Then I will be, like, concrete about how to do this adoption or about a proposal. And there will be then a demo and then some questions and answers. We'll see how the time will allow. So at the beginning disclaimer, agile is a term which covers a big surface. One of the subdivisions can be that it's about doing the right thing, delivering value for customers and another aspect is to be kind of efficient, to work well, yeah, not necessarily fast but also in a sustainable pace, predictable and so on. In this talk, when I talk about agile, I mean like the second aspect, yeah, I won't talk about the first one at all, not because it's not important but that's what the talk is about, so just to be clear. So I am a redhead developer. I am a team lead also of the security compliance team and when I joined the company like six years ago, we were brought to, or the scrum framework was introduced to us, yeah. We were one of the first teams and what we found out that it's not so easy, it's not a smooth ride. We kind of introduced it and then we noticed that we still have some issues with mainly like this predictability. And because we are like an open-minded team, we checked out what can we change in order to improve the situation and we made I think our agile practitioners happy because we were experimenting and desperate because we have tried like various things and we have evolved and the evolution still continues and we have simply found out that the problem is a difficult one, so even a good approach is not good enough. We need a great approach, yeah, so we'll see, we'll see. However, the main pay points that we have identified are the need to have a groomed backlog, which is like a very important concept in agile as far as I understand, being like a software engineer, yeah, not a person with agile education. And also as I'll get to it later, we are kind of a bigger team so a lot of things are in progress during the execution and it's like a mess to some degree, very difficult to find out whether things are going good or not, yeah. So why is it so difficult? Very briefly, it might be that one is not developing a web app from scratch for a well-defined customer, but one is developing a small feature on top of some kind of big product, yeah, and because the product doesn't have one customer, whom we can communicate and say we will do this and that will be different, but we need to keep everybody more or less happy, then actually a lot of work will be integration and not deliverable, yeah, like putting the feature there, integrating it with the rest and just like the small piece here is like presentable, but the work has to be done is really huge, yeah. So things are kind of slow. Also the team can be big, usually big teams, I don't think that they are necessarily faster, but they definitely can do more things and they are in some degree more stable. If the conditions change, big team can really adapt, take more responsibilities or even like exploit opportunities, but probably won't be doing it like in a specifically fast way. One offering is if you have a big team, split it into small teams, work much better, but maybe you can't do that, yeah, because the tasks that are coming are kind of changing, they are not stable, they are not always the same, so if you subdivide, then you will find out that you need to rethink the subdivision and so on. So it's not always a possibility to get rid of big teams and make small teams. So we are in this big environment, which means that things are slow in order to accomplish anything like interesting, the iteration can't be those two weeks tops, yes, but really like more time is needed. During the execution, a lot of things are in progress at the same time as a result, yeah, especially if the iteration is longer, and what suffers is the predictability. And as an engineer, I definitely came across the idea like screw predictability. What counts is the work that is being accomplished. What about giving engineers the right tools, the trust, the resources, and they will do the thing in the fastest possible way and screw the predictability, yeah. Why this is not a good idea? Some people know, but some might doubt that. So I have an example, imagine that you are a student and you are learning for an exam. And you know that you can get questions from three boxes, the green box, 50% probability of the question, red box, 40%, blue box, 10% probability, yeah, that you will draw questions from the box, a topic, yeah. And the question for the student is in which order you will learn for the exam, yeah, in which order. And it looks like that you should start with the green box questions because this is the most likely, right. But the right answer is you can't really know what is the right order unless you know how difficult it is to master questions in the box. And if you know the cost, then you can make a good decision. And in this particular example, it is clear that you should start with red, continue with blue, and then do with green because red and blue together are also 50% and their costs are much lower. So where am I aiming at? Predictability basically means that you know the costs. And you need to know the costs in order to prioritize, yes. So whenever we do prioritization, we are in need of predictability. So if we have a big team, big projects, and issues with predictability, we simply can't ignore it. Yeah, we need to address it. If you think of the previous example as well, it turns out that we estimate all the time. We estimate when we go shopping, when we travel, when we do pet project software, we estimate all the time. So why is it that the groom backlog or the estimations that are so painful? So there is like another example. And we see a situation like that in software development quite often. That's how much effort will it require to remove the rock. When we see the top, we don't see the bottom. So those gentlemen might have different ideas. And whoever played Scrum Poker definitely experienced that. Anybody who played Scrum Poker in their lives, could you raise hands? About half of the audience, I would expect more. So the other half will experience it, maybe, if they are engineers, at least. So what happens is that one person says, I think the task, difficulty is five of something, yeah. Other person says, the difficulty is 15. And then they discuss and they find out that there is nothing, that one person doesn't know, yeah. Everybody knows everything, but still one thing's five, one thing's 15. What to do that? It is a very difficult situation because it's about the unknown. It's not about the known. And it definitely makes people uncomfortable because the number will be settled on 10, yeah, the number will make it into the tracker. It will be visible to managers and people are not so happy. So in order to know how to help this situation, we need to take a look what is an estimation. And if somebody says, I think the rock can be removed in two weeks. What happens in your brain, yeah?  It means that probably they won't be able to do it in the first week because it's very difficult to do things fast. It's easy to do them slow, but to do miracles is very difficult. However, it is somewhat possible that they will do it earlier, between first and second week. It is however most likely that they will do it slightly later between the second and third. When the third week has passed, you start thinking, it might never be done, yeah, it happens. It happens in software, it happens anywhere. So what is an estimation? What is it? And we know it all. It's a distribution of probability, actually. And the thing from the annotation that everything has been invented, here it is. It has been introduced in the late 50s of the last century. And this concept that estimation is a probability distribution, it's called PERT. It's being taught, I think, as a part of project management. And it introduces this concept of a three-point estimation. So instead of estimating tasks with one number, they are supposed to be estimated with three numbers, which sounds quite scary because if one number is a problem, three numbers might be a much bigger problem, right? But maybe it's not the case. The guidance is that we come up with the optimistic estimate, which should be so optimistic that we think that we can do even better with one or 2% probability, yeah? So it's not like, it's not completely a rosy dream, it's just like optimistic. The most likely estimate is what we normally target. And finally, we have the pessimistic estimate. It can be like story points, it can be weeks, it doesn't matter, really. And again, the pessimistic estimate is not a promise that it won't be later than that, that it won't take more effort than is the estimate. But again, there is supposed to be like a couple of percent probability that even that will be slipped, yeah? Whether it's one or 2%, that probably doesn't really matter. So what does this approach, so yeah, sorry, one more thing. Usually we are required to put a single number in some tracker, yeah, in JIRA, whatever. And the good news is that as any probability distribution, this three-point estimation probability distribution, PERT or beta distribution, whatever we like to say it, it can be represented by the mean and the mean value is not the same as the most likely value. The mean value is somewhere between the most likely and the long tail. So in this case, we see that the pessimistic estimate has the long tail, so it's like more pessimistic. But if the task would be more like optimistically inclined that for example, for example, there will be no bugs to fix after we run tests, yeah? Then we say, we think it might be like five points, but maybe there will be no work to do, yeah? In those situations, the expected value would be actually skewed to the optimistic end. So what problem does this solve for us in another point of view? There is this concept that we don't have in check, that estimations or whatever quantities, they can be accurate, they can be precise, yeah, we don't discriminate that in check. So when we put numbers to estimations, we are infinitely precise, yeah? Number is simply a point, so we are infinitely precise, but as we all know, we won't be accurate. So we are in this unpleasant situation. However, if we substitute the estimate with this interval estimation, we are probably slightly improving the accuracy by using the expected value, and we are making the precision actually less, yeah? Or we have lower precision, but it is more proportional to the actual accuracy. So we have actually better odds of hitting the target if we have lower precision. Interesting, if you think about it, but undeniably true. So this is like a very interesting theoretical concept. Has anybody ever used it in this room? Has anybody ever used it in this room? Apart from my team? Nobody, nobody, nobody, okay. So me and my team have been giving it a shot for a couple of months, and there is one excellent news regarding that, we have concluded that the process of estimating and using the estimations, when you use three-point estimations instead of like traditional ones, the three-point approach is not worse, yeah? The process is not more painful. It's not like three times more painful to super use those numbers. So the process is not more painful, and maybe it's even more comfortable. We are not completely sure about it, yeah? But we will continue our investigations. At the same time, this is a difficult problem. Estimating is a difficult problem. So even a good solution, even a better solution doesn't completely solve everything. So we found out that you need some practice, you need some guidance to estimate using three-point estimations. And also, it's like difficult to explain. What does it mean? That there are like misunderstandings, and we don't know exactly. Then the second thing, the second pain point was the execution, which is busy, plenty of things going on and so on. Sometimes things are in progress for a long time, and it's usually a problem, but if you have a lot of things in the sprint, then you don't notice. On the other hand, some things are not in progress, and maybe it's okay, maybe it's not, maybe they should be, and so on. So when you have a long iteration, you can't do this traditional approach that after those two weeks you do some retrospection and you say, this was wrong, yeah? If the iteration is very long, then you need to act in progress. As soon as the problem is obvious enough. So it's necessary to have some tooling to introspect what is going on, and we will see that in the demo. So yeah, I put here a screenshot of a JIRA, because this is the only software that we use, which basically has a field to input estimations. I'm not really sure how JIRA can be configured. However, I think that for big teams, which have more challenges regarding estimating and so on, having this small field next to some other stuff, like having this small field basically invisible when you are not looking at the issue, that it's something which doesn't make the estimating easier. And for some reason, at that time, when I realized that, I thought like, oh, might be a great idea to try to develop a software that would kind of address this issue, that would provide an interface to the data that might live in JIRA or wherever. Yeah, GitHub even doesn't have a field for estimations. GitLab has something, I guess. And the software would allow to the team members to estimate and it would allow them to see the execution of their own long sprint and maybe even do some stuff like deliver forecast and so on. So the project exists. It's, I wouldn't advertise it at something that works, generally. It's like a demo. And if you are a Red Hatterer who uses JIRA, then it might be a good idea maybe to reach out if you like that. In other case, I would suggest waiting or maybe using the GitHub channel that the project has. However, I hope the demo will work. What will we try to model? We will try to model like a sprint which has two epics, if we say it like that. One is that we do an upstream release, which includes fixing bugs, running tests and writing a blog post. And then we do the downstream release that includes, again, running tests and then making the package, the downstream package out of the upstream source code. So, five minutes delay. But I guess we will manage. So let me see. So what do you see right now? Is like, is the interface of the program. And it allows us to estimate, to track the execution and also to simulate that the execution is in progress. So we go to the planning interface and there we can see that somebody, it was me, input those two epics, yeah? It's like not a software used for, that can be like seriously offered, yeah? It's like more something that works. So we have this fixed blockers issue and somebody already puts that it's five, yeah? The cost of it is five. And we can make out of this one point estimate, we can make the three point estimate. So if we say fixed blockers, usually it's like pretty difficult. So we say optimistic estimate is four, pessimistic estimate is eight, yeah? Then I click save and it kind of, it stores it somehow. And we have this, we have this, we have this plot. So I will do it, I will do this for that issue. Releasing upstream, again, yeah, probably it will be easy. So I will say pessimistic three, otherwise it will be the same. Writing block post, three points, yeah? Sometimes people are very, very nitpicky, yeah? So we say optimistic three, most likely four, pessimistic, I would say it can be eight. And let's estimate the rest two issues. Fixing issues in downstream tests, running downstream tests and fixing issues in downstream tests. I think that they might be nothing to fix, everything will work. So I will say optimistic estimate is two. And pessimistic estimate I would say can be like five because there might be problem with infrastructure, yeah? And so on. So if we take a look, it all can be added. Like the individual estimates can be statistically, correctly added together. So we see that the cost or the aggregate estimate of the entire sprint is somewhere between like 15, yeah, to 22 story points. Something like that. All right, and what we, any question to that? Might be a good, yeah, so the question was what the points are, what the points mean? Yeah, yeah, it's like a story points that are supposed to be proportional to objective complexity of the task. One could estimate in person weeks, that's not a problem, but estimating in points is like an alternative, yeah? Fernando? Yeah, yeah, the question was whether we have a story point definition there. Well, we don't. We don't at the moment. We use currently the basically conversion ratio to our earlier units that we have been using, yeah? The plan for the next planning season, not the current one, but to the next is to come up with this definition table and so on, yeah? Yeah, the question is about like epic level summaries, yeah, whether they are just reflect the expected value, which is like the traditional work, or whether they reflect the whole. What you see now, it reflects everything, yeah? It reflects really all those three values. It's like a statistical process, some of random variables. Ten minutes left, so I will proceed with the demo of the execution, yeah? So what we can do here, actually? I can say in a separate tab in that same web app that the team will deliver certain amount of story points and there will be some progress. So I choose that the team works on fixing blockers and they deliver two story points. So I click next, hopefully it won't crash, and I will refresh. And I will refresh the web app. So the not burned down chart, because burned down chart doesn't distinguish between states, yeah? The not burned down chart basically says that nothing has been delivered yet, yeah? That's correct. So I continue, let's say 1.5 story point, the team delivers again, yeah? So it shows that something is in progress, but still not done. So continue, 1.5 story points, yeah? And we have our first task complete, oh yeah. So what we can see in this not burned down chart is that the burned down is not linear, why is that so? Because there are deadlines to those epics and we don't expect to work on something at a certain time and conversely, we expect to work on something else the other time, yeah? To make it clear, individual epic burn downs look like this. We suppose the upstream release to be finished early and the upstream release to start a little bit later. All right, so one thing has been finished and when the task is finished, it already makes sense to talk about velocity of the sprint or in the sprint. So we can see that because one task has been accomplished, then the team at that time when the task was in progress had a velocity of the cost of the task divided by how long it took, yes? So this is like the measured velocity at that time. I continue with the upstream release. So 1.5 story points, one story points and we have an upstream release done, yeah? And again, we see that something happening with this kind of burned down and we also see that there is some velocity increment around the upstream release because we have some data regarding the velocity and we have also some data regarding the size of the task we can estimate when the task, when everything will be completed, yeah? So right now if the team continues like that, it looks like that they will be done somewhere after the second week, yes? The 95% confidence is before the sprint is supposed to end. And this vertical line is where is the day of the simulation. So I will just click some numbers here to have time for questions. I will put two everywhere, hop, hop, hop, oh, yeah. And the team has delivered everything. They did it fast because I put two and there was not, there were like three weeks and the total cost was like 18 story points so that was very comfortable for the team but this chart gives you some information, yeah? You can imagine that if there are not two epics but if there are like 10 epics and the number of tasks in the sprint which is maybe like not even a month, maybe three months long, it can be quite big. This chart gives you an overview whether things are in progress, they are being done or not. At the same time, this velocity plot, of course, when one works on one task, only at a time it looks like this, yeah? Of, well, not a very good piece, so to say. And technically it's possible to somehow compute the estimated completion based on data. All right, you have seen something. So I guess that's pretty good but to give you a couple of minutes for questions if you have some, yeah? The question is we have been using this for a couple of months, which is kind of correct and we have been able to validate that the things kind of match, the estimations match. So we, as we are using the data story points, the only thing you really match is the proportion, right? You measure the capacity based on previous executions so the only thing that you need to be sure of that you estimate consistently, that task which is two times more difficult to get roughly two times more state points and so on. So definitely there is, in our case, a concrete case of the team, there is like definitely room to improve. One quarter is a little bit better and the other quarter is a little bit worse and that's usually a symptom that things are not clear. So we have identified, we have done other mistakes, yeah, for example, like the composition of ethics that it was not really matching the execution and making it easy to collaborate. So we are not even in a position to conduct it and hope that it would give like a positive result, yeah? So we are mainly removing the big problems at the moment if it answers roughly the question. Yeah, so we prototype, yeah, yeah. What are the outcomes of using the tool? Yeah, that's all right. We definitely found out that it has value during our secondary iterations, our primary iterations are long, but every two weeks we kind of reevaluate but we don't have any deliverables so it's mainly internal event and on those secondary iterations, this tool is undeniably providing good overview of what's going on and whether there are problems that should be addressed. Yeah, this is what really works. It's not so more about three point estimations, it's more about like these charts and taking a look and saying, yeah, this doesn't look so well, mainly decision support, yeah? The outcome is that it provides a decision support for those interested in completing the work and also, as I mentioned at the beginning, like there is probably a little bit less friction during the estimation process and we hope that we'll be able to use this completion projection and to see whether we are actually sleeping or not. So we are out of time, technically. I'll be around, the tool, the slides will be online, the tool is open source, it can connect to JIRA, whatever, and so on. So you will know what to follow, yeah? So thank you for your attention and have a great rest of the conference. I would like to share some of the original stuff for you in the course in one hour. There will be an after part tonight and your ticket at the noon at the assistant. There is also a night of high work and long call at the end of the night, so it also works mostly with it. And tomorrow I would like to invite you also to go to the last session tomorrow at the closing of this course where you can listen very nicely. I do, and now we will continue with another session. I will hand over the work to our speaker. Thank you very much and welcome to our session, How to Contribute to the Ansible Community. We are Anwesha and Carol and we will do a brief intro of ourselves. So I'm Carol Chen and I just listed a bunch of dates because I just wanted to show that I have been a Linux user for a while. My first digital was actually Red Hat Linux, not Red Hat Enterprise Linux, but it was, yeah, it was Red Hat Linux 6.0 something. So, and I actually finally joined Red Hat, you know, one of my dream jobs in 2016, so such an honor to be here. And I started contributing to FOSS projects around 2004. I'm actually a bit hazy on the exact time because I had to check my own LinkedIn page to find out when that was. So, and if I had seen such a talk before that, I probably would have contributed earlier because there's actually many different ways to contribute, not just code. So we'll go into that a bit in the talk.  I started using IRC a long time ago and nowadays I am on Matrix. Believe it or not, I can learn new tricks. So I joined the Matrix. I actually heard about Matrix in 2016, 17 and already signed up for my ID, Matrix ID, like around then. So find me on both my work and personal Matrix IDs listed there. And I'm going to hand off to the much younger Anwesha who, you know, despite her youthfulness has a lot of open source experience. So don't be deceived.  So very powerful combination. But I'll stop talking now and let her continue. Thank you, Carol. And welcome, welcome everyone to the talk. Hello, my name is Anwesha, Anwesha Das. I'm a lawyer by education and technologist by passion. I am the, one of the newest addition to the Ansible community team. I'm a software engineer at Red Hat. I help free and open source communities around the globe with my technical, legal and organizational skills. I'm a proud Pi Lady. I don't know how many of you know about Pi Ladies over here. I am a Pi Ladies organizer at PiLadies.com and also I led Pi Ladies efforts in India. I have a blog, Anwesha Das.in, where I translate legalese to English amongst many other things. And I'm a fellow at Python Software Foundation. Wow, I'm representing Red Hat. Amazing, okay, okay. I wanna share a story with you. It was 2020 during pandemic. I was talking to a friend of mine who is a senior technologist who maintained kernel.org for a decade and who is an ex-Red Hatter. I was curious that what he is doing during pandemic. I was like, what are you doing? And he said that he's Ansibilizing his whole infrastructure. I said, why? I was curious. And he gave me an answer which actually changed the whole perspective for me for Ansible. So he said, if something happens to me, then people will able to understand what and why about my infrastructure. Ansible helps you to think declaratively. The comment indeed was deep and it's a fact. But thinking declaratively, is it the only feature that makes Ansible cool? Not really. There is a lot of things in the list. Agent list, architecture, cross-platform support, easy way of deploying and deploying in the server. So there are like many in the list and also it enhances the security and mitigates human error and makes so easy. Like I started learning my system administration through Ansible or like lately in Ansible. So that is how we are pretty cool actually. So no wonder why Ansible is the most popular free and open source automation project. Now, when we are talking about Ansible, we are not talking about a single project. Rather, we are talking about a whole ecosystem. Right now we have 20 plus project inside Ansible ecosystem. And like every other successful open source project, there are certain things which lies at the very core, open source ethos, a collaboration and community. What is Ansible community? Rather, who are Ansible community? You are Ansible community. We all are Ansible community. Whether you are a user, developer, or people like us who gets paid to work on Ansible, all of us together form the Ansible community.  Also, if you contribute via content or code, or if you evangelize and tell other people how cool Ansible is, you are a part of the community. Ansible is blessed to have a very strong community in regards of contributors. Ansible used to be the 10 most popular open source project in GitHub before 2020, before Ansible core and collection split it. Now, if we talk about in terms of users, there are millions of you, like the user base is in millions. And when we want to see that, what, how big is our contributors base? Let's use this chart. So this proves how big is our contributor base. This is a chart dated April, 2023. This is show, this shows the contribution, like staff versus non-stuff. So if we see here, it's 57% of the contribution has been made by the staff and the rest of it by the community. Now, if we see the unique authors in this set, 184 has been staff and a staggering number of 4,170 being non-stuff. We have used, and we have considered PRs and review comments for the last three years on GitHub, where we have indexed like 50,000 plus items and covered 376 GitHub reports. Now, is it actually the graph which shows how big is our contributor base? Actually not. We haven't considered the 30,000 plus roles and collections on Galaxy. We are pretty big. Now, are you interested in like Ansible and do you find our ecosystem interesting? And maybe some of you want to start contribution or you have started your contribution towards Ansible. Let us give, let both of us give you certain pointers to that, like how can you contribute to Ansible and anyone and everyone can become a hero in the Ansible land? So how to become a hero in the Ansible land? There are many options for you. If you want to contribute via code, which is generally, which is a norm, which is the first thing it comes to the mind, of course, you can, we are a Python shop, majorly our code bases in Python and as I mentioned, we are a free and open source project. So, and it is licensed under GPL v3. Now, collections, if you want to share your plugins, your roles and modules and you think it can be helpful for the community, please come and share it. One of the major reason why Ansible is so successful and has been adopted by a large number of people is because of its documentation. I am a living proof of that. I have learned Ansible by learning from the documentation. Now, this documentation, not only our documentation, not only describes the tool, rather it gives you certain practical examples, which is very, very helpful. So, if documentation is your passion, please join our documentation team. Ansible Meetups. So, Meetups is a place where upstream and downstream, the users and the contributors, the whole community collaborate with each other. We have 139 plus meetup groups and 52,000 plus members all over the globe. Find one and join one of such meetup groups and share your automation journey. If you're interested in web design, currently we are trying to build a website. We are in dire need of a website designers, UX and UI. UI, apart from the need which we have in our Ansible ecosystem, please join our group. Carol is going to tell you more about this in later part of the talk. And most importantly, run Ansible Meetings. Share your knowledge, share your user journey, share your stories. This is your chance to give back to the community. Now, in this section, in the next part of our talk, we are going to describe each of these in details. Like, how can you do that? Like, how can you contribute via code? Now, as I said, Ansible is a big ecosystem, so you can ask Anvesha, there are like, it's a big ecosystem. How can I find that which are the spaces I should look for if I want to contribute to Ansible? So these are the spaces you should look for if you want to contribute to Ansible. Three GitHub organizations and Ansible Galaxy. Then the next question comes, there are so many projects in the Ansible universe. Now, which are the projects which might be interesting? You might want to go and check our new Ansible ecosystem page where you can find what is the definition and what does each of the project does. I have actually mentioned few of them over here, but you can go and find about all of them in the Ansible ecosystem page.  You can fix bug or you can report something which might be a problem for you. You don't know it might be a problem for others as well. So please start contributing by fixing bug or adding a new feature. Now, how to find out if you want to start contributing? How to find out? So look for these labels, Easy Fixes and Good First Start Issues. Easy Fixes are the good first start issues. So these are the labels you should look for when you want to start to contribute. Now, the next part is Ansible Collection. If you want to start contributing to Ansible Collection, it is a very good way of contributing, like a place to start with. So Ansible Collections is what gives Ansible the superpower and why I say that. Because Ansible, there are thousands of collections, as I mentioned before, and which is maintained by the domain experts, which keeps Ansible ahead in its game and also gives us agility. So if you want to start contributing to collection, it's great. Now, how to do that? There's a link, Contributor Collections. If you want to contribute to collections, it's a document which will guide you step by step for that. Also, you can upload your collection to galaxy.ansible.com and there you can share your collections with a bigger audience, with the community. Now, and that is how you can become the guardians of the galaxy. Now, if you want to start contributing to any of these projects, I would strongly recommend you, please do come to our booth and talk to Andre and a majority of the Ansible engineers over here. If you have any questions, you can turn around and talk to Adam and Chad, who are sitting over there and who's, so please do that. And now, Carol is going to tell you what are the other ways you can contribute to. Oh, thank you, Anwesha. There's so much great information in there. So let's continue. All right, Anwesha already touched a bit on documentation and one of our main docs person is over at the Ansible booth, he's Don Narrow. So if you have any documentation questions, you can go talk to him. And actually, tomorrow we will have a talk at 2 p.m. and it's about some of the progress and things we've worked on this year and one of the major things is using personas to define user journeys in the documentation website. And Don will be the person who will be at the talk talking about the details. So I'll let him do the honors tomorrow. So please come to the talk if you're interested. Then, oops, my speaker notes. We think about documentation and sometimes you're thinking, oh, I'm new to Ansible. How can I help in the documentation? And actually, new users can be great help because as you go through the documentation to get started, you will probably notice ways to improve, to make things clearer that some of us who have used Ansible before take for granted. So if you find some way, oh, this is actually missing a step that if it's specified, it will help the process of learning, of explaining the steps of using Ansible. So you can create an issue or a PR to bring that to our attention, to the community's attention and we can improve the documentation with your help. If you're interested, we have a documentation working group, DOGS, DAWGS, and we have a cute doggie mascot there. It's every Tuesday at 1800 UTC and it's our matrix at the docs colon ansible.com matrix room, which is bridged to the Ansible-DOGS RSC channel. And actually this room is also bridged to a Discord channel because we actually have a group of writers from Nigeria, I think, yeah, who are also contributing to Ansible-DOGS. So it's definitely a global community-wide effort to improve the docs. Similarly with code, there are some issues you can find in a DOGS site repo that are easy fixes that you want to get started with. You can search with these labels to find these issues and the bit.ly link below Ansible-DOGS contribute, outlines the process of how you can create a pull request and submit it and what information you need to contribute to the documentation repo and improve that. Again, I want to touch a bit on meetups. So I mentioned a bit more about how you can contribute by organizing a meetup. These are great numbers, tens of thousands of meetup members, more than a hundred meetup groups, but honestly, not all these meetup groups that we support are active. Partly due to the pandemic, partly due to various reasons, some people started the meetup group, changed jobs, lost interest, things in life happens, so they may have abandoned it. So please, if you know of an Ansible meetup group in your area, you can go to meetup.com, search for it. If you find it and it's not active and you're interested to make it active again, come talk to us. If there's no meetup group in your area, you want to start one, also come talk to us. And if you find a meetup group with Ansible as one of the organizers, that's probably supported by us. So, and also besides meetups, which are more kind of local and regional, sometimes in your different languages, depending on your audience, we also have presence at many major force events, such as this one. So, but as much as our team would like to be everywhere or at once, meeting all of you, we actually depend also on the community, such as you to represent us, represent the community at events. So I want to give a shout out to Daniel Shire, I think Slantzimis, who actually did that specifically for Chemnitz Linux days in Germany. We were not there, he approached us. He said he would like to have Ansible workshop or talk or something and even had a booth and we sent him some stickers and he was there just sharing about Ansible community, contributions, the use of joy of using Ansible and things like that. So, these are little things that, if you have the interest, we want to support you and help you to do things like that. Sure, sometimes, oops. Yeah. Sometimes organizing a meetup, it is a lot of work, not sometimes, it is a lot of work, but there are ways that even if you don't have all the time to do the main organizing, you can help in many different ways. If you have a space for a meetup, you can help to host it. If you don't have time to take care of the organization, but you have a topic you want to talk about, approach a local organizer and offer to speak at their meetup. And even by attending a meetup, you are contributing, you're helping because a meetup is nothing without the people, right, without the audience. So, there's many ways that you can do to make meetups happen and be a part of the community. Another thing we want to mention is we're working on Anwesha's leading this effort. We're working on a meetup toolkit for organizers. There's like sample emails to find location speakers, templates for social media posts, and something to get you started. And of course, this thing will also be open to contributions because we realize that many different regions have different challenges and variations about how meetups are organized. So, you can also, as a meetup organizer, help other organizers to improve their meetups. Oh, and also, one example is if you want to do a presentation on how to contribute to Ansible, we will upload these slides to the scheduleshad.com after this. And if you notice on the first slide, there was a Creative Commons license. So, feel free to use these slides and at your next meetup to talk about how to contribute to Ansible. Chatting sounds like a fun, easy way to hang out with people you share common interests with, right? How is that contribution? Well, by chatting with people in the Ansible space, we have a matrix space, a space on matrix, similar to the DEF CONF space that some of you are now in to join participate in this event. By, you can help by answering questions because a lot of users come on these chat channels to ask questions on basic usage, or on contributions, quote questions, event questions. So, a lot of you have a lot of great knowledge to share. And even if you don't know everything, well, because I usually don't know, I don't have most of the answers, but I know where to look for the answers. So, I help, like, oh, maybe you can talk to Anwesha for this. You can talk to Andre for that. So, you know, you can be the person connecting more people in the community. That's a great way to not just help each other, but also build the community spirit. So, what's a community without these strong connections and links to each other, right? So, just by chatting is a great way you can contribute. And if you're watching or chatting on matrix and having questions, we'll hopefully be able to answer them soon. And I'll look at the matrix room after this talk. This is actually XKCD comic that, by the way, the slides were put together by Leo Gallego, our teammate. So, I actually found this tweet that somebody tweeted to me a while ago because I used to be a hardcore IRC user.  But I got converted to, and now I'm a main matrix user, although I do have my two accounts breached to IRCNICs. But anyway, join us on matrix. So, now is audience participation time. Hopefully you'll be able to scan this QR code, take out your phones now, start scanning. I'll give you a couple of minutes. And again, this is because Leo put together this initial set of slides for Red Hat Summit as a community day last month. So, thanks to him for finding a bunch of cute cat pictures. So, if you scan it, you'll find out what I'm talking about. Please vote. And like Leo said, don't just vote for the cutest cat or funniest cat you see, but think about what you might be interested in contributing or what are your strengths and interests. I'm just gonna pause for a while. If there's any questions at this time, we can maybe take one. If not, we can wait till the end. All right. So, we've gone through quite a bit of many ways that you can contribute to Ansible Project. And there's definitely not an exhaustive list. There's definitely other ways that we have not mentioned. And there are also a couple of things we're working on that gives you more opportunities to contribute in the future. So, if you are aware of some of our strategies from the beginning of the year, we talked about how, like Ansible said, Ansible is a large growing project. There's a lot of different sub-projects and different parts of the community. And one of the growing problems, growing pains is that things can get fragmented. So, in order to kind of address this fragmentation, two of our kind of main strategic items for this year are to create a new website and to create a new forum. And we've definitely discussed this very thoroughly with the community. We have had meetings and GitHub issue discussions and things like that. So, just curious, how many of you here knew that we were working on a new website? Good, thank you. So, it's a work in progress. There is a repo that's, you know, we're doing this with the community and you're welcome to join the website working group, our matrix at website, called ansible.com. As with website, you know, there's a lot of content that needs to be added and there's a lot of visual designs that needs to happen to kind of pull everything together. And like, we have great, you know, engineers and writers and stuff like that. But unfortunately, we are lacking in some, like UX, UI, designers, people who have that ability to create engagement through the online presence. So, if you have that interest, you know, it's an easy way to showcase your talent and also help this ansible community. So, and as the website launch in phases, there will be additional ways to contribute like writing blog posts, creating video content. And, you know, if you have great ideas, please come talk to us and also join the website, working group to share your ideas. The other thing I mentioned is the forum. So, it will be based on discourse and it's just a way because we have many, was it, how many hundreds of GitHub repos, right? So, each of them have, you know, discussions and issues and sometimes it's really hard to find if you are looking for something specific to have a central place to find that discussion that's happening. So, we hope that this forum will be able to kind of address some of that and pull the community together in one central place that you can share different ideas. And it's almost close to the end where, you know, in the finishing, raise the finish line here and hopefully, you know, within the next couple of weeks or at least the next month, we'll be able to share the availability of the forum. It's, 99% probably is going to be forum.ansible.com. So, once it's confirmed, we will let you know and please subscribe to the Bullhorn if you haven't already to stay updated of this. So, how do you subscribe to the Bullhorn? How do you, you know, follow all these things that we've said for now? Since we don't have the website ready yet, we do have anansible.com slash community page that has the Bullhorn information, has some of the project information. And so, you know, in the meantime, please stay, keep your eyes on the page to stay on top of the updates. Once the website's ready, it will definitely be announced there and you can continue following us and interacting with us on the website and the forum. And if you have any questions that you want to reach out to us directly, of course, Matrix is one thing, Ansible Space and also Ansible dash community at redhead.com is another way to reach our whole team directly. And speaking of the whole team, I'm wondering, would you like to share with us about, tell us about this? Okay, Carol and I might be present over here, but this is a work of all these wonderful people. Carol and I also included in those lists wonderful people though, but you can see many of them in our booth and some of them who are part, as I said, of the bigger Ansible ecosystem will be there in our booth as well. So please join us in our booth and have, if you have questions, like we'd love to be interrupted. And so whenever you find us, grab us and ask whatever you want to ask about Ansible. So here is our wonderful team. You can, so this slide, as Carol has been mentioned a couple of times, has been made by this person with a red hat, Leo. And thank you, Leo, for that. And many of the questions which we've said in this talk, like answered in this talk has been answered by them. We just, we are just echoing their thoughts. So thank you, our team. So every project, as we were discussing, every project advances and progresses. So, and it is very essential that we work on the core of that project. Like what is the thing, what we are working for? The mission statement. So we are working for our mission statement. If you can have, like go to this QR code and we are having a feedback, like we want your feedback. We need your feedback for describing and having our new mission statement for Ansible. Please consider giving a feedback over there. We would really appreciate it. And with that, do we want to say thank you? Of course we want to say thank you, but before that, any questions? From here or online, perhaps? Thank you very much. And again, if you haven't scanned the QR code, it will be available at the booth as well. Please come talk to us. We'd love to hear from you. Enjoy the rest of the F-Con. Thank you so much. Thank you so much. Thank you. Hello. Check, check. Good. Thank you. Yeah, hi all. Good morning. Thanks for coming and attending this talk. Today, I will, we will explain you how program and tester can be productive. So in this, we will share our experience. Like me and Nancy, we are working from last nine to 10 year on multiple projects. So we face a couple of challenges. We, like what are the things we are doing? Like what are the principle we follow so that everything will be on the time and we deliver the good product? Okay. So mostly like we will share our experience in this. And let me introduce myself. I'm Anu Singla, working as a principal software engineer in Red Hat. So mostly I work on the front end technologies. And like apart from my work, I also share my knowledge and educate to the people on the YouTube. Good morning everyone. I'm Nancy Chan. I'm quality engineering manager at Red Hat. And I have over 11 years of experience in quality software quality. And as a QE manager, so I'm me and my team, we both are responsible for overseeing the development and implementation of quality control processes. And we make sure that our products reach highest quality and standards. So that's my quick introduction. Now, Anu, we're going to talk about like, what we're going to discuss today along with why we choose this topic. Okay. Thanks Nancy. So today our agenda is why did we choose this topic? What are the top five conflicts and how do we resolve these problems and collaboration between developer and tester? When the developer and tester collaborate with each other and the couple of case study like we follow in our projects and the couple of suggestions from our side and then Q and A. Okay. So now why did we choose this topic? Like the development tester collaboration is very important. Okay. So we need to work together. And if they are working together, definitely the productivity will increase and the customer satisfaction will also increase. Like if we say in 1990 or before the agile, the waterfall model was used. So in that like development tester has very less collaborations. So like I didn't get a chance to work on the waterfall model but one of my friend Deepak Cole, he has shared some experience with me because he has worked on that. So at that time like the tester and developer, like tester is working in the end and the developer working in the starting. So in that like once a garment comes, so there is one SRS document is prepared on that time. So one is shared with the developer, one is shared with the tester. So there was very less communication between them and the tester is working on like as per the SRS document they're working on their use cases. But take example like if in the end, the tester is testing the bug, testing all the product and some critical bugs is found. Then maybe it requires some infrastructure change. Okay. So at that time it was very difficult to make the changes because tester is already testing in the end and it will delay the productivity or delay the production. Okay. So that's why like the agile process has come and in the agile like everything is on the collaborating and we are working on the sprint. Like we follow every fourth week, we deploy our changes to the production and there are a lot of meetings is going on, retrospective stand up or grooming meetings. So it helps to grow and deliver our product on time. So before I jump to the top five conflicts, I would like to ask quick questions to our audience. You guys might work with the different development teams or might be like interactive with the QE team and program teams. So as per your experience, what do you think? What are the reasons which creates conflicts between programmer and tester? Anybody in the audience? Yes. Yeah, right. It's totally, I totally agree with your answer. Miscommunication, some like pressure on the releasing because like we always have some deadlines where we need to like release our changes to the production. So if that's the reason like miscommunication, time constraint, pressure. So how, what do you think? Like how does this impact teams, efficiency and productivity? Anyone? Yeah, please? True, you are right. So I can, I can, yeah. So the question is, how does this impact the teams, efficiency and productivity? And she said like, yeah. So we sometimes happens where we fix, we found some bug, then we tested that again, it's kind of a loop, right? And I do you agree? Like it will create some kind of empowerment where like, like we feel like, it increased a lot of errors, right? And along with like, it also impact the overall job satisfaction, associate morale. Why? Because we have that kind of like, because these two teams have conflicts. So, and these are the five top causes which like conflicts, which I feel as per my experience working with different teams. So it's not accurate to say like, testers and programmers can never become productive or friends, but yeah, there are few challenges, there are few scenarios or situations where the relationship impacted with because of the challenges. So the first one is competing goals. So you know, like when it comes to the programmer. So programmers and testers both have different goals and priorities and as per their job, right? And programmers are mostly focused on delivering and developing the software. And on the other side, testers are mostly work on like testing the finding the bugs and make sure that like, the software is the highest quality. So I will take a quick example of like, how this works like quality versus delivery, bug free versus functionality, functional software. So let's take an example. Testers usually they try to find bugs as much as possible. And if they are aiming that like, we will be going to have a bug free software. And but on the other side, programmer really wanted to have like release the things, release the changes on production as quickly as possible. If that's the case, if they found some bug, the testers said like, okay, we have one bug which is related to UI and UX, like some font or some alignment is good, not good because they're prioritizing the customer satisfaction priority. But when it comes to the programmer, they say like, we can take it that later. Let's work on the quickly release. So here the conflicts arise. So next one is blame game. So that is very common blame game. So what it means, let's, here I will also give you a real time example about new feature testing. So when it comes to the new work, the new work, like we already have existing system and we are just adding a new feature in the system. So what testers usually do, they pick that chunk and test. So when it comes to the new feature testing, we also need to test the regression part. So regression is nothing but we're like, you're checking that with this new changes, there is no impact, the existing functionality, which is very, very important. And if they found some regression and they reach out to the programmer saying that that's a regression, they might argue with, no, that's not, it's not the part of, you need to focus on the new feature. Why you are going to the regression? And I'm sure this is not because of my change. So that's kind of, it's very common. So the next third one is communication gap. So I like that's a very major point. Communication gaps happen like testers found bugs, they write the bugs, they log the bugs in the different machines, like we have Jira, bug zealoms, and sometimes happen like they're not explained each and every details and information. So how this will impact programmer pick that bug and they're unable to address what's a problem because they're not able to, they're saying like it's not working on my machine. That's again a very common. So conflict arise because they say, tester haven't shared the exact steps, steps to reproduce so that they can work on the solution. So here the again conflict arise when like they know no and due to the lack of the information, it delays to the resolution. So the last one is the another one is limited interaction. So limited interaction is basically depending on team structure, depending on the project. So there may be the high chances both programmer and tester teams got let very minimum chances to interact. And if they are not interacting, how they will going to understand the end to end business strategy behind the work they are working on. So they might work on a silo basis if they are working on a silo mode. So they have a high chance they have a minimum opportunity to connect. So again, limited interaction also create conflicts. Time conflicts, time conflicts, both roles have a totally different priorities and goals which we need to think. And when I told I already explained like when it comes to the programmer they mostly focus on delivering the things, be on time. And when it comes to quality, there may be a chance for, they ask for like, okay, we are not ready and we are not confident to give the acknowledgement to release the things and they need extra time. So they again conflict arise because destiny is more time to release. So these are the top five causes like which creates conflict as per my experience. And this is very basic scenario. You guys can like relate like where developer and tester is saying it's working on my machine and develop, no, no, no, no, no. It's not working, you are wrong somewhere. And another image is saying like, okay, that's why I'm giving a bug to the developer and developer said no, it's not a bug. It's a feature, it's an improvement. So yeah, so this is how it works. Now how we can solve coming through these points a developer, I think it will create a more impact. So Anish. Yeah, so Nancy has shared like a couple of problems. There are a lot of problems between developer and tester. Now we will see how we will solve these types of problem. And like, as per me, like developer testers should be friends, they sit together like after the COVID is not possible, maybe we are not going office, but at least we should go office, contribute, collaborate with each other. Okay, yeah, so like the first step is supportive language. Always support your tester or developer. Okay, so like, take example, if tester is find some last minute bugs. Okay, so don't blame them. What are you doing, man? Why you didn't find in the starting? Why you are coming in then? At least thanks them. At least we find that bug before the production or if the customer come up with that bug, it will create a negative impact. So always support them. Second way, and one of James, as there is a testing guru who tell always like tester don't hate dwellers. And it's like a means the wife tell to her husband before going out. If there is some stain on his shirt, so he will not feel embarrassed. Something like that. So developer and tester roles should be productive, should be friends, they know each other. They know their strength and weaknesses. Or take example one more like if the tester is not able to reproduce an issue, but help them to reproduce the issue. Give some system logs. Because as a developer we know what are the input. If we provide that input maybe it reproduce the issue. So provide that information so that they find the issue and they can log the issue. So second way is defect triage meeting. So we follow this like every week the test, the bugs will come from any places. Like that the tester from developer from multiple players from customer also. So every week we do one meeting. In that meeting we discuss what is the priority? Either it's a bug or not. Or what are the solution? The basic things we just provide that in the ticket also. And the story points also. The difficulty level of that bugs. And the code freeze. It's very important guys. Like means if like tester is a human. He don't test each and every part of the app. So if we are pushing our code till the end. Like we have the production which tomorrow and we are pushing our code till now. Then how the tester will test each and every part. Because they need to test a regression like each and every part. Like right now we have the automation we can do it. But still we need to do some manual testing also. And like what we follow is we have the three. Like every four week we do our production push. So three week we are pushing our changes to the, pushing our changes in the testing environment. Last week we give full week to the tester to test each and every part. But we give like if they find any critical issue. Just we fix that issue and push on the testing environment. Apart from this full week we give to the tester to do it. And next one is a resource alignment. Like in IT word resource, resource currency is very normal. Like somebody is joining the company. Somebody is leaving the company. And the most standard ratio for developer and tester is like three ratio one or as per the product as per their experience. But mostly this is the standard ratio. So sometime if there is some resource crunch. So always like as a tester push, as a developer push less code in the production or in the testing environment. So that they will get a time to test the things. Or like help them like as a developer we can test other developer code or the second one is also test our code. So we are also follow these things. Sometime is the, we have the little bit scrunch in the resource. So that's the part of resource alignment. I would also like to add the resource balance in the both developer and QE ratio is very important. Five because of like if we don't have a balance team like for example we have five QEs on one developer. Not good, right? And on the vice versa. Five developers, one QE, a lot of pressure. A lot of pressure to work on the things. So being like as a QE manager, I always sit together with the project team and decide like how the ratio should be. So when we are talking about the industry ratio about the dev versus QE it should be like either three ratio one and two ratio one depending on the project, the complexity of the project, the timelines and the like what we committed to our stakeholders. So always like don't go to your manager. We have a current and just we need to help. Like manager can't do anything, right? We have the current so we need to manage ourselves. And the pair program and testing like I follow this one. Like I always try to share my knowledge, architecture knowledge with the tester. Because if we share our knowledge definitely they will not come with the small, small bugs like the data issue or some like the if some field is not showing in the UI then they will not come to us. They analyze from their own self if we share our knowledge with them or like they can directly ping to the backend team. I'm not able to see this field please take a look. So it save a lot of time between developer and testers. So now we have seen like how we will solve these problems. Now at what time the developer and tester collaborate more each other. So like the shift lab testing and in the shift lab testing like always try to involve that tester in the initial phase. In the initial phase so that like once the requirement comes so we analyze, we figure out how we will deliver that product. So at that time if we involve our tester then like tester is feel like a customer. They think like a customer, how the customer will use this product. So in this way if they provide their suggestion then as a developer when we are designing our architecture then they share our knowledge. And we use their knowledge with use their use cases while designing the product or while designing any feature. So it helps like and if we are thinking like all the scenario in the starting then it will definitely will help us to grow in the future also if the new things come. And defect reporting and regulation it's a normal thing like always developers say I'm not able to reproduce this issue. So like when the tester is reporting the bug then definitely provide all the things like attach the video, attach the screen, so provide the proper steps. So that like when the developer start working on this he has some information. So I need to do these things and I'm able to reproduce this issue. At least he will not come to the tester. Oh man I'm not able to reproduce this issue. What can I do with that? So it save a lot of time between developer and tester. Okay, so next one is resolution, recognition and appreciation. So like in Radat we always recognize anybody if somebody help us. Like in Radat we give some reward points some and thank you note so that he like the next person will feel satisfied like he help us and we recognize him something like that. So now we're going to discuss about the different case studies. So before I will discuss the case study I would just like to call like these case studies are the, we are actually actively these are the real time scenarios which we are actually using in our teams with the helper and collaboration from like a development team along with the program team. So the first one is okay the first one is implementing a CI CD pipeline which result improving the software quality. So I will go into as a part of this case study I will going to discuss like how these two roles actually helps like how the tester can help the development team during the development phase. So the first one is like you can see like how usually developer works. So developer build the work they usually work on the requirements they build and before so how the team testers can contribute during the building or during the development phase with programmers they can like add a automation suit. So automation suit is nothing but it's a smoke suit which give us a confidence like the basic functionality or basic critical functionality of the software is working fine. So what we will do we will hear like when the developer is building their code before like merging it's a master branch at that time we will integrate our automation suit with that unit test. So along with the unit test our automation suit will going to run if it's working fine like the basic functionality which we added in a suit is working fine it will ready to go with the merge request otherwise it will detect the problem and share the report with the developer. So that in the early phase developer can take a look what are the problems or you can consider what are the regression with this new change and it will be also solve the time tested they no need to like much worry about the basic scenario because we have already tested as a part of the building process. So the next one which we have is like cross-functional collaboration for comprehensive testing. So comprehensive testing is very important why because in agile module like we do like quick changes move that changes to the production. So how we can achieve cross-functional collaboration so we usually conduct the bug bash. So bug bash is an event where like we invite different teams different representatives from the development team program team as well as different QE teams. So they keep their normal they set aside their normal jobs for some time and they start testing on a piece of the thing which we have planned to release. So for that we can take an example of a e-commerce site which they are planning to release a major changes in the production. So we will conduct a bug bash event where we are like representative from the development team QE team come together and doing random testing to make sure that like to find the bugs or testing different scenario for example shopping cart workflow payment workflow to make sure that like we like give a cover all the scenarios related to the UIT. So at the end of this event what we will do we will call out few winners on the basis of the defect quality their severity and like and the details which they have shared. So it could be like you can every organization have some mechanism to appreciate that it could be rewards points it could be some gifts. So this is how you can encourage the cross-functional collaboration. So the next case study we have is about the actively participation of feedback loop like how you can involve tester in during the feedback loop. So customer satisfaction is very, very important when it comes to the software development and if we act on the customer feedback on timely basis we can increase the overall customer satisfaction as well as the product quality. And as you know testers QEs are known as a customer advocate. And if we are involving then it will definitely we're going to have a very good impact on the next as a feedback. So let's say here let's say example every team every software had their different mechanism to gather the customer feedback. It could be an email directly it could be a form attached on the system. It could be a account time who helping who connects with the customer and customer directly share the details. So we gather all the feedback in a one space and we usually have a monthly base meetings where we discuss the overall the feedback which we receive. Now on the basis of like then developers and tester both contribute and share like what are the things which you need to prioritize. So we log the tickets in our ticketing mechanism and tester start working on it on the parallel side development will going to work on the fixing the things and tester will start working on the test plan. And then they will deploy a test and inform the customer like okay these are the feedback we receive and we fix this and now it's ready to use. So this is how tester can also contribute as a part of feedback loop. So I'll hand over to Anuj to talk about the overall development and development. Okay so Nancy has said like all the three principle which we follow guys if you are not follow try to follow these things like the CI CD it's very important like means before pushing our code changes we try to like test the things so it will not create a regression. So we follow the same feedback loop is very important we follow these things okay. So now we will discuss like how we deploy build and deploy the features okay. So this is a full diagram I try to make and try to explain you guys. So how we are doing and so how we are involving different people like the tester, developer, UX engineer or the PM level okay. So like the first one is requirements. So requirement come from many places PM level, analytics level or the customer okay. So after that like we analyze the requirements. So in that like the all the team members like who are tester, developer, UX engineer or the PM level managers everybody is there. So in that we decide okay either we need to do these things or not okay we are doing these things then what are the priority of that or how the customer will use these features. So the tester is giving the suggestion they think like a customer and then like as a developer we think okay. So either it's possible or not or the backend team also decide okay. So how we will deliver or how we will give to the UI this some if we need some backend support or some data from the backend. So in this way like we analyze each and every part. So once we figure out okay then we go for the build build the feature the UX will give us the UX design and then we build the feature and after that we like the tester things and like in the testing phase we are also helping the as a developer we also help the tester to test the things share our knowledge and then after that like the customer demo. So after that like before going to the production we give the customer demo and like if it's a critical feature or the new feature we give some UAT like some give some pre-prod environments and give some URL so that they can do some UAT testing and then after that like deploy the features and we continuously take a feedback from the customer. It's very important. So like in this way like we try to build our product and try to build the quality and improve the quality and all things. We follow this role. So guys like these are the couple of suggestions from our side to all okay. So try to build a network with all the tester and developer means try to go for offline meetup try to go for conferences like I'm here. So I meet a lot of people like in this way like we get to know okay how the people other people are using the technology different products and all things. So continuous learning like it's a very difficult like as I'm a front end developer everything every day is coming new things the new library come like there are a lot of framework in the UI so it's very difficult to learn the new things or continuously learning but try to update whatever tool you are using try to things okay maybe means try to the new feature is come try to think about okay the new feature come learn the new things so it's always like always try to update yourself and be kind in stress. So like in IT the stress out is a normal thing right. So we have a lot of works to do and but try to come out take a break it's always a good thing don't starting blaming just take a break it's a bad thing or take a feedback in a positive way I always follow these things so I try to take a feedback from multiple people if somebody give you the negative feedback take is a positive because thanks them at least he give you the negative feedback and he finds something bad in you try to improve that and definitely in the end you will feel yourself as a positive way. Make personal brand like means I follow this rule means try to write a blog like I try to educate try to educate via YouTube. So related to web development but means try to do these things and means it's help you if it helps a lot means definitely. So with that this quote we will wrap up our talk so the quote means that testers and programmers should work together rather than or instead of like competing with each other by sharing and collaborating their knowledge their skills they can create a better and productive or good product so thank you thank you. Any questions. Okay so the question is like how you are maintaining the quality while pushing the changes right on the QA. Okay so like this is diagram if you see here what we are doing is when we are merging our changes okay when we are create our MR okay so in that time once build the code everything is fine then we run this unit test and the automation test so tester give us one URL like tester also doing like running their automation test right so in the GitLab we are also running their unit test on our GitLab so in this way like suppose you have make one button change okay so it we are 100% sure it this button will not create any regression at least in the existing or the critical functionality or the unit test we are also follow this rule like every time we try to write the unit test otherwise we don't merge any code so this is like we follow this rule and in this way like once everything like at least the existing functionality is working fine then we go for the merge request and then deploy to the testing environment and then tester will also do their own testing manual or whatever they want to do and after that we go for the production so this is way like we follow and if you see here in the red sign a problem detected in the unit test like if there is some issue in while running our changes then we go to the developer will take a look it's either because of me or there is some issue in the other unit test or the automation test so we connect with the tester and in this way like we follow this rule so as of like in this section like you know like when we execute our automation run right we do have some report which explain like what are the things is not going well so developers can take a look because we have already shared all the workflow and all the framework with them along with their like integration with the unit test report okay the question here is like how we spread this collaboration across things because they have high chances there are teams which not following this right so you know like we usually have a flow where we have a QE team or development team and program team so we usually have one monthly or like monthly or like twice in a quarterly meetings with the leads so over there we usually have a bi-directional discussion and feedback on the QE team as well as development so like as a QE manager I have one-on-one with my team members right to see if there and they do have any feedback for the developers because they're open to share like they can share the feedback if they are facing any challenges so they discuss with me and because I don't want like their developers and Qs directly have some some relationship conflicts so I act as a manager act as a moderator and they connect with the development manager as well as program manage to make sure like this is what we are facing like how we can fix how we can fill this gap and vice versa if development manager have any feedback like okay we have a resource crunch or last release we got a critical bug on production so how we can like improve this in a better way so being a leader so we discuss internally and make sure that like it should be a bi-directional call so we usually keep like I usually follow the monthly connect why because we usually have you follow the agile and or Kanban which has like three three weeks spent or two weeks spent so this is how we should work and second way like we have the retrospective meeting okay so if something is not going good so we discuss in the in that retrospective and discuss like provide some points and action item also we follow that okay so we will take care in the next time okay so like first time mistake is a normal thing but if you are repeating the things that's a bad thing so try so the retrospective is a good thing and we have the weekly grooming meeting daily stand up so we follow these things and at least like we are maintaining the quality and all things so if you also have any questions anyone else I can give a raise me a hand anyone in the back anyone any other question okay so I'll give my I will share my experience maybe Anuj will share so the question here is like how we can encourage peer program your peer testing so I'll give you a few years back me and Anuj were in one team and just like before the release I found very critical bug and when I found like it's like two I think next within a few hours which was supposed to really I was just doing the smoke testing and when I informed Anuj Anuj said okay Nancy come at my desk I'll show you what is going on so he explained me the code like Nancy and he told me like Nancy you sit and you fix it I was like how I can fix it that's your job so he said like it's just a mistake of full stop you just we miss that that is why it's a blocker is coming so I sit on his desk he explained me the whole code and I fix that bug so this is how you can encourage so if it's coming like if developers should like explain like how they're very small small tips like we also encourage that culture in a team like they explain like how the console and how the network logs tester can understand right so because if there something is failing without directly logging up sorry bug but we usually do which firstly check console is there any errors going on is there any what's the network logs because there may be a chance it could be a internet intimate issue right it's you have a like network connection problem that is why it's failing so just like learning these things and collaborating with developers it helps a lot so yeah okay so I follow this thing like I always share my knowledge okay so somebody tester come up I'm not able to see this field I ask him have you think about this why you are not able to see these things so have you checked the network call or are you getting any console error so he think like this and then I explain him okay we are doing some these things and that's why you are getting this issue so at least in the future he will not come up with the same question and the second way we follow we like every month we have the one guilt meeting so in that meeting like everybody share their own experience like something if somebody did something good so like in that meeting he explain okay I did these things and everybody is in that meeting like the developer tester so this is also the second way we follow these things and the third way we try to like automation test right so we help them maybe I have some bandwidth one day or five hour, 10 hour then we told them okay could you please give us one automation test maybe I help you or we review their code also they review our code but sometimes they are not able to do but we ask them okay is there any scenario is pending from our side so we can write the unit test for that so that it will not come up with the because they think like a customer they have a lot of scenario we don't think like that right and in this way like always help them to decide the framework which framework is good and what are the benefits if you are doing these things best practices there are a lot of things like we follow this is just my suggestion guys thank you if you want to discuss more we will discuss offline I don't know where my actual screen is relative to that one okay there it's decided that that one's the screen it wants to put things on yeah help out yeah and then my it's not a race of the minor one is please do not forget to pick up your speakers to our after parties and then parties they are a direct issue for you and also I would like to remind the team of the community in the role of the press so we are going to come here and we will talk about that and now thank you okay welcome to 35 Fedora releases in about 30 minutes I have timed this talk and gotten it in 30 minutes but I have to talk really fast so I asked for more time here so that I could talk a little bit more slowly I still will try and go very fast it won't be comprehensive even with that but we should have the ability to hit some important highlights in the history of the Fedora project and some questions after and I think hopefully this will be fun for people who have gone through all of this informative to people who are newer in the project and or is interested and I think there are some lessons that we've learned along the way that hopefully we can not repeat our own mistakes and we can maybe other people can learn from them Dan all heckling should go later at the end of the talk I have a slide on that later you'll yeah I think said heckling should be saved for the end yeah this is me no time to explain if you don't know me come talk to me later I'll be happy to but you know I'm from the internet and stuff I have 85 slides here so I'm gonna try and get through them there's a whole bunch of stuff about the history of Red Hat Linux and the split to rel and all of that that's a whole nother talk somebody else's talk I wasn't there for the behind the scenes so this is gonna start with Fedora core one this is the basic format of the slides release name and number at the top a little bits of information around since I'm showcasing like the desktop wallpaper over here is kind of a visual focus on things desktops always been important to Fedora but it isn't the only case a lot of people are using Fedora for server use cases for other things for IOT there's a lot of non desktop cases as well so this shouldn't be left out but you know there's the visual flare of the wallpaper so that's kind of a big thing I have the kernel version over here and things like that like which init system is there kind of put some technical things in there the actual number like that's not important over here in events that's our big headline events we've always had a lot of different smaller events in Fedora as well those aren't listed there's a lot of things in Fedora and then I also have most active on the develop list that's kind of a way to kind of get some people's names up on the screen you may recognize some of those names as we go through that doesn't necessarily mean that's the most productive person that release but you know sometimes it is and they're also obviously a lot of quieter people who've done lots of work who don't get shown up here and a lot of people who deserve credit I also put the Fedora project leader's name up there which means my name will show up a lot doesn't mean I am the most important person but you know I get to be the face of things so there it is here at the bottom I have from some of my metrics the release popularity over time it's a little bit of a spoiler here but we'll go through that as we go and then some pop culture things they're just for reference as well I'll take a sip of water because here we go so you have flowers in a pond here nice quiet beginning for the background here so this is Fedora Core 1 and it was really basically what would have been Red Hat Linux 10 if that had been produced it was basically made entirely inside Red Hat with the same mechanisms it wasn't really a community release it was open source but all developed internally it's basically just the name Fedora Core put on what would have been pretty nice Red Hat Linux release and then there was extras which were a collection of add-ons that you could basically put on top of it and that was like that the community was welcome to maintain these extras on top of that but actually during this release a really important key thing happened which I think kind of set the tone for the project overall so AMD64 64 bit extensions for Intel architecture were brand new and it was kind of a server class like enterprise feature and so Red Hat was thinking that'll be a differentiator REL will have 64 bit Fedora will be 32 bit and people will obviously want to pay for that distinction there was a lot of worry about how people will understand like why to pay for REL why it's different from Fedora at the time so they were really looking for these differentiators but then someone in the community actually Justin Forbes who's still a kernel maintainer went and just working under his desk in Texas I think rebuilt everything for X8664 built a version of it and so I wasn't there didn't work for Red Hat at the time but as I understand it this caused a lot of people were unsure what to do should this be allowed should we say anything about it or whatever but eventually the decision from Red Hat was okay well look this Fedora community people are doing this we should accept this and so it actually became part of it actually officially released at some point as 64 bit version of Fedora and I think that kind of set things both for multiple different architectures and just for you know the Fedora community as an independent not just the community doing add-ons but something that can actually make fundamental change in the project and that was a really key early thing also I want to point out the logo here which is a little Red Hat thing which is funny to me because we're not supposed to use hats in Fedora again that differentiator reason which is funny because you know Fedora and also it looks like Red Hat's new logo that they after much expense changed the shadow man thing back to this little icon here so the next one Tet Nang there's a complicated process by which these names are derived and they have to relate to the other one and I've explained up at the top what the connection theoretically is there this is basically another like what would have been a Red Hat Linux release it actually looks very much the same there were some important technical changes under the hood had the 2.6 kernel back then that was a big jump and SE Linux was enabled Dan Walsh is here in the corner he can do a talk about that I actually have my notes that's a whole other talk and Dan Walsh is the one for that talk but a big question here is what does this community stuff mean how involved is the community here and so actually a lot of people talk to me about this IRC it was actually an email mimicking a chat log here that Mr. Icon Constantine Rebetsov sort of sent to show like this is how people are feeling red headers don't seem to get it but like it doesn't really we don't know how the community is going to engage here so yeah in the release announcement here like it's kind of presented by Red Hat here it isn't quite clear what the open source community as executive producer it says in the release announcement like what does this mean so yeah from the outside as a community member who is interested in this stuff it was all pretty frustrating people who are involved in CentOS and seeing CentOS stream and Red Hat's communication struggles with that may experience some deja vu with this it's the same kind of thing in a lot of ways so FC3 this one's a little bit of progress it says in the release announcement I don't have the release announcement there nope I don't but it says the foot or project and Red Hat would like to announce rather than Red Hat but the core is really still in all of our Red Hat thing there were some things happening the Fedora extras the add-ons were actually now you could get them from the same download server it wasn't a whole different thing there wasn't actually a central build system the build system was you would send your spec file your to Seth Fiddle and he would build it for you and then put it there but down things are happening there's like four times as many packages in extras as there were before so people were kind of coming together and working on that then FC4 same wallpaper is the only time we've ever duplicated the wallpaper and it's kind of a boring wallpaper too so oh well this release was I think the worst probably the worst the worst ever it took forever to show up and SE Linux was in a horrible state it wasn't usable it was very frustrating reviews were like this is all about features and no one cares about stability this is you know all the it was probably all true also the release engineering process wasn't very good and actually there were changes like midway through this long thing which meant that you couldn't install it anymore you had to install the original one and then do a bunch of updates like it was a whole horrible thing but there was a lot of exciting community things going on I may be biased here because I personally helped organize the first Fedora conference the Fedora user and developer conference in Boston and I think that was actually again I'm biased but I really think that was an important turning point because it was a lot of red hat people came and a lot of people who weren't red hatters and it all felt collaborative and friendly and fun and there was no red hatters telling people what was going on it was red hat engineers talking to other people in the community and trying to figure out and deciding what to do and people in the community presenting about how they wanted it to go and it kind of felt exciting and collaborative so that was a really nice moment there I think I'm really fond of this background I don't know I'm not a graphic designer but I looked at this and I was like oh look how fancy that is it's so I don't know somebody who is an artist made this one so an artist may be other ones too that's not fair but I so graphic so the big news with this release really is a story about Yum which you know the precursor to DNF now the Meta package manager so before this in the olden days there was just RPM and if you wanted to update your system you basically had to download a bunch of packages and hope you got all the dependencies and it was a whole mess so there were some tools developed to do that and red hat had a huge investment in the thing called red hat network and up to date which I think was just discontinued like several years ago but it was supposed to be like this was going to be again a monetization thing this was going to be the product and they put a lot of effort into it and then meanwhile people Seth Vidal took this thing that an open source project and put it into Fedora that did this idea of rather than just having to download themselves it would actually like figure out what you needed to do an update and retrieve all the things and get them from the mirrors and do it in kind of a nice polished way so you could actually have you just run an update and it would update your system it was amazing and so again as I understand it there was some inside red hat like consternation about this should we allow this thing what should we do with it it got put into Fedora and then eventually red hat realized okay this is actually better than the thing we have tried to develop internally and it ended up going into rel and being the update system for rel as well which was a huge kind of thing as well there was a letting go of the not invented here mentality and say okay like the innovation can come from the community it doesn't have to be something that we've designed at red hat even if it was something that was like contrary to where we thought we were going with our business plans we're going to take a leap with this and figure out how to how to work with it so that was really important although still like red hat has this director control I think in the release announcement that may have talked about that kind of thing again all the decisions for engineering this were red hat internal decisions made kind of I don't know I imagine some sort of shadowy back room but actually not but one funny thing happened here when this release came out that all the Fedora systems were on the same network as red hat red hat was a small company at the time and the release was I'm like an end of quarter some sort of important business day and all the downloads for this totally broke the network and ruined everything and Mike McGrath tells the story better than I can Mike McGrath is now the VP of Linux or something maybe even fancier title than that now Big Cheese says Dan and at the time he was the Fedora infrastructure lead but he didn't work for red hat he was a community volunteer he worked for a different company in Chicago and he was the main and the CEO of red hat at the time called in the FPL and was like who did this you need to get your system as men networking people right in here and so then Max Bivac explained well I could but you know he's in Chicago and also I can't tell him to do anything he doesn't work for us doesn't work for you so at that point very shortly I guess Mike was hired and then told to fix the problem so I don't know that's one way to get a job we also this is where the now classic actual Fedora logo was designed this was actually made by like a brand consulting thing and it took these ideas like the red hat marketing red hat marketing used to actually like do marketing stuff for Fedora and they came up with the slogan of infinity freedom and that's where this this come together to make the classic logo there I have some fondness for it but yeah here this is a wallpaper that a lot of people love when I was talking about that people like really oh that 3D underwater rendered one wow this is one of people's favorites here people also like the name Zod it was a whole in-joke thing we've got lots of in-jokes but this release actually happened on exactly the day that my second daughter was born so I don't remember much about this or several months after of that personally but you know I went back and looked there was still a lot of time happening between releases 218 days that's a lot more than six months there's a whole long story about why there was no Fedora foundation that's probably also a whole other talk but at this point the Fedora board became an official governance body before that there was a thing called the Fedora advisory board which was really just a mailing list where anybody could give opinions and nobody made any decisions but they actually made a constitution for the project that had the Fedora board as the governing body for it and it was a mix of people who are elected by the community and appointed by the FPL and the Fedora project leader had veto power over this structure there and now finally we actually have a mirror manager system which let me get a count so you can start seeing the statistics starting to happen at the bottom of the page there another nice paper there moonshine so this is a big thing here was core and extras got merged together so having that split not only was it starting to be kind of actually problematic practically it was you know showing all the frustration in the community and the stress between like who can do what and so on so Red Hat made another big decision again a lot of fighting with the internal wrangling that I'm not I don't know all the details of but eventually the decision was made we're going to merge these things together into one unified project we're not going to have this core and extras split anymore and it actually turned out to be easier to move all the stuff from inside to extras so basically core got merged into extras extras became the thing and core went away and it became a unified release this is also the first release with live images Fedora wasn't the first distro to do that but it goes way back to this cool also at the FUDCon we had again in Boston there we talked about this new file system called butter a fast thought should we make that the default and at the time we decided well it's going to be about two more years before that's ready so in about two more years we'll take a look at that werewolf seven was where these were brought together but eight was really the first community collaborative releases really felt like this was some ways this is actually the first Fedora Linux because it was not just released as a unified thing but it was actually planned and put together in the open as a community project so this was a really fundamental release here this is where the feature process which we now call the changes process or change process Ben cotton wants me to say one or the other and I cannot remember I'm sorry Ben plural or not so that was introduced and basically the idea is not that we should have a big bureaucracy but stop surprising each other with changes if you're going to do something big let's talk about it first and it would impact that we'll have it's not meant to slow things down or stop but just make sure that we're all talking together so that we can make things work the best they can this was a very very popular release there are still at least a hundred systems out there checking into the mirrors every day to see if we will release any more updates for this just in case I enjoy that we also this is where the idea Fedora spins came out this spin is kind of a version where instead of this is like the official one desktop release you have different ways of putting together the software into a different desktop different installation I think this is kind of fundamental to what's interesting about Fedora as a distribution we really try to instead of saying oh you wanted to make it different well you can fork it and make your own project that's based on it we say hey come into the project if you wanted to make your different version of it that works this way cool we have been trying to find a space for you to do that this wallpaper was the first one I think with a time of day feature so it changes over time this is the evening version here sulfur the features process brings us new features I guess we had a new init system here so this is another really interesting story so init system after the kernel boots brings up everything else responsible for making sure all your services are running desktop desktop starts all of those kind of things and so the old thing system 5 init script system v I don't know somebody can correct me on that later but that basically used a bunch of shell scripts that were kind of slow and buggy and inconsistent so at the FUDCon which was I think in Raleigh that time a guy named Casey Dolan stood up and was like hi my name is Casey I'm going to replace the init system if you want to stop me come to my talk and so people came and I guess no one ended up stopping him so Casey was an intern at Red Hat so he was a Red Hatter but this wasn't his job it was just something he was kind of doing for fun he wasn't working on the OS at all so this is kind of a community led improvement replaced it with did I say upstart here is the system that was used there and so that was an interesting thing that also went into Raleigh this is an improvement coming from the community that wasn't something that was started as a Red Hat decision there Cambridge Cambridge was actually going to be as I understand it the codename for the what would have been the Red Hat Linux 10 release so there was some wrangling to get it to be the Fedora 10 release behind the scenes even though nominally there's that link there that's actually the real reason this is called Cambridge this release is important because this is where the Fedora foundations came from there was that infinity freedom voice that had been basically somebody external to the project invented that and thought that would be nice which it's fine it's nice to have that support but it didn't really reflect who we are as Fedora and so there was some work on talking about who are we as a community and out of it these four foundations are still kind of used as our guiding principles today freedom friends features and first we're there so I think that's nice that was yeah I think Paul Frieds helped finalize that and I think Max Beavac as FPL really started this down that road there this is a special wallpaper I actually never had seen this lion before before I went and did this you had to have two monitors on a widescreen the lion didn't show up unless you had a second monitor there so so this is the icons for the four foundations and also around this time we did talk about Butteruf S again and decided it's probably going to be ready in about two years and this is actually it took us exactly 196 days two releases in a row here for this one I'm going to go kind of fast through the next few ones here we had the first Budcon in South America this is this is a pretty nice but boring release which boring can sometimes be good here I have a note that we had a beautiful new website and I also see that I did not take a screenshot of the website but of Wikipedia this is actually not my screenshot I stole the screenshot from Wikipedia stole there's CC license information at the end of this talk it's not stolen at all I took but yeah there's a lot going on but this wallpaper very dramatic and I got a lot of people like is my screen broken on this one I love our community process that develops wallpaper but for some reason there's a tendency to make things that look like a broken LCD screen and this one got through here but yeah so behind the scenes in this release Jesse Keating who was the release engineer at the time did a big thing of switching everything over from using CVS as our version control to DistGit so that was a lot of big work there which is actually pretty neat technology at the time because Git does not do a good job at storing large binaries so that's like at the time Git was starting to take off in popularity but there wasn't like everything is on the Git forge somewhere there are people's various things everywhere so just like today our primary way of packaging things is getting the official tar ball and so you have this official downloaded binary somewhere and those couldn't really be stuck into Git so it's a clever system for that it's all pretty neat it was innovative things coming from Fedora and I think Jesse got a job at GitHub on the strength of all this work so that's and also because in that transition we I say we but I don't know Jesse probably somebody made a tool called Fed Package that basically instead of using the CVS commands it kind of abstracted all the package managing things so it didn't really matter what transition you were using underneath and we still use that Fed Package tool a lot as well and it kind of hides some of the implementation details and I think that's actually also kind of a nice lesson because change is hard so yeah you can see huge growth here we've got a nice growing growth trend around there things are going really well yeah so this really lovely wallpaper for this release this release is going to be great right I hear laughter from the audience here yeah so yeah uh oh goodbye to half our users here so there's not enough time to talk about whether system D or GNOME are good we could have a whole yelling fight about that but this is a lot of change all at once and I think if you look at these technologies today I think they're good this was the right choice to go in this direction but wow they were not ready and people were not ready and we actually went back and looked and I was like well could we have documented things better we actually put a lot of work into making this smooth there were videos about all this and it was like we tried but it was just too much change I think in retrospect like that Fed package tool if we would have worked on some things for compatibility and done some user experience things and it would have been a much better experience and it's always kind of a trade off so one of the things that we switched to upstart as in a net system before but there was so much emphasis on making it compatible that basically not only did you not notice any of the change we ended up just keep writing the same shell scripts for it and we never took advantage of any of the possible improvements from it so there's something where if you're focused too much on the compatibility it can hold you back so going ahead is sometimes important but maybe let's go this way again because that was not great this wallpaper obviously a reference to Jules Verne and 20,000 Leagues Under the Sea but I kind of can't help but feeling that the sort of murky depths and gloom was just kind of the feeling that my kids say the vibe of the project at the time and it was kind of depressing and so we got a depressing wallpaper here Jared Smith who is the FPL said that was the awkward teenage years so yeah that made me something to it what did I what architectures just wait sorry I'll fix my slide later I don't know why we dropped anyways the comment from the audience was I've accidentally left my arm off the list here and I should not but yeah we did consider ButterFS as the default file system this time and we considered we decided maybe another about two years that's going to be ready there was actually one big important change that happened here before this Fedora had a contributor license agreement where basically you said that you were giving and at this point and since that we've changed to a contributor agreement which basically says I've got the right to submit this code and it's under an open source license and if it doesn't have an explicit license you can treat it like it has MIT or Creative Commons license so it's not a thing that gives away any rights and so that was a change that I think made being a contributor not working at Red Hat is quite equitable there are a lot of open source projects which have a thing where you have to assign your rights to the company or to some entity that works on it and often that's kind of a unilateral thing where everybody outside of the special entity is bound by copy left it means if you make a contribution that contribution can be shared with anybody and so on whereas the entity can say oh I'm licensing this as proprietary software I'm going to charge a lot for it so even your contributions that are GPL for everybody else for us they're special so we don't do anything like that and I think Red Hat doesn't do that for anything I think that's pretty important that we got rid of that and I'm glad we didn't actually we're even looking at if that contributor agreement is even necessary for a lot of things there's a lot of cases where there's a concept called license in license out basically the assumption that when you're making a patch for something that it's under the right license just by making the contribution but that's for legal to figure out I would like to point out that on the DEVEL list here we have Adam Williamson is both the most prolific thread starter and the most prolific reply to those threads there I think that's yeah so things can't all be murky depths here so we had this release beefy miracle the mustard indicates progress the naming process again you can see that people were not afraid to bend the rules to get what they wanted in this one here I'm missing I'm so sorry that I've dropped the architectures well what am I missing now I think maybe that's supposed to say arm64 and armHFP whatever I told them to save the heckling yeah I told them to save the heckling for later but it's not working anyways many people describe this as their most favorite release overall and I think there were a bunch of features but I think the important thing really was just kind of the camaraderie and the friends foundation of this kind of fun themed release that was kind of a silly mascot and everything kind of even though things felt a little bit depressing kind of brought everybody together and the community felt like yeah we are we're doing something here so I think that was really a nice moment there in this release these tiny dots are actually circles because it's an idealized physics problem cow and the name nerd jokes in here this release was kind of a mess actually the installer code base Anaconda it had gotten kind of horrible it needed some serious refactoring which it got but that features process was very geared on what happens release to release and it turned out that rewriting the whole installer was something that needed more than one release to go through and we slipped all the way around from the fall release to January which was not great to say the least and also the Anaconda team that does the installer works on both Fedora and Rel and Rel didn't have an upgrade feature that's actually being worked on for Rel right now but at the time no upgrade feature and it was pretty important to Fedora but somehow that hadn't made the requirements at the very last minute we realized oh no there's no way to upgrade hey we kind of need that so Will Woods threw together something called FedUp which is a name that I love dearly I wish we still had that and this actually kind of accidentally set us on a good path really because it actually was a better upgrade process and from this we've really worked on making sure that the upgrades are really smooth process that you don't have to stress out about it's not a oh no Fedora's short life cycle means I need to give up two weeks of my life every year making sure the upgrade works it's just a hey run do the upgrade thing and you'll be on the next release and smooth sailing on so I think it actually turned out well through serendipity there but it wasn't the intended result another thing that happened around this time is we had a lot of pain with release engineering and I will not name names but one person had been doing most of the work in that area for a number of years and had ended up just from being very overworked the person who knew how to do all the things and no one else did and also some amount of pride in that like I am the person who knows how to do all these things which is totally reasonable and a lot of things in open source are kind of driven by that like yeah I have ownership of this is my thing but it can also be pretty unhealthy for that person and for the project so there was a lot of frustration and I don't blame the person at all this is a systematic this is a fedora problem that we hadn't really addressed very well because we should have found ways to support the person in that and found ways to make sure that they could have that pride in being there in a way that was about the team and the sharing and success of everything and so that's but it was definitely causing problems around that time I think that is kind of a repeated theme a little bit here again we've got their jokes here and these are boxes to put cats in the problems oh yes yeah so this is a good QQA thing it turns out that putting Unicode in the name exposed a lot of exciting things everywhere and actually I think this is the first name we had a space in it which actually turned out to be worse a apostrophe yeah right I think we solved the apostrophe by making it to a Unicode apostrophe so yeah great but yeah so all that is kind of fun but the biggest thing that happened around this release was really an immense tragedy so Seth Vidal who I mentioned before as a really important early contributor to the project he was called while biking home in a hit and run driver Seth was very humble and he would have downplayed this but he was so important to making Fedora what it is both in the community and in technology when I was we were both university sys admins at different universities and he helped convince me that it was worth the effort to be part of the community and give things back rather than work on my own and do things there yeah he was kind he was funny, he was brilliant and he was a dear friend and Seth would miss you very much this wallpaper it's a 20xx for 20 there in the background very subtle this release had a lot going on I was actually going to put a picture of myself wearing the 10 years of Fedora's shirt there but I decided if I was going to cut something out the vanity could go the badges aren't actually in that screenshot I just decided to plaster them there because they're fun so we launched the Fedora badges gamification thing which is something we're working on again and kind of putting more central a way to both bring people into the project find easy ways to get people hooked in different areas and also some people are very much driven by can I get a digital sticker for doing a thing we have digital stickers, it's very fun this is also a place where we decided we have the 10 year mark, it's time to do some strategic planning we started out great and then we had this big drop things are kind of taking up again we wanted to make sure that the next 10 years would be awesome basically so we flocked to a Fedora event we changed from this FUDCON and the idea Robin Bergeron my predecessor was the FBL had this idea that rather than having these little distributed events with no real focus we'd bring everybody in the world together to have a one big event where we would all talk about what we were going to do plan the next release and bring this together and so that was a focus of a lot of the strategy there Tom Calloway, Ruth Sealy did a lot to make that be a reality. I'm dropping names and I probably shouldn't because I know I'm missing a lot of amazing important people's names in this so if I left out a name I'm sorry you deserved to have your name mentioned as well but yeah release engineering comment here this was hard because of all the changes we were making around this but also this time the Fedora board had kind of faded into the background and kind of become there weren't a lot of big decisions to make but occasionally there was something like is this open sourcey enough would be raised and then the board would go off and have a debate and maybe come to a decision and then give a like a prophetic announcement that wasn't the question asked and it wasn't really very functional so actually FESCO the engineering steering committee ended up driving a lot of the strategy work here this was so this thing called Fedora next we came out with having different additions one of the big problems that was causing a lot of stress in the project was the earlier strategy decided that the desktop release was called the default offering and then we had a lot of people who were contributors in the project and they mentioned way back at the beginning that there are a lot of people using this in server use cases not the desktop and with the desktop being the default a lot of the decisions were being made okay well that's what we're going to do we can just desktop oriented decision and so it ended up that people who had sysadmin interests basically felt like all they could do was complain that saying no no no was their role in the project and you know sysadmin tend towards being grumpy anyways so it was easy to exacerbate that so part of the idea here was let's not do that let's give a positive way for people who want to have these different use cases to work on fedora server work on iot work on what are these different cloud use cases and say okay you can make the decisions that are right for your use cases and have them even if desktop can also not have to try and say I'm going to make sure that I placate the server needs for this very different use case for here so we can have these different decisions so I think that's worked out really well some of the other things fedora rings not quite there yet but so they get all the architectures right this time peter now okay awesome did not still still got the list wrong um um yeah go ahead let's do it that is another talk but the three additions is three additions is what were fedora server fedora workstation fedora cloud the time so we've expanded from that but that's basically that decision there yeah that's yeah so actually because of the release engineering problems and all that this is actually we decided to stop and actually we skipped a release for the first time and probably only time ever to kind of give release engineering qa time to like recover from that hard release and get the tooling up to shape to do things that turned out okay I think that probably staying on the cadence is something we should keep to that's a whole another big conversation um yeah a lot of people were skeptical about this additions idea which is very fair um it was a big change um I think uh that idea really worked we can kind of see as these things go up here like um it was a hard decision but I think it has been see a lot of growth in the project and that that that strategy and approach made things better in the community and made the release a lot more popular um and um yeah this is where as part of that strategy we decided to have a brochure site get fedora.org and we're going to also have something that went hand in hand with this a contributor focused site that was going to be a thing called fedora hubs the idea was um there were like eleven hundred IRC text chat meetings every year and a lot of stuff on mailing lists but if you looked at our website and everything that maybe somebody who is new to the project might come and look it looked like we were dead they would look like there was no activity on the internet happening because you know the internet had changed from being something that was a lot of these different text based protocols to you know the web and social media and those kind of things were really uh becoming the focus of what people thought was the internet and so the project didn't really show up so we wanted to have kind of a social media view of showing all the activity um that turned out to not work so well um but um that's um another talk but um we kind of come back to that idea later of making sure that the project is visible and um activity is surfaced um Josh Boyer says that he was the blame for killing the names here but really um so we stopped having the fun code names uh the reason is we were coming up with these lists with these tenuous links we would take them to legal they would review the you know ten candidates and say these two that are the worst possible ones you can use one of those and then that was like we were using quite a lot of legal resources on that so fine we decided okay that's it's not it's fun but it's not worth it for that we have to find our fun in other places I'm sorry um yeah um I mentioned that the board wasn't really working um not just that it wasn't very active but um it wasn't very connected to the project so we had made this you know three editions decision the board actually approved that went through this whole process of that um and then at the flock conference a little bit later we were in a room like this and a lot of people were like no one made that decision that wasn't official and like it was supposed to be official um so like that like clearly when you have a community led project a community driven project you can't have top down decisions that just declare things it's got to be something that's connected in order to understand okay here we have a process for decision making the decision has been made and it wasn't really working very well so we came up with a new structure called Fedora Council um it maybe also could use some improvement but I think it's worked pretty well where it tries to draw people who are involved in different areas of the project into leadership and to have a more active um not just a um behind the scenes governance and dispute um resolution but actually active involvement in leadership in the project um we also got rid of the exclusive veto for the throw project leader by going to a consensus model where effectively everybody has an equal veto on something and we have to figure out how to all get along on things which actually has worked very well we have never gotten to a difficult situation where you haven't been able to reach a consensus um how to do consensus that's a whole other talk I would love to do but again I'm actually running way over my time here because I'm going much slower than I was going to um one thing we did add um we have a thing called the fcake the Fedora community action and impact coordinator that is something Robyn set up and is one of the reasons I've been able to be Fedora project leader for so long it is no longer just one person isolated there's a kind of another full-time person to help with community building and activities in the project which is um very very very helpful um yeah um I can talk also about why that's not called community manager and a whole other talk which I will not do right now um change things up Fedora uh KDE Plasma desktop here um we got a diversity inclusion advisor I think that's something um I would like that to be a fully paid role I can't convince red hat to do it if anybody else can come up with funding for this I would love to have that be a fully paid role um yeah a lot of things going on here I'm gonna go here XFE spin here um a little bit of working in marketing Fedora loves python here um one of the things that happened around here though I would have brought the docs team kind of got into a situation where it turned out where we hadn't been paying attention and one person had become the docs team who had all the docs team knowledge and docs team work and that person got burned out and suddenly we didn't have a functioning docs team in the project and again this is not that person's fault it was something we're structurally like it was going along so well um we weren't really paying attention and giving them the support and the team the support that they needed um so uh um yeah here was a really short release cycle this is something we decided on purpose because previously when the release had drifted we decided we said okay well we'll go six months from now to the next release and that was causing releases to rotate all around the calendar and be unpredictable so we decided well we're gonna stick to the fall the October May release cycle and even though that this will be short um it turned out to be an okay release despite that there wasn't a lot of changes that all worked out well um and people actually really liked this one it got a lot of really good press which was very encouraging to people who kind of went through those awkward teenage years you can see in the graph here this big there kind of I think the things we were working on people started to take notice and be like hey this is what's going on in Fedora these days um Peter Robinson I have you name dropped here uh you said you made yourself redundant for secondary architectures we got rid of this idea of having a whole another process for some of these other architectures and kind of merged that into the main thing maybe I have the list right this time who knows yeah alright I got the list right too so that works out um this is I think my favorite wallpaper I it's beautiful um this is actually not my voice print it's the designer Kyle Conway saying Fedora in a voice print of that and then that becomes the trees and it looks pretty um we got a new mission statement I'm not going to harp on that too much but I think it kind of goes back in a lot of ways to that thing about spins and where we try to make it so you can you can as Fedora as a project we want to make something you can use as an end user but we also want to make it easy for people with ideas about how to make an OS how to make things better how to work on those ideas and deliver those to people um it goes yeah uh from Fedora next rather than just like handing out a bunch of building blocks um we also we want to give out some pre-assembled things but we also want to give people those building blocks and like hey you can make your Lego set and give that to people that's um something that we try to empower as a project um modularity is it's whole another retrospective talk I'm not even going to touch it um we finally got mp3 playback patents software patents are a huge impediment to free software um our basic um tactic is to wait them out which is um not not a great way but we actually waited this one out so there we go um yeah um yeah the modularity thing was a little bit of a stress um this was um this release took took way too long um or the previous release took way too long we made this one short again um modularity was really the fire here and again that's another talk here but um yeah a sugar on a stick which is um I user interface designed for children to be intuitive it's actually kind of amazing because you put this front in front of an adult and they're like I don't understand how to computer anymore and you put this in front of like a four year old and they're like whoa so it's it's it's actually it's great um uh this is another we broke the laptop screen wallpaper I don't know keep doing that um so this is actually the first ever perfect execution of our planned release schedule we were um you know exactly on time um and the modularity thing actually landed so that was nice um part of the trick here was dropping alpha releases so um quality team a lot of work around that um Ben Cotton as program manager I think it's a lot of credit here as well um and uh less good here we had somebody who had been you know working on the websites team who over time became the websites team and had kind of felt he had ownership of everything and once again like he was doing such an amazing job with it that we didn't really pay attention to that and uh when he got a different day job suddenly we didn't have a websites team and uh it turned out then when I went to Red Hat and said hey um can you we need to we need a websites people and they were like no that's not important for rel um so that was a whole crisis about how are we going to have a a nice pretty website um so yeah actually it turns out that um this should be a whole another thing we actually have a nicely revitalized community built websites team that made a beautiful new website if you go to fedoraproject.org now it's amazing and that was really