Jenkins User Experience Special Interest Group, 16 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Jenkins UX SIG Meeting 16 Mar 2022

Description

User Experience Special Interest Group March 16, 2022.

00:00 - Introduction
01:24 - UI improvements general - Jan Faracik
04:10 - Documenting Javascript and CSS for developers - Daniel Beck
10:00 - Demonstration of symbols
16:15 - UI samples plugin examples and improvements - Jan Faracik
27:30 - Redesign of the "New Project" page (use a dropdown) - Jan Faracik
38:00 - Code coverage plugin refactoring - Ulli Hafner

A

Then I'm recording now so hello, everybody. Today we have march the 16th and we have our user experience group meeting and yeah on the agenda. I have actually only three points, so the first thing is the weekly status, the 339- I don't know if someone can say something about it. Can you say about it, something tim, it's the weekly so because I'm not involved otherwise.

B

We skip the topic.

B

A

Too exciting, okay, then, I would like to skip this point, and then we have only two remaining things. Actually, only one thing is uh the ui improvements from jan and tim. If you have some thing to share and if there is still time sorry, if there is still time, I think I can share some details about the refactorings I'm making with a student of mine in the code coverage plugin.

A

Okay, then yeah, let's start with the ui improvements right. uh Jan, would you like to share your screen sure.

C

What's that, um I think everyone can see my screen.

C

Yes, awesome, yeah, um so yeah and what's what's recently happened um so right now, we've got three merge, quests up um one for the buttons which slip work in progress, one for the updated breadcrumbs um and then one more for the uh icons.

C

um So the breadcrumbs apr should be merged soon and I'll just update the kind of drop down links that we have across jenkins and then hopefully the icons should be relatively soon with the next week or two um at a push. um That's that's pretty much a little bit on the pc right now is.

B

The model inside this thing an issue that daniel was asking about, or.

C

um I'm not seeing if he's responded, um I think I'll just have to see how it works with plugins. um I've not personally checked plug-ins for it. So I'll have to have to see if that's a bit dodgy or anything but.

B

C

Yeah, I would have I.

B

Would have thought it would have noticed if it was dodgy, but you know it used to be in the j in a plug-in, but I removed it recently. Well, here's daniel.

A

Yeah, maybe it makes sense to document this behavior somewhere in our developer, hello, hi.

B

We spoke your name and you came.

C

um Yeah I wanted to get that documented on the jenkins, um dev docs um and then also add it to the ui samples and plug-in which I'll I'll get done. Hopefully soon.

B

Yeah, that's the only reason I hadn't clicked merge. Yet, um as was they're talking about the breadcrumbs one, daniel.

B

On whether we want to hold off any time or just yarn, we'll in the background, do some documentation and have a look at those plugins.

D

Because of model link inside copy and paste or yeah, okay.

B

Yeah, I think it's done a whole bunch of random plugins. I think generally copied and pasted all over the place, but I haven't seen anything that looks weird.

D

I mean this seems to be just one part of a larger. It seems we're fairly light on documentation, kind of situation and.

D

Something else that I thought about is it probably makes sense for us to think about sort of the the api or contract for plugins like, for example, css classes. Perhaps we could introduce a naming convention there. That indicates whether something is internal use only or intended to be used in plugins. So it's really obvious for someone who knows a very straightforward rule to tell well, this should not be used in plugins and it's kind of akin to using restricted api in java, something along those lines.

D

Now, maybe maybe this already exists, and I'm just unaware it does. I don't know when there's two underscores or an exclamation point or something in the css class, but um perhaps uh something like that is, is also what we what we could do there.

D

uh I just fear that we introduce a bunch of changes here and plug-in maintainers for one thing they do not know what they need to fix in their plug-in.

D

uh What version of jenkins introduced the change like, for example, I mentioned something you know in which version of jenkins did we add an icon that you want to use? Well, you need to look at the git history for that um and then they might end up copy and pasting a bunch of stuff where we say well. This was kind of internal use and now your plugin screwed in the next release, because we are changing, changing it again to make it cleaner in core.

D

So a few for me related um topics here, so um I'm I'm looking forward to having that documentation. I don't, I don't think it's an immediate prerequisite, but perhaps for the nearer term, future.

C

Yeah um for the css one, um I've been trying to prefix um kind of global kind of styles, with just the jenkins kind of word um and then for kind of internal classes. Just prefix like app or something just so plugin developers don't use it as it might. Change um might not be the best prefix but kind of that's what I've been doing at the moment.

B

It's probably just worth writing that down I'm doing style a little bit. I don't really know how you can how you document css classes when they're available so much unless you have a whole public api documentation.

C

Yeah, that's the tss, basically um yeah. I need to hold bunch of documentation.

E

Just perhaps do not care too much about that. We have seen a lot of copical copy paste of code that should not be copy pasted in the past that are private or jenkins core, but people are still copy pasting that for their own plugin, when we are collecting a vulnerability in core that plugin is still using the forked version. That is not corrected with the vulnerability, so for css, it's even easier for them to copy the stuff.

E

So I will propose you that if you want to have something reusable create a jelly component, otherwise do not expect people to not use your stuff. They will do it at some point. So it's not your fault. So.

D

Right, but if, if a css class is core internal whatever we can tell the plug-in maintainer well, maybe this wasn't the best idea. You've ever had look at what this says right: it's right. There sure it will not prohibit it, um but at least we give people who want to do it uh the right way, a chance to get it right.

E

On the opposite direction, there is there any css class from core that we expect plugin to use.

D

Modeling inside.

A

What do you mean with expecting, so there are a lot of classes that I would like to use in my plugins, for instance, the table uh visualization. I simply would like to have my tables implement jenkins table.

A

D

E

In that case, you have a component, no.

D

No, it's just a table that has the css class pick table pane, oh yeah, sorry ball and a few others. At least it used to be until fairly recently um model link inside. If you want the drop down next to a link to a build or whatever or the classes, to put there um and there's just a ton of that and uh some plugins do their manual task implementations where it can be. This debated whether that's a good thing or not, probably not because there's uh the task tag, um but there are several.

D

What is just is part of the definition I think, with the widgets in the side panel. You also need to assume that you're in a table environment and need to add a need to start a row or something so there's quite a few of those yeah good example. Thank you.

C

um I've got a couple of have things to to demo. Today. That's all right.

B

Should we look at the symbols just briefly and see what people are thinking? um Did you want to open the pr quickly.

C

B

I found something that you can do now. If you go to um paul's, you can just put your name at the end. So if you go to your url bar and just.

C

B

And then just put your name there.

C

All right, um so I've got the uh pro.

C

B

That I said I updated the change log this morning because it's not doesn't just, I think originally, it was just about the side panel. But as soon as you touch the side panel, you touch all over the place, so just change it to update icons. I'm not sure if you want to be a bit more descriptive, but um previously it said side panel, which is touching a lot more.

B

um I think so. Early you've done a whole bunch of feedback recently, which I think has been mostly addressed. If you want to go down.

A

B

Yeah, I'm not sure if there's anything else that we want to do in this pr.

B

If anyone else is planning to test I've had quite a bit of a go around it last night um and well, like I experimented with the gray color, I'm not sure if it's just too light or not, because it looks really good on dark theme on regular theme, it looks okay, um but I see it it's more.

B

For me, it looks more weird when it's mixed in amongst other icons, um which is something that we can improve as we go, but yeah, I'm sure what do other people think if a people tried this looked at it recently.

D

So so it's no longer blue, or what do you mean.

B

uh It is black in the side column and it's blue. If it's inside, of a link which we've tried to avoid um the context, menu is still blue and that will be fixed on a follow-up.

B

But no in general, they're um black or like a gray on dark theme, I think.

B

uh So that's like that's an example. If you guys do yarn, if you go, young goes to the top you'll see what they look like.

B

It's not a full black, it's like 333. I think.

A

Yeah, I I think on the the side panel side, it looks okay with the black. What didn't look so good, I think, was the summary poncheli's which are rendered in the middle. This was a little bit too black for my opinion, but yeah. This is something which is quite different for people, some like it, some like it not so maybe I can change it via a theme.

B

I think part of that is just about it fitting in with it there's not very many of them fitting in it looks quite different.

B

And then the font font awesome ones are quite a lot lighter. I'm not sure if that's something set by you, if it's just that font torso mic on the lighter yeah.

D

B

D

I mean if we all agree that we want to have these monochrome uh icons everywhere. Then the exact shade of gray doesn't really matter. We can iterate on that. It's just if the. If the feedback ends up being well, it was more colorful and nicer before then. We're kind of you know stuck with it um and can't go back, and otherwise uh you know the exact shade of grey. We will iterate forever.

B

Yeah, it's fine. I think it's good just to hear that it was more just about the summary panel rather than the side panel, which I didn't pick out from the before um but yeah. I guess so. We've got four approvals, um three of them from people testing it recently. So I'm not sure if there's anyone else that plans to look at it and provide any feedback or whether we should look at shipping this um during this weekly.

D

I mean um I would like to take another look at this one. I mean I've now approved the other pull request with the drop downs, so we can definitely include that didn't go out yesterday, right. That was okay, so so we can definitely have that in the next weekly um and then the question is whether this needs to be in the same weekly um could go either way. So I would like to take another look at this one.

B

Sure yeah, we can wait for that. uh I think there's probably quite a lot of stuff. That's related to this. That will come out once this is there so um improvements and iterations.

B

um This will be based on quite a lot of other stuff.

B

Cool, I guess that was all I had on that one yarn. If you wanted to show your demos sure.

C

um A bit just to retweet redirect what tim said. There will be like a million kind of pull requests after this just to just iterate and change the odd icon here and there and and fix things because no doubt will be kind of issues somewhere, but it'll get better yeah.

B

I've I've got a decent sized pr to the credentials plug-in to utilize it there, because that was one of the main ones that looked quite out of place.

C

um I've also been working on a branch just to add the custom symbols, so kind of plug-in developers can add their own, um so it should fit in a lot better at that point, um but I'll open that up for this question once this one's kind of merged in.

C

So a couple of things um I've been working on since the last uh meeting um doing a bit of work on the ui samples library. um It's still, it looks like a mess just because the custom icons aren't being loaded on this branch, um but it's got a bit more content. Now, um it's a bit more categorized so trying to keep things kind of really simple um kind of addressing it towards a first time, kind of plug-in, developer, um so kind of calling things like just check boxes rather than the jenkins name.

C

For that, because jenkins has some kind of odd choices for component names, but trying to keep it kind of straightforward. um This is like the the buttons page.

C

So ideally it shows you different types of buttons you can use um and also show you eventually the code to actually use these buttons on your plugin.

C

So we've got a page for colors as well.

B

If you just go red button, assume we don't still use a hidden flash, swf or whatever.

B

It says something like I'm sure, I'm sure I mean some flash on that page somewhere, yeah positioning.

E

B

Flash movie, I'm sure you don't do that anymore.

A

So one questions uh one question to these: uh widgets: are these useful in every context of jenkins, or only in the configuration page.

A

Because I'm using, for instance, a lot of widgets in my static analysis, plugins and in the configuration of trend charts, for instance. So.

E

A

If I can use these things as well or if these are just bound to the configuration section of a freestyle that.

C

These are useful anywhere, ah okay yeah, so you don't need to use them anywhere, really um yeah this. This ui samples package is still very much a work in progress, there's still a ton to add um and code samples and stuff like that. um So if we click the colors and we'll show you all the colors that jenkins currently supports, so you can use them in your charts, for example, or whatever else. um This branch is missing, quite a few colors, so it's a bit broken, but that's what it looks like right now.

C

um If you hit say text box, you'll get different text boxes, you'll have different scenarios, so this one supports autocomplete. So if we start typing a state, you'll you'll get examples.

C

um We've got the code for this, although right now it's just broken. um We've also got the the code mirror text box, so you've got the syntax highlighting and stuff like that um got a page for tool tips. So when the tool tips branches is updated, you'll be able to use this for your plugins and stuff. um Just again, things are quite broken just due to the branch of jenkins I'm running um but yeah. um So that's the ui samples.

C

It's just going to be a kind of, hopefully better organized version of the the one we had before any questions or ideas or anything.

B

C

Need help with that yeah I'm open to anything really.

A

C

A

Really helpful, uh because, typically, I want to know how to cut can I do something and I look into other plugins and the other plugin makes it wrong, and here I can look how to make it right. This is a really good idea.

C

um One thing I'm struggling with right now actually is is how do we kind of print the jelly kind of code on the page without jelly actually like rendering it is it like attack to shoot.

B

I'm sure there's a raw tag or something right wedding might know.

E

The g uh g column row out directly that should be able to display directly the thing you want now, if you are finding a way to automatically display that, instead of having to code it yourself that could be even better.

E

I'm thinking especially about some of the popular framework where you have all the things in the code directly, perhaps it's not the level of detail we want to have for jenkins, especially for that small plugin in your sense, but that could be good, but normally yeah j out should be the the good thing. If you want to include anything inside just be careful, do not include xss, it should be nice.

C

But yeah I'll try that after this um yeah, that's the uh ui samples, hopefully something'll, look a bit sharper.

B

um So I think we've talked about this before I think so. This is probably more important than documenting stuff on like genghis io is improving this, but how like raising the aware, I guess it's kind of pretty more important to focus on improving it right now, but raising the awareness of something like.

B

Should this be automatically installed in jenkins core? Should this be moved back, it wasn't jenkins core. Originally, I think, should we move back to jenkins core and an extension point added, um so that plugins can contribute to it, because no one's going to update it if it's, if they're not forced to as part of their change, if they add a new component, are they going to add a demo to it? If it's in a separate repo, um are they going to maintain the docs if it's separated like does this belong as a separate repo shouldn't?

B

It be a demonstration of how to build like we can hide this from users unless they're running a development road or with a flag or whatever that sort of thing's quite easy. um I don't know if anyone's got any thoughts on that.

E

What could be the advantage of having that in call directly.

B

So that, when someone makes a change to that component as their document, they make the documentation change with their feature change. They introduce a new component, they document the component as part of their change and they can image and they can demonstrate their change there. Even if it's something that's for another plug-in, they can show in the ui samples that this is how it would be used, and this is how it's worked, and this is how it works.

E

Yeah also easier to do in your pull request. Previewing this kind of thing.

B

E

Was just a bit concerned with the core size, because we have a lot of things inside core that are related, but not directly related to the code that make the full project a bit slow to compile this kind of thing. So.

E

Do you think about a module or what, in particular,.

B

Yeah, it could be a module for it.

B

um I'm not, I think, it's more important to improve it. So if we get it improved and we see what it looks like and then um so he really wants to have his plug-in data, I mean he could. I guess you could add dependency to ui samples, um api or something um but it'd be easier if it wasn't core- um and I feel I feel like I mean.

B

Obviously, this has drifted a lot if things like um flash was not updated when whoever removed the flash dependency didn't update, ui samples um but they're, probably more likely to find it or if it was more used.

B

There's a commit from ui samples plugin. I think it was split from core originally.

D

Yeah, it was part of core in until 1, 5, 35 or so.

B

D

So I mean we can go back, but perhaps it might be useful to understand the motivation. uh Seven years ago.

B

Nice commit message: jesse, oh yeah,.

B

um But there's something as a consequence to that. As you can see, it's had very little maintenance since it was split from core, so there's been base, there's been basically no change since it got split out of core it wasn't maintained.

B

um I mean we as core maintainers can say you've added a new attribute. You need to go update this, but um then you've got to manage hoops core versions and update the core vision over there and um lining up the pr's and then get someone to merge and release it um like tying. Your documentation to your code is more likely to get you a better result.

E

So perhaps a bit my effort just thinking loudly what about, instead of moving that inside core moving the thing from core outside the ui library that are used in core with strong binding with core for sure. But I think it's mainly that part of the code that should be close to that one, not really the full core.

E

So just thinking loudly, what do you think about moving out the library for the jelly component.

B

I think it can get harder to update people less likely to update um then they're less likely to create a component. um I guess an interesting idea.

B

B

And what happens when it fails to integrate? Someone does is change, someone merges it and then it doesn't get merged in um it. Does changes like someone can't roll out or change the ui samples, I've. I've worked with common lib sort of things before um and it makes things more aligned, but it makes changes more difficult and longer.

B

I don't think, that's something we need and.

E

I will bet that your common lib has not that strong binding with the rest of the code.

B

uh Well, it was a lot of ui stuff and then yeah, but I think it's updated one place and not the other place. Yeah yeah, not a lot of fun. um I think the focus should for now should just be on improving this. Let's make it nice make an exemplar, and then we can see. um Even if we don't move into core, we could possibly find a way to automatically install it through plug and palm something or or to test harness in some way. Yeah.

E

That could be very nice to have that for the of tooling in general,.

B

So a lot of people aren't aware it exists.

B

Okay, we got anything else. John.

C

Yep um something I've been playing with as a kind of redesigned to the new project screen, um just because it was it was quite old before um so. I idea behind this. One is maybe I was being done whenever I first started using jenkins. I'd often get confused between the fans, the ordering of of things. um It wasn't particularly clear. You had to click a project type. Then it looked particularly clickable.

C

um If you wanted to copy an existing project, type you'd have to scroll all the way to the bottom. It wasn't kind of immediately obvious that you could do that. um So I've tried to address that with with this kind of redesign um and also adds a new kind of drop-down component, which is a bit more visual.

C

um So I'll just give a demo really um just type hello world, um so you hit the new kind of drop down and it shows you this kind of pop-up list, um so the categories are kind of the project. Types are categorized um as before um the default jenkins. One has a new icon to fit, and it kind of looks just like that. Really um you select one which is freestyle and it pops up.

C

um So it's immediately obvious that you've selected a project to enter the name you can now hit create, so things are simpler. Really, um if you want to copy an existing project, type you've got this toggle here to click that and it'll pop open the copy screen. Really um so you hit this, and now you can kind of more visual view of your kind of current project.

C

um So I'll now tell you the type which I thought was handy. um I also have a little icon saying if it's passed or failed or whatever um not terribly sure, if that's helpful, but it's just to make, make it more obvious as to what you're actually picking essentially um so if we can hit freestyle projects and they'll just pop in like that, um that's it really.

C

um I think right now, it's a little bit broken so clicking create, probably won't work but yeah that that's that's the idea, really um any comments or feedback or anything.

D

um So one thing is you copy an existing project, not a type right? Okay, so this is a bit of a label issue right um then this needs to scale to at least a thousand projects.

D

So right now it's a text box where you enter a project name that you can probably copy and paste from a different tab or something as shown. This does not seem particularly scalable um as a comment for the other viewers. If you go back to the project type, um this grouping existed before. So, if you open it um standalone projects and the nested projects, this exists there, we just disabled it in jenkins2o and completely forgot to enable it again. So this has existed for five for six years now.

D

um So it's great to see this uh actually make its debut, um so this looks actually fairly reasonable. um I wonder how this scales now this doesn't have the same kind of scaling issue, but we should support. At least I think 10 15 project types is probably reasonable.

D

um I know that cloud b's products have a feature where you can add more project types fairly easily, and so, if this has kind of a hard cutoff at 10 and afterwards it becomes unwieldy. That would be a bit of a problem both for obviously the globby stuff, as well as if you have a particularly complex instance, with a bunch of plugins installed, several of which contribute new project types, but design wise. This looks reasonable.

D

um How is the I see the freestyle project icon is uh in the new style uh and the others are probably just compatible with what already exists in the plugins right, cool, yeah yeah. I mean this looks good, assuming the scaling can can is not a problem.

E

So in terms of ui, I will say it's very nice I will not say even reasonable, but very beautiful in term of style, very accurate, consistent with the rest of the application that you are rewinding.

E

You are improving the user experience in case of copy. My concern is just for the regular usage like I want to create a freestyle job at the moment. It's one click in your case. You have to open the select, then you will see the proposal and then you have to click. That's more about the ux.

E

At this point you are slowing down the process for people who know what they want to do, and this kind of thing for the beautifulness of the design is it's really good, not sure what you want to do with the the copy that you mentioned, that it was not really a good experience because it was at the bottom with you moving that to the top. It's a very good initiative.

E

That part, I would say, 100 percent, agree, agree with it's more about the select that you have one click more than the rest of the iteration and potentially even more because if it's not displayed in your first page, for example, if you look for something in the nested project, you will have to scroll before it was already displaying the page. Yes, you have to scroll, but it was displayed.

E

It's more about that level. I would say that could be a bit potentially annoying for some people.

D

I mean it's consistent with the rest of all web applications that are dumped down, so the same ui can be used for a phone as well as your 27 inch monitor.

B

Yeah, I'm wondering if there's a way that you can kind of handle both where you can have an expanded view in some way and a nice simple, clean view, it's kind of a lot of products he says have like wizards and even well.

B

He even may recommend you a project type, so you, instead of starting with this, you put in your git repo at the start and then um and you just like you start with your get reaper and that's it um or even even starting with your scm type, and then your get repo rather than just dumping you in here and taking you through all these other forms, um but also how like power, users who are creating a lot of pipelines. It can be quick, but for new users.

B

It's really nice simple experience, because I think this looks really nice and I don't know how often a lot of people create jobs. um I use multi branch pipelines for a long time. So for me, it's a very one-off thing. um Yeah and the other thing is on the copy. Even what you've got might be. Okay, if you've got 10 jobs or 20 jobs or to start with and then maybe it changes to more scalable components or there's gonna have to be some typing involved and even yeah.

D

So if you, if you can select the 10 projects or whatever, and then you type to filter it in some manner a bit like plugin manager, available kind of like we're doing it there right, you show the top hits and then you need to type to find something else.

D

um That would be, I think, a viable approach there. That would also mean it's uh less easy to get it wrong because there's some weirdness, if you start out inside of a folder and you provide a project name and the project exists on the top level, and the project name exists in the same folder.

D

How do you reference, which and with a more complete.

D

With the suggestions you show, that can probably be disambiguated because it might actually depend on where, where you currently are, there's a uh what's. It called uh inconsistency between various form elements that allow referencing projects, so that's actually something where it would be valuable. If that would be a reusable component like you can say um that we can plug into plugins like copy artifact, you specify a project name there. uh The the post build step that triggers another project right.

D

You want to specify something there and if that would be a reusable component, we can just copy into these plugins. That would be useful, but this this does look promising.

C

Awesome um so I'll um I'll write that down and try and iterate one of this for next time, um I'm trying to have something: that's a bit more scalable for larger organizations.

C

um That's basically everything I've got um so awesome cheers everyone um I'll, stop, sharing.

A

Okay, thank you. um Let's see I'll share again the again.

A

So yeah, basically uh we are finished with all parts of yarn. So if you still have some minutes, I can show you what we are doing in the code coverage plugin, it's more or less a little a feature. We are new uh extending, so it's not so ui yeah, only it's not only ui. So maybe I'm not sure if everything is interesting, but I will show you and you can choose on your own. So, let's see, I think I share the screen and show you what we are doing here.

A

Okay, I think I share my whole screen.

A

And here we have it, so you should see now. um I hope you see now my jenkins instance in the background, and I think uh I introduced our ideas for the code coverage plugin in the last meeting. So what we are adding now in the code coverage plugin is the first thing is a new coverage column which shows you the code coverage.

A

This is something I presented already in the last meeting, so I'm still, we did not finish the coloring thing, so this is still a work in progress, but what we now introduce or changed, we we started to introduce the kind of change coverage. Currently the code coverage plug-in reports, the total coverage of a plug-in or a project. That means you see. How is your line or branch coverage in your whole project?

A

What is uh for me it's more interesting if I am on a pull request, I want to see how good the pull request is. So what we are actually uh computing now is uh not only the project coverage which is here where you see how it's your product project standing.

A

We are also computing the coverage of a pull request. That means you, we are selecting only those files and only those of lines in those files that actually have been changed in a pull request.

A

That means here, for instance, we have a code coverage of 100 percent for the pull request and the remaining is yeah less than 100.

A

This is yeah, I think something which a lot of development teams would like to see just to focus on the differences and not on the whole thing.

A

So this is now new in the visualization that you see these two changes and what we are currently trying to redesign is the user interface. This is still not finished. It's just a work in progress now, so we have the overview, which is the project overview. What we would like to add is a similar overview for the change coverage.

A

That means you see only the delta of the coverage and what we also would like to show is we have this kind of a tree map where you see your your code coverage of the whole project, but I think, what's more important, is to have only the code coverage of your changes. So you see, these are the two classes I changed and the code coverage is good or is not so good.

A

So this is one thing we are currently changing and what we are also changing is um yeah. This is still not finished, so we are also having a second view where we see the individual files of your project and you see the source code now in a side-by-side manner.

A

That means maybe, let's see here, that means if these are my classes, that have a code coverage and now we have a selection here and you see on the right side, we have a let's say a master detail view where you select the source code you would like to see and on the right side, you see the code coverage of this source code.

A

This is currently your work in progress, as already mentioned, so it's not yet finished but yeah. I think the student is making a really good progress and it's you know a feature which I'm really looking forward to having it in the mainstream.

A

I think it will take a couple of weeks until it is finished so yeah just want to say: yeah have a look at it and the pull request, and if you have any comments, feel free to comment.

A

Are there any questions here? For this part.

A

Okay, thank you then yeah, I think I have no other items on the agenda is something else. Someone would like to add today.

A

Okay, then I think I am we are finished with the meeting today. Thank you, everybody and, let's see us on the next four weeks. Okay, bye, bye,.

E

Thank you for the organization.