WEBVTT 00:00.000 --> 00:12.200 So thank you, the next one is Otto, and he wants to understand the number of needs, which 00:12.200 --> 00:16.080 is understandable after talking about the number of needs on the five today. 00:16.080 --> 00:20.240 And he's going to talk a little bit about his research in 4th of June, if you're waiting 00:20.240 --> 00:21.240 to say. 00:21.240 --> 00:22.240 Yeah, thank you very much. 00:22.240 --> 00:28.440 Actually, we, for Joe Contributors, had a nice meeting yesterday, and we might have found 00:28.440 --> 00:34.880 a perfect way to integrate, design, and use a research into our issue tracker, and 00:34.880 --> 00:38.040 organize it in a perfect way, maybe we'll see. 00:38.040 --> 00:44.400 In any case, I will talk about the challenges we are facing, the things we tried, some lessons 00:44.400 --> 00:48.640 we learned from that, and how we arrived at the idea that I will present in the end. 00:48.640 --> 00:55.800 Yeah, actually, I do have very technically background, mostly in web development, and I would 00:55.800 --> 01:01.480 not consider myself as a designer yet, but I'm definitely becoming the user researcher, 01:01.480 --> 01:07.040 and that's primarily because I think that technology sometimes sucks. 01:07.040 --> 01:08.040 You agree? 01:08.040 --> 01:13.400 You hear quite some people laughing, I think some of you agree. 01:13.400 --> 01:18.400 In most years, I never really cared about user experience to be honest, because I mean, 01:18.400 --> 01:23.040 user experience, I mean, it's nice to have, but right after I'll fixing all the bugs, 01:23.040 --> 01:26.720 I will get to that later, I will also implement all the features first, and maybe fix 01:26.720 --> 01:29.560 all the accessibility issues that my software still hasn't. 01:29.560 --> 01:34.000 We can talk about user experience later, but the technical frustration I had with the 01:34.000 --> 01:38.560 like a very specific tool made me look into user research finally. 01:38.560 --> 01:44.960 Yeah, I'm also involved in a code brick for several years now, a code brick is providing hosted 01:44.960 --> 01:52.720 infrastructure for software development, like we decided that Microsoft GitHub is not the 01:52.800 --> 01:58.000 right tool to host a pre-librator software project, and it's actually very set how many 01:58.000 --> 02:04.560 free software projects still depend on large monopolies from the large companies of the Earth, 02:04.560 --> 02:10.000 some would even say the most evil company of the Earth, and yeah, we offer Git hosting, 02:10.000 --> 02:15.840 issue tracking, CICD, static pages, it's replaced translation platform, and much more. 02:15.840 --> 02:20.640 We're open to free and library software projects, and we're powered by donations and membership 02:20.720 --> 02:26.640 fees of our legal nonprofit association, we have about 1,500 members, most of them even have voting 02:26.640 --> 02:32.720 rights, so we're really basically the opposite of GitHub, but still working on open source software, 02:32.720 --> 02:35.600 and also only powered by open source software, which brings me to Fujayou. 02:36.240 --> 02:41.120 Fujayou is one of our project, of course, it's also a real resource community, but it's something 02:41.120 --> 02:45.520 that you can host yourself and something that could brick hosts. The history of this software 02:45.600 --> 02:52.000 project is longer than could bricks, but we fork this software over disagreement with the previous 02:52.000 --> 03:00.800 upstream. The nice thing about Fujayou is that it's a really nice community, and actually it's 03:04.320 --> 03:09.360 a fork is actually challenged, because you proliferate workflow, and you say, okay, can't 03:09.360 --> 03:14.560 we all agree on the same thing, can't we collaborate on what we do, but a focus also chance to 03:14.560 --> 03:20.000 question the established workflows, and the nice thing in Fujayou is that we did, and we changed a 03:20.000 --> 03:26.400 lot of things. We completely stopped depending on proprietary services, like group placed proprietary 03:26.400 --> 03:31.280 CI with a pre and library one, we moved the translations from a proprietary platform to library one, 03:31.840 --> 03:36.640 this is actually a nice idea, and the next thing that Fujayou does really nice, they 03:36.640 --> 03:42.880 pretty early agreed on doing user research. Actually, before I got involved, someone started doing that, 03:43.840 --> 03:49.680 and it was stuck for several years, but it was communicating that the Fujayou contributors 03:49.680 --> 03:55.200 are open toward this, which is actually very important to me, because since I've become a member 03:55.200 --> 04:00.480 of design and just speaking in a non-technical role, I actually see that a lot of developers don't 04:00.480 --> 04:05.440 take me seriously, and I'm very happy that at least the Fujayou portrait team does different. 04:05.920 --> 04:15.120 Yeah, actually, I wanted to get started, and I started reading about design. I mean, 04:15.120 --> 04:20.640 I use the research, and for me, coming from a design background, a lot of terms have been 04:20.640 --> 04:24.720 strange. I mean, probably designers don't know what would old technical terms mean, and I was 04:24.720 --> 04:30.160 confused about user research, user experiences or testing all these terms, and actually it's very 04:30.160 --> 04:36.720 sad, because they are not very much resources on the topic. I'm used to having tons of block articles 04:37.520 --> 04:42.160 that talk about how to do X in this technology, that technology, blah, blah, blah, blah, they they 04:43.280 --> 04:49.040 there's really a lot of resources about how to do technical things, but for free-level software 04:49.040 --> 04:54.560 for open source design, I went to the open source design website, there's the resource page, 04:54.560 --> 05:02.640 but a lot of things are just down, not found anymore, behind paywalls, and actually, I can 05:02.640 --> 05:08.640 recommend the e-beginner's guide to finding user needs from Yanditrich. It will actually help me a lot, 05:11.600 --> 05:17.760 yeah, it is free and liberal. And yeah, also a lot of articles kind of start with, like, 05:17.760 --> 05:21.760 this is how you convince your management to do user experience and user research, 05:22.080 --> 05:25.760 and this is how you increase your conversion rate, and just feels weird as a pre-software 05:25.760 --> 05:30.800 contributor to see a lot of marketing pre-phase, then I just want to know how I actually do it. 05:31.920 --> 05:37.760 Yeah, even after reading the book, I was still slightly confusing how I actually get started 05:37.760 --> 05:43.360 and what the first step should look like, and there was one very, I went, I was very tired 05:43.360 --> 05:49.520 in one specific Sunday evening, I was like, okay, maybe I'll just create the next cloud calendar 05:49.520 --> 05:53.520 appointment, I will just post it on MasterDone and we'll see. So I did, when just sleep, 05:54.240 --> 06:01.440 the next morning I woke up and I had a fully booked week, actually. I had about 18 sessions in one week, 06:02.480 --> 06:08.800 most of them booked overnight. It was definitely a great experience, I can recommend this to you. 06:10.320 --> 06:15.600 I was not prepared very well, I just just started it and improvised, and it went very well. 06:15.600 --> 06:20.640 I think the, especially the first sessions, they've been very valuable, because I learned a lot of 06:20.640 --> 06:28.320 things from users. If you're going to do that, I suggest that you just focus on like five sessions 06:28.320 --> 06:32.800 for a start and evolve over time, because I feel like the first sessions have been really valuable, 06:32.800 --> 06:37.520 and then it started to kinder become less valuable, but it's still very nice. 06:38.800 --> 06:42.720 Yeah, and at this point, I want to clarify that when I'm talking about user research, 06:43.120 --> 06:48.560 I'm talking about understanding users, and often I don't really know how to turn the things 06:48.560 --> 06:53.920 I learned into actual user experience improvement, but this is a separate thing, and even the things I learned 06:53.920 --> 06:59.360 about our users have turned out to be very valuable in certain decisions when thinking about like 06:59.360 --> 07:04.240 how to place a button. I can't know for sure, but I have a lot of data to back my 07:04.240 --> 07:07.280 and to make an opinion, an educated opinion, basically. 07:07.680 --> 07:14.480 Yeah, I also have been very surprised during the sessions, because I mean, I had a mental model 07:14.480 --> 07:19.280 of a user, like implicitly, and never really considered it, but in my head, all the projects 07:19.280 --> 07:24.000 use this kind of look like me, male, maybe young, somewhat skilled with the technology, 07:24.560 --> 07:28.960 and yeah, of course this was partially confirmed here, and we use a research, but I was also 07:28.960 --> 07:36.080 told different, because there are a lot of things that are different, and especially some 07:36.080 --> 07:40.560 users really have no clue how to use our software, because they used to other platforms. 07:40.560 --> 07:45.360 I never considered that, because I knew that people are coming from GitHub, but some people 07:45.360 --> 07:48.640 haven't even changed to GitHub yet, they are used to completely different workflows, 07:48.640 --> 07:53.520 only over locally, or they are ledger to make contributors without any tech background that are 07:53.520 --> 07:57.920 just, just edit the file here, you will figure out your way, but actually file editing in 07:57.920 --> 08:04.240 for jail is super complex, if you use a rep UI, because it was created with this developer's 08:04.320 --> 08:14.800 in mind, and not people who have never used Git. Yeah, and I started evolving the user's things 08:14.800 --> 08:23.680 that I did, I did user testing, I did user testing, which basically means I led users, 08:23.680 --> 08:29.040 user software and observed with the challenges they see, but I also did user research using 08:29.040 --> 08:33.680 other platforms, I think it's really valuable to see users using other projects, not only 08:33.680 --> 08:41.680 years, so I've seen people using all the source for just on Earth probably, I have done a lot 08:41.680 --> 08:47.280 of interviews just asking about what actually trying to do, how do you organize your project, 08:47.280 --> 08:53.520 what would work well for you, and just learning about what they're trying to build. I gave them 08:53.520 --> 08:59.200 tasks like just do this, and I observe how it does, like my personal favorite is create an 08:59.200 --> 09:04.640 organization and then the user treat. People fail miserably because it's really complicated, 09:04.640 --> 09:09.440 but I've learned how where users expect to, how to add a user to the organization, because 09:09.440 --> 09:13.680 they click somewhere, it doesn't work, but at least I know this is where users click, if they 09:13.680 --> 09:17.200 want to solve this task, and maybe I should make it just work the way they expect it. 09:18.320 --> 09:23.920 Actually, I even gave users tasks that are impossible or not implemented yet, of course, 09:23.920 --> 09:29.920 I resolved this quickly, but just to see where would users expect this new functionality to 09:29.920 --> 09:34.160 how to work like, and this was also very valuable insights at some point. 09:36.000 --> 09:41.520 The last thing that I did sometimes was, especially for setting, that are really complicated, 09:41.520 --> 09:46.720 it was like, okay, imagine you could create the settings, and you just overtake objects that 09:46.720 --> 09:51.200 you have a mind is there, how would it look like, and then they told me how they would configure 09:51.280 --> 09:55.920 a project, and of course, it does not work this way, but at least I now have a mental model of 09:55.920 --> 10:01.680 how our users expect there, I don't know, repository settings to work. This is also really 10:01.680 --> 10:12.000 valuable in my opinion. The thing that I did next is actually evolving this by different things 10:12.000 --> 10:17.600 and communicating this, and I usually did raw transcripts of my sessions, I highlighted conclusions, 10:18.560 --> 10:24.560 I tried to scale up the team with more designers, but this also brought some challenges. 10:25.920 --> 10:34.400 For example, the challenge of them, not completely being aligned to our free library software 10:34.400 --> 10:39.680 ideals, they were just often like, can I use Google Calendar, and of course, this is not what we 10:39.680 --> 10:45.680 want to do, but yeah, and the next challenge that also prevented designers from getting into user 10:45.760 --> 10:50.720 research and project is that we have a lot of complexity. I mean, all the design guides that you 10:50.720 --> 10:55.200 have, they basically show like, this is how you reuse a research on a web app, and everyone can relate 10:55.200 --> 11:00.800 to it, that you get a task, and I understand what the user is doing, but if I asked the user to just 11:00.800 --> 11:08.240 do something, they are not doing it with a theoretically simple way, but they are doing it in 11:08.240 --> 11:13.520 their very complicated way, and they tell me about very complex needs about their complexity, 11:13.520 --> 11:19.200 ICD pipelines, and how they integrate home automation with the iPad lines, and very complex 11:19.200 --> 11:24.720 stuff, and sometimes like one challenge for me, if I do a screen share, and observe the user doing 11:24.720 --> 11:29.600 something, they are just too quick, they just switch between apps, they are typing files, and I do 11:29.600 --> 11:34.800 they use tools that I've never seen before that abstract, the thing that I'm used to know, 11:35.360 --> 11:41.840 even with my technical background, I really fail to understand what users are doing there sometimes, 11:41.920 --> 11:47.920 and I try to invite some of the project developers into doing user research, but they're not 11:47.920 --> 11:53.520 going to do it, we have to be honest. Yeah, so the things we do is really, I really 11:53.520 --> 11:59.040 are trying to understand without having domain-specific knowledge, and I really need to integrate 11:59.040 --> 12:04.560 our developers into the tool chain, but they're not going to spend a lot of user research sessions. 12:05.280 --> 12:10.800 So, the second challenge that we have is the issues that we have, and they are of a 12:10.800 --> 12:16.640 writing quality, of course, some people write very robust text, have very complicated ideas, 12:16.640 --> 12:22.720 some write very brief, and over time I realized that, at least in my opinion, the workflow that 12:22.720 --> 12:30.400 most free library software projects have are actually not working very great, and I will ask 12:30.400 --> 12:34.480 you question to the audience, if you raise your hand please, please keep it raised even for 12:34.480 --> 12:39.840 the second question. Like, have you ever been, have you ever created an issue, or like you 12:39.840 --> 12:44.400 probably already created an issue in some project? Have you ever been confused about whether to 12:44.400 --> 12:50.080 file it as a back or a feature, please raise your hand and keep it raised, did you choose 12:50.080 --> 12:53.840 something that did it wrong, please raise your hand in addition to it, like keep your hand 12:53.840 --> 12:58.960 raised and close it, okay, and if you're maintaining a project, have you been ever annoyed 12:58.960 --> 13:03.840 because someone did it wrong, and filed it the wrong way, he also some people are annoying, 13:03.840 --> 13:09.760 he actually backs feature requests, does this, this is actually a good idea, and I started 13:09.760 --> 13:15.920 to question this, and I realized that actually these things are rather modeled around finding 13:15.920 --> 13:21.280 a solution. Like, if we, if we ask for a feature request, we ask the user to think about what 13:21.280 --> 13:26.400 they want, without describing the problem, and sometimes we have things that are really not 13:26.400 --> 13:30.320 clear. I mean, people write, I need this button, and if you ask why do you need it, 13:30.320 --> 13:35.120 yeah, because it does not exist yet, but the actual, the actual thing behind this is like, 13:35.120 --> 13:39.360 what do you want to do with this button, and in the software we have, I mean, it's really old, 13:39.360 --> 13:43.840 it was inherited over a several projects, we have a lot of features, and all who we know, 13:44.560 --> 13:49.360 like the discussion that led to the implementation of something, we don't really know why 13:49.360 --> 13:52.960 it was actually needed and which purpose it served, there was like a discussion to implement this, 13:53.040 --> 13:58.400 it was accepted, it was implemented, but we have no clue why, and which purpose it served, 13:58.400 --> 14:07.840 and people abuse it in very different ways. Yeah, and I will show you something here, 14:07.840 --> 14:15.600 this is how I perceive this to work. I mean, people suggest a solution, and my favorite is about 14:15.600 --> 14:20.880 single sign on thing, so people suggest to put custom text on the sign in page, because then they 14:20.880 --> 14:28.080 can tell users to how to sign in, or you have to disable local lock-in. Without, we don't know why, 14:28.080 --> 14:32.480 but people asked us to disable local lock-in, or they wanted to disable the lock-in sources, 14:32.480 --> 14:37.600 certain of them, or they wanted to set the default lock-in source, or they wanted to redirect 14:37.600 --> 14:42.240 to a specific lock-in page, but the actual problem, all these features requests, all these 14:42.240 --> 14:46.960 just one problem, because if you have a company and you have a sign in with, and you still have 14:47.040 --> 14:51.680 a local lock-in, people will fill the local lock-in with their credentials, or they should 14:51.680 --> 14:59.040 click on sign in with my university, or sign in with my company, and all these problems, 14:59.040 --> 15:03.360 basically solve the same problem, and some of them solve it even in a bad way. For example, 15:03.360 --> 15:10.720 disabling local lock-in would prevent you from having a local admin account or a guest sign, 15:10.720 --> 15:15.200 and so if we implement this way, we also need a different solution to the same problem, 15:15.280 --> 15:20.640 the same with auto redirecting, and some solutions actually address different problems. 15:20.640 --> 15:25.520 For example, here, the actual goal of disabling local lock-in was that users 15:26.240 --> 15:31.360 that are still able to configure a different lock-in source, or set a password, even if they 15:31.360 --> 15:36.800 are not supposed to do that. So they try to solve, like, actually, a different problem this way, 15:37.840 --> 15:43.680 if you don't know the solutions are supposed to solve, I mean, the future requests only look at 15:43.680 --> 15:49.120 this, and we have no clue what they're actually supposed to do, and I think this is a big problem. 15:50.720 --> 15:56.240 Yeah, the, oops, sorry, I just, and the next problem I was pacing personally was that 15:56.240 --> 16:00.240 developers have motivation. I mean, if we have paid stuff, we can just tell them to work on the most 16:00.240 --> 16:04.880 important issues, but actually our developers have personal motivation, and they're naturally 16:04.880 --> 16:10.080 opaque, the tasks that are interested in. And so even off a label, a lot of issues, and they're like, 16:10.160 --> 16:14.320 this is really important, no one picked them up, because no one was motivated to work on these tasks. 16:15.200 --> 16:19.840 On the other hand, developers have been really motivated to work on something, but I was not doing 16:19.840 --> 16:24.240 research on them, because I mean, it's probably still important, but I can't do all the things at the 16:24.240 --> 16:30.080 same time, and I had no clue what developers are actually interested in working on. 16:31.120 --> 16:35.440 Yeah, so there was a mismatch between what I was doing and what the developers were doing, 16:36.320 --> 16:43.600 and so my idea was to integrate the research into the issue tracker. I tried to split the 16:44.320 --> 16:48.960 problem description from thinking about the solution by using like two different templates and 16:48.960 --> 16:56.240 suggesting where people should start, and yeah, and try to involve all the developers into 16:56.240 --> 17:03.680 trying the different issues. And the problem of this work was basically that a lot of 17:05.200 --> 17:11.360 users were confused about where to start. They used the wrong templates, they were really angry 17:11.360 --> 17:15.600 at us, because they were like, I've never seen such a complicated process in an open source project, 17:15.600 --> 17:19.840 I just want to file my future request, please. Yeah, and some contributors also did not really 17:19.840 --> 17:24.080 understand the workflow, which is of course not bad if you want to have like all people like 17:24.160 --> 17:30.880 Rean workflow. And actually it was lost for like several weeks now, or like actually 17:30.880 --> 17:35.920 months, about thinking how to solve these problems and iterating on this, tried to change 17:35.920 --> 17:39.680 wording in the templates, explain them slightly better, but yesterday we had a meeting with 17:39.680 --> 17:44.320 some for jail contributors, and we actually had a very nice idea, and it's really lucky that we 17:44.320 --> 17:51.120 talked about this beforehand, because now I had was able to accept my talk, and what we are now 17:51.120 --> 17:56.880 trying to do is we clearly define stages, because I mean different types of issues are somewhat 17:56.880 --> 18:02.240 hard to communicate, but like a process that follows certain stages is much easier to follow. 18:03.840 --> 18:08.960 We try to create shortcuts so that people don't feel like they always need to go through 18:08.960 --> 18:16.240 complicated workflow, but they could fast-track certain things. And what we do right now is basically 18:16.240 --> 18:20.560 splitting issues into what is actionable for developers, and what is like still in the process of 18:20.560 --> 18:25.440 being worked on, and a lot of projects implicitly do this by having like a separate forum from 18:25.440 --> 18:31.600 their actionable issue tracker, but I feel like an issue tracker allows has the power to cluster 18:31.600 --> 18:38.400 things with labels. Like this is only an example, I have much more research labels where just cluster 18:38.400 --> 18:44.480 issues, and say yes, I want to look into how, for instance, this configured, I have a lot of users 18:44.480 --> 18:48.640 that are confused about how they can filter for issues, pull requests, whatever, so I have 18:48.720 --> 18:52.160 a cluster everything that is related to this, and so on, it really helps me 18:53.280 --> 18:59.680 specify the various described problems. I have illustrated the workflow that we are currently 18:59.680 --> 19:06.960 trying to go for, so users actually start here, and they file an issue by describing a problem, 19:06.960 --> 19:12.560 and only describing the problem, ideally, and the issue is in the triaging stage, and every 19:12.560 --> 19:18.640 project contributors is supposed to take a look at this, and decide, like is it a really simple 19:18.640 --> 19:23.360 problem, like is it something that we are completely sure about how to work, and we just did a mistake, 19:23.360 --> 19:29.520 and it is broken, so we can directly label the issue implementation, and some developer knows, 19:29.520 --> 19:33.920 okay, I will fix this right away, because it just clear how it's supposed to work, it just needs to 19:33.920 --> 19:42.000 be done. If not, then we usually enter research, or we want to enter research, I mean the research, 19:42.080 --> 19:46.000 that is from yesterday, we of course did not try the ad, but we want to try, 19:46.000 --> 19:50.640 understanding the actual need of the user, and collecting more data, and also finding like 19:50.640 --> 19:56.080 other problems that users described that could be related to this, and once we have gathered data, 19:56.080 --> 20:03.040 we want to enter the design stage to draw conclusions, and only when we are satisfied, and I mean 20:03.040 --> 20:10.400 design does not only mean technically design, but also UX design. Once it's described, we enter 20:10.480 --> 20:18.960 implementation, and the issue is ready for development. I hope this will work out. Actually, 20:18.960 --> 20:24.160 the other two arrows mean that we sometimes could create issues, because as I described before, 20:24.160 --> 20:30.400 like something could use this could describe several problems, and we want to have one issue 20:31.040 --> 20:36.000 that tracks the various problems into one issue, so we would start from scratch there. 20:36.640 --> 20:43.840 Yeah, and I'm really looking forward to trying this out, and I'm curious about what you think, 20:43.840 --> 20:50.080 and if you have any questions, just leave me no, let me know. 21:06.320 --> 21:11.200 I'm saying a lot of big questions. I'm sure you repeat the question, I think. 21:13.360 --> 21:18.480 You've been in this work, but it seems to me that this might react to it, so it basically depends on 21:18.480 --> 21:35.920 some of our first reports, and I think that's a kind of separate problem. We would, of course, 21:35.920 --> 21:43.760 prevent what you describe that we have a reactive workflow, but I think that, like, as a user 21:43.760 --> 21:48.960 researcher, I see that users describe a lot of problems in the issue tracker, and the problem that 21:48.960 --> 21:54.560 I'm trying to solve is specific to making use of this data, because it's currently not really used 21:54.560 --> 22:01.120 in my research, and that's a specific problem I'm trying to solve, and what I, of course, 22:01.120 --> 22:05.840 hope is that this makes our software better and avoids UX problems in the first place, 22:05.840 --> 22:11.840 but in my opinion, just not replaced having a UX designer who gives valuable input about 22:11.840 --> 22:17.840 how to design features in the first place. I think what you address would fit into the design stage, 22:17.840 --> 22:22.880 and would be very great to have more input into the design stage to be currently, 22:22.880 --> 22:30.880 don't have a true designer, still looking for one. Oh yeah, sure, go ahead. 22:30.880 --> 22:37.120 I would like to know, as you mentioned, that developers like to work on what they like to work on, 22:37.120 --> 22:40.960 and then you have this take-a-existence, that is the solution to that problem for you? 22:43.280 --> 22:45.200 I'm not quite sure if I understand this question. 22:45.200 --> 22:50.800 Present that the solution that you came to, is that addressing the problem that developers are picking 22:50.880 --> 22:55.280 up, okay? Yeah, the question was about whether this addresses a motivation problem, and I think 22:55.280 --> 23:01.440 it does, because this allows everyone to proceed. So like, if a designer, I like, if a developer wants 23:01.440 --> 23:08.640 to work on something that is just reported or they even reported themselves, they can now participate 23:08.640 --> 23:18.480 and moving this forward without requiring the user research team to help with that. And I mean, 23:18.480 --> 23:23.200 of course, it would help if we synchronize our team members, and I know what others are motivated 23:23.200 --> 23:30.080 to work on, but currently, the words for that we previously had basically depended on me knowing 23:30.080 --> 23:35.040 what someone wants to work on, and then doing the work. And now I hope that this allows the 23:35.040 --> 23:40.400 project developers to also do the workflow, and it does not depend on me knowing what they want to do. 23:40.400 --> 23:47.760 And yeah, I think it does address at least part of the problem. Yeah. 23:47.760 --> 23:55.760 Hi. You basically have a focus on labels for the user's engineering, and that's paid for the 23:55.760 --> 24:04.080 questions following. In this workflow that you propose, do you think that using labels will be 24:04.080 --> 24:09.120 fine for starters for going to work for like this, or do you expect that you're probably 24:09.120 --> 24:13.520 going to have to make a policy case with Brazil itself, so support this portfolio. 24:13.520 --> 24:18.080 Yeah, the question was whether it's workflow works well with Foggio, or if you have to add 24:18.080 --> 24:23.120 something. And I mean, of course, I designed the workflow basically around what we have, 24:23.120 --> 24:28.160 and I'm pretty sure that we will see challenges. For example, the filtering options that 24:28.160 --> 24:34.880 we currently have in Foggio don't make it quite easy to support this workflow, because you 24:37.040 --> 24:40.960 because you can't, for example, have sub-labeled, and so on. That's what would be very useful to me. 24:40.960 --> 24:46.320 But I have used the labels actually not specific to this workflow. I've used them in the past, 24:46.320 --> 24:51.440 and I think it's possible ready to work with the labels and cluster issues this way. 24:51.440 --> 25:06.080 Okay, yeah. I think this is mostly too for their contributors to the type. This is, okay, 25:06.080 --> 25:11.840 yeah, whether like who decides how we go from triaging to implementation, and this is actually 25:11.840 --> 25:16.400 the decision every day for their contributor could make, but I mean, at the moment, 25:16.400 --> 25:24.320 like the matter is, like if someone is looking at this, and they have the technical knowledge to 25:24.320 --> 25:30.160 to know that this is just the way this intended, they would just set the label the same as 25:30.160 --> 25:36.720 currently people are moving the feature request to box and vice versa. Of course, there's a chance 25:36.720 --> 25:44.080 that someone clarifies the box as, okay, it can be implemented, and actually the feature that 25:44.160 --> 25:50.560 is broken would need to redesign anyway, but I think the chance of this happening is low enough. 25:50.560 --> 25:54.800 And I mean, given that we can sometimes just have like a few comments discussing this, 25:54.800 --> 25:58.240 and it's just a consensus of like three contributors to move it forward, 25:58.240 --> 26:03.280 then we don't have to, you know, enter all these stages. Thank you very much for your attention.