All right then, so thanks all for coming. This is sort of the closing session of the conference. I hope everybody's had a good conference. You know, yeah, annual blah, blah, blah with the board or kind of the annual discussion with the board.

This year, we're doing the format a little bit differently, mainly because we've been doing things a little bit differently. But just to kind of start with the very basics because I don't expect everybody here to know exactly what the board does. The OpenSUSE board, these five and me are the group in the project who are kind of

ultimately responsible for leading the project. It's kind of inverted quotes because, you know, you guys are in charge as the contributors, really. But we're the central point of contact, so if anybody knows who to get in touch with or someone wants, you know, just somewhere where it's OpenSUSE, the board is there as kind of the default contact point. We resolve conflicts in the community

when, yeah, whenever you have a problem, when nobody else can help, you know, contact the board. On the same kind of line of that, when it comes to decision making, you know, if there's ever a situation where contributors and the like don't feel that they, you know, are in a position where they can decide, you know, they need somebody else to make a decision for them, we're there, we're also the main contact point

for SUSE and vice versa. And this last line actually wasn't in our documentation, we'll talk about more of that later. But, you know, generally speaking, the board is kind of a source of ideas for project-wide discussions and new ideas and, you know, start that stuff

when we're thinking of changing things in the project. And, yes, I mean, we're all sitting standing here, but we had our board meeting this week where we were all, yeah, all in Prague and talking about lots of stuff. But, yeah, well, I'm skipping ahead. Before that, we introduce ourselves. So, I'm Richard, I'm the chairman of the board.

You all know me, I talk too much anyway, so next is Anna. Hi, I'm Anna, I started as a Google Summer Code student two years ago, and now I'm working for the open service front-end team at SUSE. I'm also involved as mentor in the mentoring

and now the board, and I think that's enough. Yeah, hi, I'm Christian. I started with using OpenSUSE when it was still called SUSE Linux, then became beta tester, whatever. In the meantime, I'm also in the heroes team, do whatever is needed, basically. And, well, it's just a hobby of mine.

I'm Sarah, I started during my apprenticeship as a computer science expert. Now I'm a student in computer science. I'm a global coordinator of a localization team.

I am in, I contribute to the wiki and founded the heroes team. Yes, I do different things everywhere where it is needed at the moment. Well, I was gonna say that I'm Richard Brown, but somebody else did.

I'm Christian, I'm from the Netherlands. I do whatever happens, what comes on my way. I'm a forums administrator, work in the mailing lists. I try to build some packages once in a while. Well, that's about it. I'm Simon, I have my own microphone somehow.

I started out as a community maintainer for a bunch of packages, and then somehow I ended up on the SUSE maintenance team. And I do a bunch of other random fixes for things like breaking the installer often. And all sorts.

Yeah, so we've all been in Prague for an extra couple of days. Am I on? Yeah, sorry. Yeah, we've all been in Prague for an extra couple of days having our annual board meeting, which is kind of the chance for us to sit down, figure out what the big ticket items the project needs to address, and also some of the ideas

that we want to kind of bring to the project. But we weren't always working. It wasn't, you know, yeah, it wasn't too much hard work. Yeah. You know. We, but you know, we weren't always drinking beer. We did kind of get in trouble because we took a bottle of wine into the SUSE office.

Yeah, so for the next bit of this talk, we're gonna kind of go through one at a time on some of the topics we were covering. What we decided, what we've done, what we need your help to do more with. And then at the end, we have the open session where you can kind of just ask us anything, give you feedback on these ideas, that kind of thing.

So next up is Anna talking about communicating with the board. Actually, yeah, that will work better. And I'll introduce each topic because we didn't rehearse this at all. Okay, yeah, so the communication with the board.

It's better if I'm here, then I won't have. Yeah, there you go. Yeah. So if you want to contact us, you can do it any time, write an email to the boar at openSUSE.org email. We have now, so this week we decided that we want that everybody can add items

in our online meetings that takes place every two weeks so that everybody can go to the page there and add the topics and then they will discuss. But you can also email us the topics to the mailing list if you don't want to do it like public.

And of course, the public discussions will come on the project mailing list with everybody. So this week we have been making a lot of changes in the weekend. So especially we have been focusing on the information

about the Boar because it was what I outdated was the Boar was doing. So there was some activities, pages that were not really what the Boar was doing anymore. So we restructured all the information. We updated the Boar page, the meeting page, also the elections and membership,

although that was changed recently, probably most of you already know that. There was some email and so on, but the week is still outdated so there is still some work in progress but we are working on it. Yeah, the new theme in the wiki that is actually not something that Boar is doing, some external contributors are working on new redesign

in the wiki but we thought it was a good idea to mention it here. And we are also discussing, I mean, it's not related with the wikis but with the news.opens.org. So currently we don't have any license and as we are open source and we like open things,

we think that our news page should also have a open content license and we will think what license will fit better and maybe there will be some discussions. And yeah, there is some, so still we haven't decided what license and how will this be added

but we want to have a license, an open license there. Okay, so for those of you who have been around the project for a while, you may remember once upon a time we had an ambassadors program, then we had an advocates program.

Basically the program wasn't really in use anymore and the last remains of the program were the wiki pages and so we have now cured off officially the ambassadors or advocates with a replacement wiki page, as you can see there, OpenSUSE Events and that tells anyone who would like to run an event

what they need to do, how they can get marketing materials and anything they would need to run an event because really we would like you to all be ambassadors for the project and we don't need to have a select small group from various places. Next, next one.

I'm a long way from the next slide button. Everyone's favourite mailing lists. So we have decided to create a new OpenSUSE support mailing list for any support questions and queries. There's a couple of people subscribed already so feel free to send your support questions

to this mailing list rather than factory mailing list which happens a lot or OpenSUSE app as well. We would also like to reduce the noise on the OpenSUSE factory mailing list so if you start creating bug reports, things that should be bug reports there,

I will probably start sending probably friendly emails at first then getting slightly grumpier if you keep doing it and so basically we would like anything that only really affects one or two packages to become a bug report on that package if it is a more general support sort of thing or you're not sure if it's a bug or not,

send an email to the support mailing list instead and to help ease confusion, the support mailing list covers support for Tumbleweed, Leap, beta versions of Leap and everything like that. Yes, when we have spoken about feature requests,

OpenFate is shutting down because it wasn't really used by developers but we have customers who had feature requests and wanted to add them so we thought about a solution

and our solution is to report it directly to upstream on GitHub and if we have other projects, we would use Bugzilla for feature requests. I want to create a Wiki page for it

and so everybody can find the right place for the special feature request you want to add. And also we would like everybody having a project in OpenSUSE as also the way people can track the bugs in the Wiki page

so because we can of course create the page but we don't know how all of the things are working and where they are tracking the users so that we will need some help there. So another problem we have is that the sleep bugs are private so which is annoying especially in the Leap development

because you see a change log with a bug number but can't see what is behind that bug and this is obviously a problem when we want to work together and we want to work together and do it a lot so our temporary solution is to create a mailing list

bug share at OpenSUSE where you can send a mail like please open up bug number one, two, three and then you will in the perfect case someone will just make it public and if that isn't public because it contains SUSE customer data then you should at least get a summary

so that you know what it is about. And on the long term solution we hope for a better way which could be a bug sealer component like shared bugs between Leap, Tumbleweed and SLE which are public by default and that should hopefully make things better in the future.

And we will also encourage the SUSE engineers to file Leap or Tumbleweed bugs by default and avoid the Leap bug sealer component when it's possible. Yeah, and just an extra thing for the bug share mailing list that's staffed by SUSE employees so starting with kind of me and Simon

and I think a few others have already volunteered because SUSE are happy with SUSE engineers checking that we're not gonna share public customer data when we pump that out. So if you're a SUSE engineer who's also an OpenSUSE contributor and you kind of care about this problem please mail the board and we can look at adding you to that list so you can kind of help with that.

But this is, yeah. I've already been added to it. Somebody did it already, yes. Cool, so I don't know who. Cool, you're next? Cool. So the friends of OpenSUSE, that's basically the projects we are sponsor

or helping, like there are many, so OpenSUSE sponsors many projects and conference and this was already a topic during the elections like there was the question what do you think about this and what other projects you would like to contribute with and everybody was really happy

with contributing with the projects although nobody knew what projects those were and then we want to make this information transparent that there is a Wiki page where we track what projects or what conference or events we are sponsoring and that in this way everybody can suggest new things which we'll sponsor

because at the moment it is not clear what we are sponsoring with nothing and it's difficult also to suggest new things. And it's also a good opportunity to say what is the project we find important and we want to support and also that the community maybe not only suggest other projects

but discuss if the current projects will be sponsored as well. And apart from that our partner, so currently for Leap 15 we have at least or that we know these two projects. Yeah, so for Leap 15 we had this kind of weird situation it's actually this is a follow on topic

from something the board talked about last year we wanted to kind of start reaching out to other companies who wanted to do stuff with OpenSUSE using it in their products as well so sort of things like hardware manufacturers and cloud providers and stuff like that. Yeah, a year later we have these two examples where we launched Leap on Friday

and both Tuxedo with their hardware business and Linode with their cloud business have support for Leap 15 already they launched it on the same day as we did they worked with us while we were developing it and yeah this is something which we want to encourage more companies and other projects

to kind of work with us on. These aren't exclusive deals by any stretch of the imagination we didn't sign any contracts with anybody just a case of sort of working with them and helping them with various bugs and teaching them how to contribute to factory and how we think and how we work and that kind of thing.

Yeah, so if you want to have a VPS you can go and log on to Linode sign up get Leap 15 already and I don't want to spoil the surprise of that box sitting on there but yeah, Tuxedo also now are selling Leap laptops and they also will be having Leap laptops

with nice open SUSE stenciled on the back which is an incredibly nice touch as well. Anything I forgot? Okay, Matrix, we are looking for new ways

to communicate with each other young people don't use IRC they don't use forums, et cetera and we found Matrix to seem to be a good solution for us since you can access it with all kinds of protocols

and use it in very many different ways. We are considering, and that needs to take place over the next couple of months but we are considering to have our own Matrix server

so that we can provide the infrastructure for it and that it will always work. For the moment these are plans and we invite you all to send emails to the board or discuss this on a project mailing list to tell us what you think about it.

Yeah, this is one that's been on my mind for quite a while. In my experience from the forums and IRC our biggest problem are not the NVIDIA cards not the Broadcoms, et cetera, it's upgrading. People are afraid of upgrading

because they think they will block their system. Even though we showed them in OpenQA that we test all this, we test it again and it works, that's a big problem. We thought, or I thought, a year ago I started talking on a conference,

why would we not have service packs? I talked to Ludwig about it and this seems to be a problem currently but service packs would be easy. You download it, click, it installs, you reboot and you're on the next version and for a lot of people that's different from changing some numbers and running zippered up.

This is also something we'd like you to think about. Send plans on a project mailing list, have a discussion about it and like always something will come out.

So we've been also discussing the conference organization. The team this year has done a wonderful job. Most of you guys won't have seen too many issues with it. It's been a fantastic conference but we as the board think possibly there are some better ways we can organize the conference.

The OpenSUSE Asia community that has a fantastic example for organizing conferences where they have a board or not a board but a committee put together from previous conference organizers that they then used to decide and help facilitate each conference. So there is some continuity every year

with the same group of people overseeing stuff but then it's up to the local team to run the conference itself and it makes the communication lines for who's doing what in the conference a bit cleaner and a bit clearer. There has also been people suggesting to us

that they might like to host the conference somewhere other than Prague or Nuremberg which is something that maybe we'll look at for 2020. Certainly for 2019 I think it's gonna be most likely the conference will be in Nuremberg but we are open to calls for proposals and if those proposals can provide

a compelling business case then that is something that we will put forward. But there is a note on that that if you look around this room there are many SUSE employees and SUSE is the major sponsor of the conference, would probably like to have the conference somewhere where it's not too hard to send their employees

so that would always be a consideration in a bid. And so I am just gonna read the slides because I just talked about stuff. But yep, I think I've covered everything there. Yeah, I think you got everything, cool. And yeah, that's kind of the summary of everything

we were talking about at the board meeting this week so now it's kind of up to you. What is your feedback? What would you like to see both not just for this conference but yeah, in the projects generally? Do you have any questions? I'll stop, I'll, yeah.

This is the fun complicated part where we all spend ages figuring out who's gonna answer. So my question would be what would be the real difference between your Leap 15 service pack and 15.1? Isn't it just a label? Yes. Yeah, that's a shitty,

that's a really shitty reason because if the people are afraid, they are afraid of the content, not of the label. Yeah, Darix, to you they're the same. I see daily posts from people that are afraid of doing things in a terminal. If you have a service pack

and it would be something like a one-click install, that would be different for them. You can do the same. On that same topic, while I agree that the migration tooling

like we use for SLES would be great to have for Leap, the naming, I can tell you from my experience working in the SLE world for many years won't get you far because our customers also think service packs are like major releases and we even sometimes in product management trying to figure out how can we change that perception by maybe even thinking about different ways

of doing the updates to our major releases and not calling them service packs or trying to find a different way to do it that lowers also that perception threshold but we have the same problem on SLE with the service pack but the migration obviously would be great.

So Dan, SLE and OpenSUSE have a common problem and this is just an idea to brainstorm on it and I've been around in this community for years and I've seen lots of suggestions like this and always something comes out and if something doesn't come out,

we have found better ways. So I appreciate that you bring in more winners who work with OpenSUSE but we just this year lost Hetzner having OpenSUSE as officially the distribution. Has that changed? Yes and no.

I can talk about this because I'm a Hetzner customer and it was actually a really, really long Hetzner support ticket because I was like yelling at them for like months. So yeah, Hetzner, big German hosting provider, used to do a lot of stuff with OpenSUSE. They no longer list OpenSUSE on any of their official images.

They do now, after the discussion that I had with them, have support for OpenSUSE as a VNC installer so that is still there. All of their source code for their installing tools are in GitHub and do work with Leap 15 so officially we're not listed but in fact it just works.

And I'm working with them and I would like more people, especially if you are a Hetzner customer, like file a support ticket because they might realize on aggregate just how many of us there are. But yeah, so it's an ongoing work in progress. To be honest, speaking personally, and this is gonna be recorded and I'm gonna regret it, I guess,

I get the feeling they're shifting more and more towards their Hetzner Cloud product so the better way for OpenSUSE to be more easily present there would be for us to get our OpenStack images more as a top tier OpenSUSE delivery because then they can just use our official OpenStack image if we had one.

So yeah, work in progress but it's not as bad as it was six months ago. Okay, one last question then. OpenSUSE mailing list, wouldn't it be just the same as OpenSUSE Dash support? Because you had a bit of a mistake to put it on the slide.

Yes and no, there are some similarities there but the OpenSUSE mailing list for a long time had a very focus on back in the day what were the OpenSUSE stable releases and if you mentioned something related to factory at that time which has then migrated onto Tumbleweed,

often you will get users telling you that this is for support of stable things and go away with your question to OpenSUSE factory which is the problem we're trying to fix so one of the ways we would like to fix it is by making the name clearer and kind of giving the whole thing a refresh and revamp as a new thing.

Yeah, so to kind of put it another way, I mean obviously having a new support mailing list means the nature of OpenSUSE at is likely to naturally evolve as a result of OpenSUSE support being the official support mailing list, we'll see how that works out. We'll see what we end up with,

we'll see what needs to be fixed there, maybe nothing does, maybe it all works out fine. So I have a similar question, so I was wondering have you considered splitting off an OpenSUSE leap mailing list because currently we have both the Tumbleweed snapshots and any leap updates during the development process all going to the factory mailing list

and also questions from users about packages in there and problem reports. What would you like to see is to at least make OpenSUSE factory OpenSUSE factory again and not support questions, not a kind of platform for Tumbleweed users.

One single open support mailing list I think could very well do. It's about support, but the most important... Not just support, I mean there's not just support, there's also the development phase.

This is something we did talk about this week. We did kick the idea around, but we kind of thought, let's not try and change too much all in one go. So we're starting this with OpenSUSE support at and the kind of suggesting for bugzilla first stuff for the mailing lists, those things that should be in bugzilla.

If factory still is a little bit too muddled, then of course that kind of thing is the natural next thing to talk about and discuss, but there's no decisions made there. Can I just say that as I on the board, I think there has been far too much noise on that list over the last year and I'm willing to do anything to change it

so that there is not too much noise on that list, but this is the first step. I have a question about the membership, well how to become a membership. I think there was a discussion about changing it

to one contribution only and not the long-term contributing as a requirement. And in the wiki workshop that we attended, we tried to change a few things, but now it wasn't really clear if that changed or not because I couldn't find an official announcement how that works now.

So just like how does that go these days? We will work that out, but we want, the one thing we want is that it's much easier to become a member. My personal point of view, anybody who downloads OpenSUSE, OpenSUSE installs it on his laptop just to try it,

it's already contributing if he gives some feedback and if people organize local events, et cetera, et cetera, they should be able to become members. It needs adjustment in the wiki. I think he's also speaking about the documentation we have and we,

yeah, it is already updated, so this is already being used in new, I mean there was a discussion in project, everybody agrees, so it is already being applied. The only thing that is missed is updating the documentation in the wiki, there was someone rising the consensus in projects and we were also discussing about it this week and then I think Richard is going to update

this documentation, right, the wiki, so it will be updated as soon as Richard has time. Come on, sir. Two points. First, why we need members? Apart, wait a minute, apart from giving us work,

my mail is not working, my clock is not working, and nobody else taking care of them. And second point, okay, I understand, we need members to vote. Yes. Then why we want even more people to vote apart from the people that are actually contributing and how we draw a line there? Yeah, so I'll tackle both of those

because I was the guy who put the proposal on the mailing list for tuning it up. We need members primarily to vote on decisions like the board, who is on the board, and we need them to decide on those trickier decisions where the board can't make a decision or the community can't make a decision. And that's pretty much it, not much else.

It's just a case of if you opened it up to the big wide world of everybody, you have the risk of boat face becoming the name of the new OpenSUSE distribution. So it's really just a case of making sure that OpenSUSE people are voting on OpenSUSE topics.

The kind of issue of, what's the second question again? Just remind me. Yeah, so yeah, who's gonna deal with the mailing list issues? Oh, so the issues with the mail aliases? That is something we kind of brushed on slightly

in the topic there. With the update of the documentation, you can expect also talk on the project mailing list starting soon about what we want to do with the tooling. The general thing we decided to get together this week was the whole process of connect and the approval process

and the membership officials and waiting for somebody to look at that proposal and blah, blah, blah, blah, blah. And then you hit the button in connect and it doesn't make the mailing alias properly so you go and bug Tio and Tio starts crying. Yeah, all of that is ridiculously over-engineered.

Yeah, yeah, just slightly. Yeah, it took us four years to realize that but it's ridiculously over-engineered. So this is the board decision because we don't want to overstep our bounds. The board decision is we want to address that. Exactly how the current membership officials can expect discussions or emails starting soon

on our idea. Basically, what's wrong with a shared spreadsheet for heaven's sake? Email addresses, the approval process, the request process could just be a contributor wants to be a member, they email the membership officials, quick discussion, quick debate, quick entry on a CSV file somewhere.

CSV file goes running that scripts and make your email aliases for you so you have nothing to do. We could replace you with a cron job. Sound good? Cool.

I have a comment about the service pack discussion. So what I think is would be much, much better if we would have some mechanism to actually tell the user that your OpenSUSE leap

is out of date and then he can decide if he says, yeah, update and then some tool tries to put in the new repositories he does the update and if he messed around with SIPA and his repositories and maybe he has to fix it on his own but at least for users that just want to use Linux

that would be a good solution and they won't just start to add repositories and that's more like power user for me, yeah? So that would be a good solution to really be able to tell someone like, I don't know, my mother then you can use OpenSUSE leap

because right now I can tell my mother, yeah, you can use OpenSUSE leap but hey, you have to look when there is a new version because then you have to touch some files to update and that's not what the normal user wants to do. I'm sure we have an opinion but Oli looks like he's gonna try and climb up the wall so I'm gonna let him say something first.

Just as the last thing, I think there was a heck with project on this, I don't know where it ended up. So I also think you have found the right problems. This was also the biggest surprise to me when I saw OpenSUSE first or when I joined SUSE

is that this whole OpenSUSE upgrade I mean, the service packs they are really, there's marketing that is a whole new product which is cool, it has cool new features but it really scares people also like, oh, I need to go to a new product so I still run OpenSUSE leap 42.2.

That is not really addressed with the service pack thingy, I think it will make it worse. I like the dot number, I mean if you can take a look there's like Debian which has a major number and the lower numbers and you get them automatically. Why is that done? Well, who would do that? I mean, you raised the right idea.

I think you could put that in as a maintenance update. Who would do the maintenance updates in OpenSUSE? I think this is a limiting factor and it's not addressed by relabeling it. We have all the tools available functionally, technically I think. So if the board wants to drive that it would be really cool

but I think it has to be more driven on the side of project management or who as a contributor could contribute in that direction and then maybe even we will come up with a really cool technical solution that I cannot even think of right now. I wouldn't like to make the decision now

but really leave it to that task force, that group or something. I mean, everybody learns here how to do packaging, how to do new packages but how to handle end of life over minor version, I think it has been never a topic. Yeah, I agree. I think I do kind of personally agree

with your point of view but from the board's perspective, we purposefully say we don't make technical decisions on the project unless contributors want to do so. You can consider that kind of service pack idea as us identifying the problem. It can be down to the community to how to fix it. If there is a technical solution and I think there is,

let's try it. Talk to Dominic, talk to Ludwig, let's see what we can do to really smoothen that sort of thing out. Andrew. So now that there's a much closer relationship between OpenSUSE and SLE with the LEAPs,

15, SLE 15 thing, will SUSE be more proactive in promoting that relationship and promoting the project at events that SUSE are at? So as an example, you've got LC3 coming up in Beijing,

SUSE is a diamond sponsor there, ideal opportunity. I tried. I tried. I can't give an official firm the entirety of SUSE answer on this topic

because to be honest, we haven't discussed it at that kind of level where I can say like all of marketing management of SUSE agree to exactly what you said. What I can say is the people at SUSE who we did talk to on the topic of LEAP to SLE migrations because LEAP 15, if you haven't noticed

in the release announcement, is the first version of LEAP where SUSE will actually support migrating from LEAP to SLE in place as part of a zip-it-up. From SUSE's side, part of the product management and engineering management reason for justifying adding that support and committing to that was exactly so SUSE could start doing that kind of thing.

It makes business sense for SUSE to do that kind of thing, to show LEAP as an entry for potential customers entering their SLE world. I hope so. I expect it. I can't guarantee they'll do it, but I'll push for it. Okay, in that case,

I'd like to make a request to the board to request that SUSE consider OpenSUSE as a strategic partner just like they do with HPE, IBM, et cetera.

I think in many ways they already do, but if you want a badge on a website, well, we already, oh. It's not visible. Really? Either visually, orally, at any of the events, you see nothing about, well, you see very little about OpenSUSE. It's only because Doug's hijacked corner of a table. You've hijacked corner of a table

at one of the events that SUSE are sponsoring that you're attending. I'm gonna run up there because Andreas is raising his hand, but I will say, if you go to the open source section of the SUSE page, they did change it recently, so they've got all the communities they support, and we're just the massive one in the middle that has color and all the rest done, so a different way of reflecting it,

but yeah, you've got a point. I'll look into it. I just wanted to comment back on what Andrew was saying with regards to HP, and the way that I understand it in an unofficial statement is that partners are investing money in order to build those alliances with SUSE.

With OpenSUSE, it's exactly the opposite way around, that SUSE is investing as a sponsor in the OpenSUSE project. As a guy whose team is working with these partners,

what I can say is I would consider OpenSUSE, especially the fact that we are using factory and LEAP development to springboard SLES means that the OpenSUSE community is directly contributing to SLES. We take from our partners not just revenue,

but also engineering and testing resources, et cetera, and I find that OpenSUSE falls directly in that, so I find it a valid request. Well, of course, but this is just a marketing thing. It's about marketing. I see no reason why we shouldn't be marketing that.

I'll do what I can to try to push that. Next question. Sorry. Yep. Actually, I have two questions regarding, or one comment. The thing is I saw on my mails back shares already there. I didn't saw it for OpenSUSE support. It might follow.

What I actually want to know, or what I want to refer to the title of the talk of Doug, sorry, of which are this. OpenSUSE is what you make it, so we have this request of the board now for getting a metric server, and regarding the heroes, I can tell you

this is a tough task maybe, so if anybody here is experienced with metrics or wants to do that task, step up, do it, and I want to consider everybody who wants to use this support mail address or bug mail address before doing that, maybe try to also consider if you can contribute

to the bug in the build service, which might make even the distribution better and not only is filing a bug and forget about it, which is even better than just filing a bug. Of course, discussion is always good, but we should get the distribution better. But regarding this, I think the wiki we want to create

to where you should track the things is exactly for that because at the moment, it's not that easy to go with your issues somewhere because maybe you know where to track them, but I don't know if everybody knows. So, I mean, that was the idea of the wiki,

exactly what you are saying, trying that people find the place where tracking things. And the support mailing list exists. Myself and a couple of others on the board are already subscribed. And regarding metrics, before asking about volunteers to set it up and so on, or even if we do it,

we wanted to hear some feedback, that's why, so it is not something decided we are going to use, it's a proposal. And before going to set it up and nobody use it, then we want to hear what people think. And also on that, no one on the board is gonna set up matrix.

No one on the board is gonna force any of the heroes team to set up matrix, that's outside our power. We are very much just putting the idea out there and if a volunteer steps up and does it, then it will be done. If no one does it, then it will be too hard and it won't get done. And we will use the relay server that's slow.

So actually that's gone because there are concerns from the community about communication and how get new people and people that are not used to use IRIS and things like that. And then we were discussing a lot and we thought metrics could be a good alternative. But it's not decided, so. Yes, it's not decided, it's up to the community to decide and then do something if they want to.

Sarah, someone? You still want something to say, Dax? Dax? So I can tell you one thing, what will happen, somebody will step up, set it up and then say, yeah, I'm out. The heroes have to keep it running. I can name you at least three things right now

which you are heavily using and if I got promises, oh no, no, in a month we will turn it off and it's still running. So, yeah. Experience. Another topic.

There was the topic of how to go about replacing the open fade system and the suggestion I heard was to create a Wiki page and on that Wiki page list where for individual packages we can request features. My suggestion would be can't we move that information

into the build service so that this can be maintained directly alongside the packages and not as a separate source of information? So my simple open SUSE answer to that is yes we can if someone does it but the thing with the build service bugzilla integration is it creates a bug on open SUSE, not a bug in Gnome,

not a bug in KDE. If you would like a new feature in Gnome, really it needs to go into whatever place that Gnome features go and the only sane way of doing that really is to have a Wiki page that the people who want to use the information can add.

And I think there's a misunderstanding here as well because when we speak about the project, I think we are speaking about OBS, open QA, so we are not only speaking about the project inside so open build service and so I don't know if it is. So if you look at the current filing a bug

in open SUSE page, you've got the generic one like how to file a bug in the distro and then like in Yast and then in this part of the distro and then that part of the distro and whatever but also if you think about it, we have an umbrella project. Where do you file a bug or a feature? For OBS, for OSUM, for open QA, things like progress.

So with this kind of joint topic of bugs and features, it's kind of a joint effort to document all of that because we're not gonna try and have one grand unified feature request place for every single open SUSE project.

Yeah, it was everything about all the open SUSE umbrella projects and not about all the packages in the distribution. Yep, so I think again the right problem addressed.

I wonder how this process of reviewing that would then look like. I mean with FATE, it was I think suffering from two pinpoints. First, there were no people stepping up and making the decisions like no open, whole open SUSE community will never do that

and second, that from a technical perspective, it's clunky. See, this one is an easy one because other than someone who wants to add something to a pattern, for example, which is actually an open SUSE feature and if you wanna do that, annoy me, create a bug request and we'll see what we can do.

For everything else, whether a feature added or not, is added or not, we really believe is a decision for upstream. So if you wanna request some fancy feature in Gnome, we really believe that is for upstream to go for and that's not for us to carry. Okay, maybe.

No, we meant to say it's about everything. Maybe I as a user do not really understand and don't know any kind of different parts. I'm just saying, I want in my SUSE system on my computer, I have this cool idea. I don't even know that it's actually leap

and where this would come from, what project this is about and all those things. So I like the idea to handle something on the side of open SUSE. We as a community care for something but then how is this like triage so that we can separate it? So the point of the wiki is that it is the best way that we as the board can handle this

and try and direct people in the right direction of where their feature should go. So it would be the board making the triaging and we can update it? Yes, we are gonna do it initially and then everyone else can update it. And there is another thing, you can track the issue for the users but if the developers don't read it, then it is completely useless.

So I think it's much easier for the developers to track the issues where they are already working. So, yeah. I just want to say like one important effect of being a packager is also being the bridge between your end users and it might be

an integration issue in the distro but also upstream, giving them feedback this breaks in the next version or something. So I think having the packager pick up the bug and then forwarding it to and this is really part of the workflow. Yeah, we want to document that when that is true. There's, you know, in the non-packager scenario

that isn't necessarily true. So, yeah, that's what we're thinking along the lines of. And I've been told we're running like 15 minutes over so any other questions can go to the OpenSUSE project mailing list, you know. Yeah, and Douglas now has a big surprise to add to the end and close enough. Thanks, Doug. So I hope you all had a good time

at the OpenSUSE conference this year. I do want to thank the sponsors again. I want to thank Arm, I want to thank SUSE, MySQL, Tuxedo Computers and OnCloud. And the big surprise that you have all been waiting for, please put your hands out in front of you on top of the desk and let's hear a drum roll, please.

Okay, so I would like you now to take your hands and put them underneath the desk in front of you and one of you will have this in front.

Well, maybe one of, yeah, you better start searching. And we have a winner right here. Yes. So, please come up and get your Tuxedo Computer.

Did you want to present it and I'll take a picture? Yeah, sure. So this is the, well, not the first but one of the first Tuxedo laptops running, loop 15, preloaded out of the shop. So, thank you very much.

And yeah, I did it too quickly. Pardon? Yeah, he's taking it. We are running late, so yeah. Thank you very much.

Is there any last minute things? When's the bus for the SUSE employees going back to Nuremberg? Okay, so the bus for the SUSE employees going back to Nuremberg, is it six? Yeah, and if you'd like to help unpack everything and move tables and stuff, please meet in the foyer and yes, we can tidy up the mess we've made after this lovely day.

Thank you very much. See you next year.