WEBVTT 00:00.000 --> 00:11.680 Hello everyone. I'm Elizabeth I am the lead Pakistan developer for Rhino Linux. This is my 00:11.680 --> 00:15.680 first time at Boston and I'm really excited to be here and to give this talk. Thank you everyone 00:15.680 --> 00:20.240 for coming here and everyone on the live stream and we're all really excited and honored to be 00:20.240 --> 00:23.440 the first talk of the day in the community room. 00:23.440 --> 00:28.480 Hey everyone, I'm Adam. I'm Vfanda and desktop lead for Rhino Linux. I'm so excited to be back here 00:28.480 --> 00:32.480 at Boston giving another talk. We aren't here today to talk about the technical side of Rhino 00:32.480 --> 00:36.880 Linux but rather the personal side. Some of the challenges we face as a team of young developers 00:36.880 --> 00:40.480 and hopefully we'll have some lessons to take away from this but before that there's still one more 00:40.480 --> 00:45.600 person who needs to introduce themselves. And I'm Warren and I'm the systems lead for Rhino Linux. 00:45.600 --> 00:49.520 This is now my third year in a row giving a talk at Boston and like the others I'm quite excited to be 00:49.520 --> 00:53.920 back on stage. As Adam said this is going to talk about the technical side instead we want to 00:53.920 --> 00:57.840 retrace the human side of Rhino Linux and how we learn to build a team of young developers 00:58.480 --> 01:02.560 as well as what this project has continually taught us along the way about maturity, communication, 01:02.560 --> 01:06.720 and sustainability. We recognize that our talk may not apply universally to broader burnout 01:06.720 --> 01:11.360 and developer culture rather as the demonstration of our specific case and how we have worked 01:11.360 --> 01:16.000 to overcome it. However we do still hope that the lessons we have learned along the way can 01:16.000 --> 01:21.040 impart translates to that broader scope. Before we fully begin I'd like us to give a brief overview 01:21.040 --> 01:24.320 about who we are as developers and how we ended up in this space together. 01:26.880 --> 01:31.840 Yeah so my background stems from full stack web development. I was 12 when I decided my first 01:31.840 --> 01:36.240 website and that began my journey tinkering in and around the web space. Eventually I made the 01:36.240 --> 01:40.400 pivot from solely for an end development to full stack and continue to learn and try to master 01:40.400 --> 01:43.760 my skills in that space and then definitely that seems to be impossible with a new framework 01:43.760 --> 01:48.880 releasing monthly. It was around 2020 but I developed serious aspirations to move into full stack 01:48.880 --> 01:51.840 development as a career and began working towards that goal ever since. 01:54.320 --> 01:59.360 Coincidentally 2020 was all to be ever I discovered Linux which kick started another obsession of mine. 01:59.360 --> 02:03.600 I began to play around as much as I could with Linux in my spare time and my exploits eventually 02:03.600 --> 02:08.160 led to me creating my very first distribution. The eventual predecessor to what became minor Linux 02:08.160 --> 02:12.560 and for more on that history you should read the hour-fost them talk from last year QR code on screen. 02:12.880 --> 02:21.440 So I got into Linux in 2013 when I was 8 when my dad got me a Raspberry Pi. I wanted to play 02:21.440 --> 02:26.560 Minecraft like everyone else in my grade and I didn't really know what a computer was and it 02:26.560 --> 02:34.000 technically is a computer so I used it. Eventually I started writing scripts in Sonic Pi which is how I 02:34.000 --> 02:40.400 got into programming in the first place. And then around 2018 I got a full desktop computer that I 02:40.400 --> 02:46.800 continued customizing and rising as much as I could. And then in 2020 I was bored one day and how 02:46.800 --> 02:51.760 most projects start with being bored. I just decided to write something so I decided I was 02:51.760 --> 02:57.120 going to write a package manager in bash or at the time I called it a pseudo-package manager 02:58.080 --> 03:02.880 which eventually turned into Pakistan. And then I came to Rhino Linux through working with Adam 03:02.880 --> 03:08.560 on his predecessor distribution rolling Rhino remix and when it came time to deprecate that in 03:08.560 --> 03:16.240 time for Rhino Linux, Pakistan formed the core package manager of it as a source of distribution 03:16.240 --> 03:22.640 upgrades with our Rhino meta packages. And finally I was born with a keyboard in my hands. 03:22.640 --> 03:28.080 My father's professor at MIT and had me as a test subject from very early on. He created the 03:28.080 --> 03:33.440 education oriented programming language star logo TNG alongside Mitchell Resnick which influenced 03:33.440 --> 03:38.320 Mitchell to invent the far more familiar block based language scratch. And so as such I was one of 03:38.320 --> 03:42.720 the very first kid users of scratch and it massively influenced how I view an interact with code. 03:43.440 --> 03:49.520 Much of my coding regardless of the language feels very much block based under the hood. 03:50.080 --> 03:53.680 I built my first PC with my father at around five or six years old and gave my first 03:53.680 --> 03:58.640 talk at a conference with him at 10. And because of the environment that I grew up in, I've been using 03:58.640 --> 04:02.800 Linux from a majority of my life and have always seen it as just another operating system. 04:03.600 --> 04:07.280 And that first custom build ran Linux Mint and like Elizabeth, I've worked on many 04:07.280 --> 04:11.360 iterations of the Raspberry Pi. As such and as I have mentioned in my previous talks at 04:11.360 --> 04:16.560 Phastem, I have a very long term affinity for Ubuntu. And I've always been a tinker, finding 04:16.560 --> 04:20.960 great joy and putting software where it shouldn't necessarily be. And this drive is what initially 04:20.960 --> 04:25.040 brought me to Rhino Linux, where at the time I had been working on porting Ubuntu touched the 04:25.040 --> 04:31.760 pine phone pro. So from the moment we announced Rhino Linux to our initial release 10 months later, 04:31.760 --> 04:37.040 we worked at an incredibly fast pace developing most of our applications, workflows and roles 04:37.120 --> 04:42.960 very early on as a scope of Rhino Linux expanded rapidly. And we mistook our speed for progress 04:43.520 --> 04:47.600 because we were getting the job done. So we didn't really bother to check up on each other or 04:47.600 --> 04:52.880 document our work. And as such communication between each other was minimal, since we didn't end up 04:52.880 --> 04:57.360 crossing the boundaries of our core roles that much. So we could only assume that everyone else was 04:57.360 --> 05:03.520 doing the work and just continuing on a fit. And the car was technically on the road, but 05:04.160 --> 05:07.760 it would end going in the right direction. So we didn't really bother to check if anyone actually 05:07.760 --> 05:12.720 had their hands on the wheel. We were all students and teenagers at the time with no real 05:12.720 --> 05:17.760 responsibilities. And with a lot of free time on our hands, we kept saying yes to more bold ideas. 05:17.760 --> 05:21.680 We were cruising on borrowed time until the moment came when we actually had to manage our work 05:21.680 --> 05:26.560 life balance with Rhino. And retrospect, this was one of our biggest pitfalls as we designed our 05:26.560 --> 05:30.320 process season pacing around the environments that we were living in at the time as students. 05:30.400 --> 05:34.160 We didn't know how batter system was and how on maintainable the pace we adopted would actually 05:34.160 --> 05:38.480 become. We had no reference for what a functional development team looked like and no real plans 05:38.480 --> 05:42.400 besides the present. We just had to ship the damn thing and deal with the followed another time. 05:43.840 --> 05:47.760 This system worked for previous smaller projects that we had worked on like-pack stolen 05:47.760 --> 05:51.840 rolling Rhino remix. But those were no-in there for scope of Rhino Linux. I was working 05:51.840 --> 05:57.120 style should have changed when we began maintaining an entire series Linux distribution. But it didn't 05:57.200 --> 06:00.800 early signs of problems began to arise in that communication between each other and there should have 06:00.800 --> 06:04.480 been an immediate rev flag. But we kept ignoring it until about eventual moment when it would 06:04.480 --> 06:07.760 become a much larger problem and only then will we be forced to deal with it. 06:08.960 --> 06:12.960 As the project began to slow down paths for honeymoon phase, concerns began to arise about 06:12.960 --> 06:17.600 our pace and the future of our development. Team Dynamics rapidly shifted as a couple of our initial 06:17.600 --> 06:22.240 large contributors primarily around our applications development dropped off or left the project 06:22.240 --> 06:26.640 entirely. They're missing presence in that space is still felt to this day and we had to pick up 06:26.720 --> 06:30.880 the work ourselves. This has only put more pressure on the team and we struggled to figure out how 06:30.880 --> 06:36.320 to sustainably expand our ranks again. The structure we built created a lot of roles I need to be 06:36.320 --> 06:40.160 fulfilled and we could not take on all of them but we had to or else we would have to drop certain 06:40.160 --> 06:48.880 things that people had come to expect from our district. It was around this time that our team 06:48.880 --> 06:52.960 disciplines surrounding release planning steps and our use of canbambles faded away. We got into 06:52.960 --> 06:58.400 a burnout feedback loop. Overwork, withdrawal, resentment, repeat. This feedback loop then became 06:58.400 --> 07:02.160 the basis for how we operated and worked together for a long while and admittedly it's been 07:02.160 --> 07:06.080 quite a struggle to break out of even today as we stand on this stage talking about it we still 07:06.080 --> 07:14.080 find ourselves stuck in this cycle. So the burnout feedback loop it first starts with overwork. 07:14.640 --> 07:19.520 As a team we've consistently taken on more work than we can handle at any given point and this is 07:19.520 --> 07:23.840 always been a source of struggle for us and leads people to first overwork themselves to meet 07:23.840 --> 07:28.800 the internal pressure that we put on ourselves and subsequently withdraw as they burn themselves out. 07:29.520 --> 07:33.680 Typically once this occurs another team member has come out of their withdrawal period whether 07:33.680 --> 07:38.960 by volition or necessity and is ready to take on that burnout instead. Being an active maintainer 07:38.960 --> 07:44.000 while everyone else is contributing less can be a frustrating and isolating experience. Especially 07:44.000 --> 07:48.800 if you or other members of the team have never experienced burnout before up until this point. 07:49.680 --> 07:54.080 Resentment can begin to develop and over time it will continue to grow until eventually someone 07:54.080 --> 07:59.200 snaps and that's exactly what happened. We had our first of many team arguments and it was neither 07:59.200 --> 08:04.160 civil nor pretty. Calls remarks and threats of resignation got thrown around very recklessly and in 08:04.160 --> 08:08.640 the aftermath a lot of us ended up withdrawing entirely for a period of time. It's easy to become 08:08.640 --> 08:12.960 very heated in the moment and taking a pause before applying probably would have made all of the 08:12.960 --> 08:17.360 difference. In the end the arguing didn't solve anything it only deepened the riff between us as a 08:17.920 --> 08:22.240 team heard our feelings and kept boiling that resentment. Moving on from our first few major 08:22.240 --> 08:26.480 arguments we decided to attempt a few changes to our dynamics to boost our team back to the 08:26.480 --> 08:30.560 productive and capable force that it once was as well as making sure that we began to foster a 08:30.560 --> 08:34.720 healthier development environment. First we put up a blog post talking about some of the difficulties 08:34.720 --> 08:38.880 that we faced and explained to our users that we would be taking a step back to focus on ourselves 08:38.880 --> 08:43.680 for the time being. We wrote a code of conduct compartmentalized our roles and tried to take on a 08:43.680 --> 08:48.480 just try to work philosophy. Title of this slide is resolution attempts because despite our 08:48.480 --> 08:52.960 tries we ultimately felt flat on our faces once again. We had hopes that bringing to light our 08:52.960 --> 08:57.280 issues would inspire others to join our team but this was not the outcome. We were desperately 08:57.280 --> 09:00.960 crying out to the world to help us while failing to listen to ourselves and what we had written. 09:02.160 --> 09:06.800 Admittedly though the tiny break we took did end up benefiting a short term with some of those 09:06.800 --> 09:11.760 benefits being almost immediately recognizable. We were talking more compassionately with each other 09:11.840 --> 09:15.840 and team morale was higher than it previously was. Everything else though, unfortunately, 09:15.840 --> 09:20.800 fell short. We never made any faithful attempt to follow our newly published code of conduct and we 09:20.800 --> 09:26.320 compartmentalized our roles and built up our silos of independent knowledge yet again. Truly believing 09:26.320 --> 09:30.320 that if we specialize in our respective areas further, then there would be less chance of friction 09:30.320 --> 09:34.960 as we were communicating less. What was an attempt to go back to how things were was crucially 09:34.960 --> 09:40.960 missing two parts. One we weren't the same people that started this distro and two our roles were 09:41.040 --> 09:46.000 not the same as they originally were either. Officially we had our own distinct roles but we never 09:46.000 --> 09:51.040 really stuck to them so when we finally decided to try and only work in those official roles 09:51.040 --> 09:55.440 we found ourselves stuck in a place that we were before. Our roles were incredibly lopsided 09:55.440 --> 10:01.600 and work and authority and we were simply entrenching ourselves further. Finally, I would just try to 10:01.600 --> 10:07.200 work mindset to addressing but not have some logic behind it, also very we fall. With the hope 10:07.280 --> 10:11.120 that once you get into the group of things you'll begin to find for work much easier and more manageable. 10:11.120 --> 10:14.720 We thought that it would be a wake up call and that just tried to work would be reason enough to 10:14.720 --> 10:19.280 get motivated and get stuff done. This definitely did not work and in fact probably caused us to burn 10:19.280 --> 10:23.680 ourselves out faster in the end. We had sacrificed long-term gains for short-term wins when we 10:23.680 --> 10:26.960 desperately need both. We could not find this over-bully that we were hoping for. 10:28.960 --> 10:33.600 So after a couple months of working like this we decided something needed to change. So it actually 10:33.600 --> 10:38.400 ended up working for us. We can boil it down to a philosophy of three words, allocate, 10:38.400 --> 10:43.760 collaborate and communicate. It became important for us to actually allocate pieces of work rather than 10:43.760 --> 10:48.960 just saying this needs doing and expecting someone on the team to do it. By doing this we could then 10:48.960 --> 10:53.680 set ourselves up to be in a better place to come together and then collaborate on that task together 10:53.680 --> 10:58.480 while each doing our own part. We have found that when we have instituted regular team meetings 10:58.480 --> 11:03.120 we see huge benefit not just in our productiveness but also in our communication. In addition 11:03.120 --> 11:07.280 Adam and I found last year that seeing each other in person at Phastem massively improved our 11:07.280 --> 11:11.600 relationship and so we began trying to emulate a similar atmosphere when we can't see each other 11:11.600 --> 11:16.080 directly face to face. It's very easy to lose your temper and insult someone who only ever appears 11:16.080 --> 11:22.640 as a little icon on a screen and it makes it just a bit more difficult when you know that person 11:23.280 --> 11:28.480 on a much more personal level and meet regularly with them. We focused more on becoming actual 11:28.560 --> 11:33.120 friends and recognizing when we were being rude to one another and in consequence we began to 11:33.120 --> 11:38.560 care much more about each other's thoughts and feelings. One additional thing we have noticed 11:38.560 --> 11:42.320 has helped us is communicating our issues to those who have been in similar positions to us 11:42.320 --> 11:46.800 previously. For Aaron he had his dad to turn to for advice relating to maintain about now 11:46.800 --> 11:51.440 and team dynamics. For me I had a colleague up my company who gave me some great practical advice. 11:51.440 --> 11:55.040 Reaching out to those with previous experience has been a vital piece to personal growth. 11:55.280 --> 11:58.960 For my name including the some stage it can be a struggle to work with in the team if there is 11:58.960 --> 12:03.440 no personal element to it and I feel like our previous mountains of dysfunctional communication 12:03.440 --> 12:07.840 and consistent arguing contributed heavily to my previous burnout. This will culminate it into 12:07.840 --> 12:12.320 us increasing our collaboration as a team instead. Previously we expected team members to work 12:12.320 --> 12:16.480 individually rather than as a collective and this mindset has consistently hindered us or let 12:16.480 --> 12:20.640 the stored releases of multiple of our intended deliverables as work has often dependent on a 12:20.640 --> 12:24.960 soul maintainer. We realized that coming together to work on tasks rather than having individuals 12:24.960 --> 12:29.440 work on separate issues led to faster outcomes and the overall workload becoming more bearable. 12:31.040 --> 12:35.040 Figuring out what really worked for us took a lot of introspection on Aaron. It became apparent 12:35.040 --> 12:38.960 that we had to take a step back and analyze the areas that we were following short. We had to 12:38.960 --> 12:43.520 acknowledge that we do not scale well and had to develop better systems for this. Over time we 12:43.520 --> 12:47.840 eventually realized that we are not good at saying no and consistently take on more than we can handle 12:47.920 --> 12:52.400 at any given point. We repeatedly make promises to both ourselves and our community that we do 12:52.400 --> 12:57.680 not grasp the full scope of, often providing unrealistic and unreasonable timelines for ourselves. 12:57.680 --> 13:01.440 We have a lot of grand and bold ideas that we want to implement but we simply can't deliver on 13:01.440 --> 13:03.680 all of them even if we want to say as to everything. 13:04.720 --> 13:08.480 Aaron is often a perfectionist and has had to realise when he is getting too controlling 13:08.480 --> 13:11.840 as well as learn how to relinquish some of that control. Guilty as charge. 13:11.840 --> 13:15.600 Multiple times this level of overbearing has pushed others on the team to consider leaving 13:15.680 --> 13:19.440 projects entirely. Although part of this problem does stem from the overreliance on 13:19.440 --> 13:24.320 Aaron as a primary developer in many areas, this is what many will refer to as verbose factor 13:24.320 --> 13:28.320 where in a hypothetical situation this person would get hit by a bus. The rest of a team would 13:28.320 --> 13:32.800 not be able to continue as before. The overreliance on Aaron in many areas has contributed to 13:32.800 --> 13:39.360 his personal burnout feedback loop. In other areas we had to recognise that the rules we originally 13:39.360 --> 13:44.720 carved out for ourselves weren't necessarily the right fit for us. For instance Adam had been 13:44.720 --> 13:49.600 considered the primary lead developer of rhinolynics with a large portion of that decision 13:49.600 --> 13:54.160 making pointed upwards towards him. But this wasn't sustainable for a couple reasons. 13:54.160 --> 13:59.440 Firstly he actually gets the majority of his enjoyment from website and desktop development. 13:59.440 --> 14:04.720 And secondly it overalied on just one person to make all of the decisions. Even when that person 14:04.720 --> 14:08.960 was no longer in charge of most of the development which were areas that had mostly been 14:08.960 --> 14:14.240 relegated to Aaron. Despite our arguments and frustrations at the end of the day we have 14:14.320 --> 14:18.400 grown to care about each other a lot. Over the years we have gotten to know each other on a deeper 14:18.400 --> 14:22.560 more personal level and have developed close friendships with one another. We have come to provide 14:22.560 --> 14:26.400 a friendly ear whenever one of us wants to open up about issues that are affecting us personally. 14:27.120 --> 14:31.200 We have found common interest between each other outside of development and within development 14:31.200 --> 14:36.000 we began to provide advice, test and contribute to each other's side projects. Over time we have 14:36.000 --> 14:40.160 come to respect one another as members of the team and recognise the individual contributions 14:40.240 --> 14:44.160 each team member provides to the making of this district. With that we have managed to form 14:44.160 --> 14:48.160 lasting friendships that have been able to hold steady on the rocky road of Linux maintainer 14:48.160 --> 14:52.720 ship. Larger groups have also reached out to us for partnerships. And while this has put an 14:52.720 --> 14:56.320 increased amount of pressure on us as a small team is kept as pushing forward and that's 14:56.320 --> 15:00.400 us know that we are still in large part moving in the right direction. Achieving recognition 15:00.400 --> 15:06.080 from projects that we have a huge deal of respect and admiration for has continued to motivate us 15:06.080 --> 15:12.480 even through our periods of extended bone out. And furthermore we love our distro and what it stands 15:12.480 --> 15:17.440 for is the only rolling release boom to base distribution which we recognise provides great value 15:17.440 --> 15:23.280 to developers who may use it for testing ground for upcoming boom to releases. So this isn't 15:23.280 --> 15:26.880 a distribution we're making for any other reason than our genuine love and joy for it. 15:28.240 --> 15:32.880 Going back to a state of before we believe that the three pillars of alicate collaborate and 15:32.880 --> 15:37.200 communicate are essential. So looking back here some of the things that we've learned along the way. 15:38.400 --> 15:42.800 Constant burnout and dipping out is not a sign of responsibility rather it is typically one 15:42.800 --> 15:48.080 of dysfunction highlighting underlying issues but it is not failure and should never be taken as such. 15:48.080 --> 15:52.080 Reflecting on what is resulting in burnout particularly with each other is a crucial step. 15:53.520 --> 15:58.000 Fearing out for problems that are affecting your team and its dynamics can take time. 15:58.000 --> 16:01.440 It's taken us while over two years to figure out what the problems are and to begin making 16:01.440 --> 16:05.520 some progress towards solving them. Despite this we still find it hard to avoid about how 16:05.520 --> 16:11.840 it's from time to time. It's easy to lose sight of yourself and your own needs and to put the end 16:11.840 --> 16:16.320 user before yourself but at the end of the day the developer matters most and the project can wait. 16:17.520 --> 16:21.760 Explicit expectations for each other matter immensely. It should never be assumed that everyone 16:21.760 --> 16:25.920 is on the same page. Be willing to step out of your comfort zones and learn more in depth about 16:25.920 --> 16:30.880 others areas within the project. However this relies on an important aspect. Those working in 16:30.880 --> 16:35.280 each of those specialized areas need to be documenting their work or will be incredibly difficult 16:35.280 --> 16:40.560 for others to pick up. Team project planning should be structured and them frequently. 16:40.560 --> 16:44.720 Early on this was one of our biggest strengths as a team but eventually we began to neglect it. 16:44.720 --> 16:48.560 Project planning is crucial for two reasons. One is that's for your expectations for the 16:48.560 --> 16:53.360 upcoming release and two is that it assists with team cohesion and allocation of work. 16:53.920 --> 16:57.440 On that note when planning every team should expect that as members will have less time 16:57.520 --> 17:02.400 available than originally anticipated in ideal situations and so you should account for that in your planning. 17:03.680 --> 17:08.720 And finally when you're starting a project that you truly care about and not some toy project 17:08.720 --> 17:13.040 it's okay to stop at the beginning and to get to know those around you to communicate as much as 17:13.040 --> 17:18.320 humanly possible and to not immediately set up roles and responsibilities because those should come naturally. 17:20.480 --> 17:25.680 Finally we realize that no adults in the room accept us now. We had to step up to our own play. 17:25.760 --> 17:30.480 We recognize that we still have a long way to go and that this is a substantial learning process. 17:30.480 --> 17:34.400 In the grand scheme of things we are still quite young as developers and so with Rhino Linux as 17:34.400 --> 17:38.240 a project having just recently passed out with free year anniversary of beginning work on it. 17:38.240 --> 17:42.720 We still have yet to solve all of our problems and we are still figuring out how to manage no 17:42.720 --> 17:47.200 longer having the time that we once did. We are still learning how to grow up. To that end, 17:47.200 --> 17:51.600 however there is no endpoint to growth regardless of the age of a project and its developers 17:51.600 --> 17:54.960 every project continues to grow up and team building is an eternal process. 17:56.000 --> 18:00.400 We have seen it and surely you have too. We are not the first ones who have had issues with scaling 18:00.400 --> 18:04.720 and we certainly won't be the last. Ideally older and more mature projects can be given guidance 18:04.720 --> 18:08.960 to younger ones. Older projects have already suffered through the scaling problem so they are 18:08.960 --> 18:13.360 great resources to look up to and reach out to for advice. As is the topic for this room, 18:13.360 --> 18:16.960 there are several other talks today revolving around tackling burnout and sustainability. 18:18.000 --> 18:20.720 And unlike close source and corporate development work, 18:20.800 --> 18:25.600 bosses extremely personal to the individuals working on it where people often have very specific 18:25.600 --> 18:30.240 roles and by and large the boss world is built through passion projects where that individualism 18:30.240 --> 18:35.520 is on full display for better or for worse. So we take a lot of pride in our work and many times 18:35.520 --> 18:40.800 when lacking pressure from the professional world it arises internally. In some, if you want to 18:40.800 --> 18:45.840 be systems maintainers, you have to maintain your own systems too. As always, thank you for coming to our talk. 18:51.280 --> 18:55.280 And now we have some time for questions. 19:05.280 --> 19:09.520 It's not really a question because I think you answer all my questions to be honest. 19:10.560 --> 19:17.280 It's hugely inspirational what you're doing. So just keep doing what you're doing, share with others 19:17.280 --> 19:21.280 because it's true passion and it's coming through. Thank you very much. 19:35.280 --> 19:41.840 I think so the talk was very inspiring. How we all prioritizing tasks and future releases? 19:42.560 --> 19:44.160 What's driving that process? 19:47.760 --> 20:07.280 Yeah, so typically we all get together. We like, or instead, we instituted regular team meetings 20:07.280 --> 20:12.880 and that's typically where we decide what we prioritize. We've started recently picking back up 20:12.880 --> 20:17.760 and using command boards, again, which I think is great. I'm a big advocate for them. So yeah. 20:20.000 --> 20:25.840 The can-bem boards particularly allow us to decide what is a high priority, what can we save for 20:25.840 --> 20:31.280 the next releases. It gives a very visual layout to all of the things that we're working on. 20:32.480 --> 20:37.920 And we can also organize it by which areas of the distribution they're particularly involved in. 20:42.880 --> 20:53.440 Thank you. I just want to say I really enjoyed that talk. He's really inspirational and it's 20:53.440 --> 20:58.880 really enjoyed the majority of the show. I've learned a lot as well from myself, but what I can take away from work. 20:58.880 --> 21:02.240 So I just want to ask what's the next step, what's next for Rhino? 21:02.240 --> 21:17.440 We still have plans to try to scale ourselves back up again. We know that we are here to stay for 21:18.480 --> 21:22.960 for a good time and we are still very much passionate about continuing the project. 21:23.760 --> 21:31.600 We do want to continue to try to figure out how we can expand our team in more ways, but we have learned 21:31.600 --> 21:36.160 some unproductive ways how to do that. So now we're going to aim for more productive 21:36.160 --> 21:41.120 manners of that, which we think starts a lot with documenting. 21:41.120 --> 21:45.680 Yeah. Any more questions? 21:48.880 --> 21:50.400 Thank you.