Welcome back everyone are you ready for some goals action,
very good very good um i have three envelopes here with the new goals but before
we get to those we will wrap up the last goals because a lot of exciting things
happened uh for the last three goals.
And the champions will talk a bit about what happened and what we achieved.
And we will start with Carl and accessibility.
Yeah.
Oh, what?
It's the thing is,
Maybe I will just click here. Yeah.
OK. Anyway, I will present what we did for the last two years for the Caddy
4.0 goals, as an accessibility goal.
But first of all, why accessibility? Why are we working on that?
That, first of all, it's inclusive and give equal access to everyone.
Like, a lot of us are not impacted by accessibility issues,
but even though if you are getting older or friends of us, I mean,
like there's a lot, huge proportion of the population, world population, which might have some.
Vision issues, might not be able to use the mouse correctly.
There's a lot of reasons why you want to,
why you cannot use your computer as a normal user.
It also improves usability, because even if you are not impacted by these sort
of issues, just having a keyboard navigation in your applications improves the
usability of your applications.
Having a good contrast for UI elements helps everyone.
Yeah, it's the right thing to do. Like you want to integrate,
you want to make sure that everyone is able to be part of the society,
be able to interact with computers because computers are so much important nowadays.
Days, like if you want to order something, you need to use a computer.
If you want to do like administrative stuff for your government,
you often also need a computer.
Yeah. And if that isn't enough to work on accessibility,
there's also like, it's a law, like you have a lot of countries,
as it is in Europe, in North America, And as a lot of other places,
they are gradually requiring for public usage,
but also for private companies to use only software which is accessible.
So if we want to reach public institutions, we need accessibility.
And did we manage to make KDE accessible?
I don't think so, because it's not something that you can do in two years.
It's a long process and it takes time.
It takes time, it takes development effort and yeah, but we did manage to do a lot of things still.
Um, yeah, as well, like we had a lot of accessibility improvements in Plasma,
in the applications, in KDE frameworks, and even in Qt.
Um, and I mean, like for example, in Plasma, the range of accessibility improvements,
it's from keyboard navigation,
color blindness corrections in Plasma.
Screen reader support. It's not like one thing that we did.
It's a wide range of issues we solved.
And we also did improvements in frameworks and Qt helps everyone.
Each time we fix an issue in KGami or in widget add-ons or in Qt,
it makes it easier for other people to build accessible applications.
Sure, they can also mess up in their own application accessibility,
but trying to make like the default widgets accessible is super important.
Yeah. I mean, this is like a screenshot of accessibility tech measure quest for the Plasma Group.
Only for the Plasma Group. And you can see there was like two more than 200
mesh requests open, and from them, there was like almost 200 meshed.
There's still a bit open and a few like which were marked as invalid.
And outside of improving the accessibility of our applications,
we also did a lot of work inside the tooling.
For example, there's a new applications, Accessibility Inspector,
which allows you to look at your applications and look at the accessibility,
look at the state of the accessibility there.
The application was actually quite older, but it was never released.
It was super hidden inside the build folder.
And yeah, now it's a Probe application which is released and a lot of improvements
thanks also to Laurent and others.
Yeah.
But there's also a lot more improvements to the tooling. There's a Selenium driver.
It allows you to write integration testing based on the accessibility API.
So each time you want to write integration tests, because you should write tests
in your applications, you also make sure that your application is accessible,
because if it's not accessible, you cannot test it.
So you are forced to make it accessible.
And that helped a lot. And not only for my goal, but also for other goals,
which we'll probably talk about later.
And, yeah, it's provided by the IT SPI Dbus API.
And this was all done by Ault, mostly, super good work.
Yeah. We also did some improvement to the documentations because with the documentations,
you need to learn everything again.
So we had like no documentation about how to write tests.
For Selenium.
We also had a gold sprint in April this year in Berlin, where we tried to combine
every gold together in a room.
It was super productive.
I mean, every sprint is super productive. We managed to fix a lot of bugs in
Kigami, Kigami add-ons, some applications. So, yeah.
But I mean, there is still a lot of future work to do. Like I said earlier,
we are not accessible yet.
There are still a lot of things to do, to improve situations.
For example, text-to-speech. There are new frameworks to do that,
based on Dbus, which is compatible with Flatpak and Snap,
which we need to implement in Qt.
Because there's an abstraction in Qt, and we need to implement that, it's a lot of work.
There is some work going on about the replacement API for ITSPI.
So, it's still like really, really working phase, but we need to get involved
there and try to make sure that it's good for us.
And yeah, there's also like in many applications, as even Plasma,
we see like a lot of work to do, to be done, to fix many issues and yeah.
Yeah, so a few lessons learned as a goalkeeper, um, it's not because there's
a goal was voted by the committee, but you will certainly find yourself with
a lot of contributors to that goal.
Um, that's, I mean, it's like we are a community. We are not, we don't have managers.
We don't have people who tell us to work on this thing and this thing.
And I think it's a good thing to be able to have some freedom on what we want to work on.
And a lot of people are already overloaded by their own projects and tasks.
So it's always a bit difficult to find contributors to work on some topics.
And I think as a golf keeper, probably we should try to,
to do a lot more outreach to the developers and the community to make sure that
people are aware about the goals and.
I recommend them to invest a bit of time there and tell them what the advantage
for them is, like, for example, having like iteration tests is super important.
Like it's something like you, it's a bit of work at the beginning.
You need to fix your accessibility. You need to write the tests,
but at the end, it's super rewarding because then you find you have less bugs.
Don't fix all the bugs, but you find you have less equations.
So you need to do like a more outreach there.
And for the last slides, I want to thanks like everyone who worked on accessibility.
There's a few names there, but there's actually like a lot more people who did
work there. And it's super.
Yeah ok.
Next one Nate for the automation goal thanks Carl,
let's see first of all million dollar question So, here's the best accessibility improvement we got.
Not done yet.
Still going. Okay, I'm done now.
So now I'd like to talk about my goal, automation and systematization.
This is definitely the easiest to pronounce goal out there.
So that definitely makes it the most important one forever.
So the important thing of this goal was to enable all of us to be lazier,
because that's the point of automation and systematization.
All of us are overloaded all the time. I think everybody in this room has the
experience of having 10 times more things to do than you have time to do them.
And one thing that's often the case for people like us who are highly productive
is that we find ourselves saddled with grunt work. We have terminal commands to run.
We have email responses to craft that we've already sent 10 times before.
All sorts of things that we're experts at doing, but that take up time.
And when you have tasks like that, that you repeat over and over again,
it consumes a significant amount of your own time and resources and life's energy.
And so the idea here was that we should all focus on automating away these kinds
of tasks that we don't actually really want to do and that we're very good at.
And when we do that, we get a whole lot more time left that we can actually
put into doing the things that we want to be spending our time on,
the things that give us joy and make us happy and push forward the state of the art.
When we look at this
the goal was essentially animated by three principles
behind that the first one is
that automation beats manual labor manual labor is error prone it's time consuming
it's boring it's not fun we've all had this experience of doing something that
we've done a million times before and it's just not a good use of your time
so for all of those things it's good to automate away all of those tasks.
The other one is that policies are better than opinions.
It's another thing that I think we've all had the experience of is that you
propose a change, you say, let's do this, you open up a merge request,
and you get a comment that says, plus one, I like it.
And then somebody else says, minus one, I don't like it.
And now what? What do you do? If you don't have a policy to guide what goes
next, oftentimes this just gets stuck forever.
And so the idea here is that if we can all get together and we can agree on
certain methods of doing things, on certain policies behind decision-making,
that it can cut down on the number of plus one I like it, minus one I don't
like it. That is just not terribly productive.
And so there was a focus on making decision making systematic in this way that's
sort of not technical, it's more social.
But that was another thing that we wanted to focus on for this goal.
And the third one, the third idea behind this was that it's better to work on
a team than to work alone, because working alone is very lonely.
And it's it can be hard to find other people who want to help you,
you get depressed and disappointed when you burn out and need to take a break,
nobody takes over the work for you.
So it's much better if we can work as teams and we can communicate as teams,
rather than just doing everything privately all alone, because it's sad and makes us unhappy.
Uh, there's sort of the why bother question about all of this,
which is the elephant in the room.
So if all of us are just here working on KDE forever, we've certainly got infinite time, right?
Well, the fact of the matter is that KDE is a multi-generational institution.
Uh, all of us are here today. We were not here yesterday and we may not be here tomorrow.
Metaphorically speaking, of course, hopefully we actually were here yesterday
and we'll be here tomorrow, but hopefully you know what I mean.
The fact of the matter is that people come
and go and that is totally okay it's a fact amazing
it's one of the things that makes kde so incredible is
that we've managed to keep up the interest and enthusiasm for the overall project
over almost three decades but this necessarily means that there's a lot of turnover
and that means that people when they leave take their knowledge and their labor
with them if you look at this graph here this is something that carl has put
together other recently. Thank you, Carl.
The colors are essentially individual years' worth of contributors.
And if you look at that big blob of orange people, those orange people kind of fell off over time.
And everything those orange people
knew was lost if they didn't embed that knowledge in code, in automation,
and in documentation, so that by the time those red and blue people showed up,
they didn't know the things that the orange people knew if it
wasn't documented and preserved in processes
properly and so i think this kind of a graph is really important for all of
us to consider in terms of our legacies in kde you know whichever color we represent
on this graph if we want everything that we produced to continue and be used
and built upon by the next generation,
we have to make active efforts to make sure that happens and that's basically
what this goal was is all about.
We've already touched a little bit on some of the benefits.
Let's briefly go over that again. Probably the biggest one is quality.
Because when you do things according to processes and automation and tooling,
you end up with a better result because it's not kind of random and dictated
by who had time or who had skills or which person happened to be doing it at
this particular moment in time.
And the other thing you get out of this is consistency, because when something
gets done the same way, or at least according to the same process every single
time, then you get a repeatable result.
And repeatability of results is really important, because it's something that
increases the perception of stability in your software,
and it makes it possible for normal people who don't have the incredible pattern
recognition recognition skills of engineers like us to use something just because
it behaves the same way every single time.
And that's important for us to have in our software and in our internal processes too.
And the other thing, of course, it gives us this free time because who wants
to do crap that's boring, right? We all want to be writing new features.
We want to be improving the user interface. We want to do things that are enjoyable.
We don't want to be fixing the the same bug 10 times over again because
it keeps regressing and nobody noticed um maybe
10 is an exaggeration but i can think of specific bugs that have
regressed three times in memory and even that's too much so let's not do that
right uh when we do this we'll have less grunt work to do fewer regressions
and uh i think i mentioned earlier arguments and merge requests another Another
thing is style nitpicks,
which is in some cases more frustrating than arguments in merge request.
When you submit a big block of code and you get people saying,
well, please put a semicolon at the end of this line of JavaScript.
And don't put a semicolon at the end of this line of JavaScript.
And, you know, we have tools that can format these things automatically, right?
This is a waste of our life having these arguments, like pick something and then move on.
So there was an effort to do those sorts of things.
When we look at what the goal was actually focused on in terms of actions,
we did a lot of automated testing.
Carl mentioned ATSPI and Selenium, which was incredible work and something that
really synergized very well across the goals.
Harold, as mentioned earlier, was really instrumental in bringing this technology
to the forefront, and it allowed us to improve our code coverage and testing
as well as accessibility at the same time.
So, especially in Plasma, we saw a really enthusiastic adoption of this technology.
And now we have a huge number of user interface tests that seem kind of silly
and dumb, but, you know, push the button and make sure the thing happens when you push the button.
Turns out that's really important. So we have a lot of that now.
And that's really great.
Another aspect of the work was automatic bug triage.
Bug triage is something that I think everybody in this room hates,
myself included. I do a lot of it.
You might be forgiven for thinking that I enjoy it. I don't. Nobody likes it.
So let's do less of it, not because
we're ignoring it, but because we have machines to do it for us, right?
So we have this thing called the Bugzilla bot, and it will apply certain canned
answers to common issues that people have in bug reports,
and it will prompt people to improve their bug reports, automatically close
old ones that were submitted for versions not in support anymore.
This is something that there's a huge amount of low-hanging fruit on,
but there was significant progress anyway, and that made a big difference.
And finally, what we also have is the subject of documentation.
Documentation is is in some aspects the weakest focus here, because it requires active maintenance.
Documentation gets stale and goes out of date very quickly. But it's nonetheless
really important that we make an effort to keep it up to date,
because documentation that's out of date,
is in many ways worse than no documentation at all, because it can send people
down the wrong path and making wrong decisions.
If we look at what succeeded in this, first, let's look at this fun graph.
In terms of bug triage, if you look at this, the red line is the number of unconfirmed
bugs in PlasmaShell over time.
And you can see that that drops precipitously and then keeps falling for a while.
Now, I mentioned automatic bug triage. I'm not going to say that the Bugzilla
bot produced this, but the Bugzilla bot made it easier for bug triagers to focus
on the bug reports that actually mattered.
So they didn't spend all of their time saying, I'm sorry, Plasma 5.12 is out of date.
Can you please try using a better distro?
That's just not something we have to do anymore because a machine does that
for us. We have machines to bash distros now, which is a major improvement.
We've got all sorts of other stuff,
too. we made it mandatory for a lot of projects to pass their tests.
We had tests. Some were disabled. Some were perpetually broken.
There was a major focus on making sure that tests actually do what they're supposed to be doing.
We have continuous integration jobs to build Flatpaks and Windows binaries,
so we can just spit those out on command. That's super cool.
No more manual labor there.
Like I talked about, we did Bugzilla bot stuff. There was a lot of documentation updates.
Some of this was driven by Tiago, KDE EV's documentation contractor,
but a lot of it was volunteer-driven as well, which was fantastic.
And on the subject of documentation, we got a whole new user,
a whole new set of human interface guidelines, which was rewritten from scratch
to actually be applicable to the way KDE designs and builds software today.
And we've already seen some great results from that in the form of people submitting
changes to bring applications in conformance with the human interface guidelines,
which kind of goes to the point about when you have processes that work,
people follow the processes, right?
Uh, nonetheless, we saw some challenges with this goal.
Um, probably the biggest one was that nothing encompassed under this goal is ever truly urgent.
You know, we all have our, our daily fires to put out. All this stuff is always backburner stuff.
Uh, it can be tempting to push it off until later and say, well,
you know, we'll, we'll ship it in a, in a state that's good enough now.
And then we'll, we'll care about that stuff later.
And I don't think there's a silver bullet for this, but it really requires vigilance
to make sure that we're, we're improving the processes and the quality at the
same time that we're shipping the software.
Another major challenge for us was that even with ATSPI and Selenium,
writing tests is still just really hard.
It's probably harder than it should be, and it makes it more difficult for people
to just kind of throw in new auto tests whenever they add a new feature or change
the user interface or something.
I think there's some friction there that can still be lessened a little bit.
And then also, let's face it, it's kind of boring.
Everything about this goal was the opposite of flashy and exciting.
And so ensuring that there was
motivation to actually do the work has been quite a challenge over time.
This is not an indictment of anybody in the room. If anything,
frankly, it's an indictment of me, the gold champion, which gets to the final point.
I probably did not lead this goal
in as active a way as I think in retrospect I
would have I would have liked to and that I
think ended up being a challenge for for the goal itself and that leads me to
some lessons learned that I can share as a goal champion I've now been a goal
champion for two goals I did usability and productivity a few years ago and
then I sat it out for the cycle after that. And then I did automation and systematization.
And one thing that I really feel like I can say as a gold champion is that,
being proactive and leading by example is super important.
It's very easy to make fancy presentations, but nothing spurs on work like work.
And so if you're the goal champion, it's very important that you be seen doing
the work and that you then communicate that work.
I'm going to skip something here, but on the subject of communication,
another thing that I I found in this particular goal cycle was that episodic
communication in the form of fewer updates about larger,
more impactful wins seemed to be more motivating than a steady stream of small things.
It seemed like it was easy for people to kind of tune out a stream of small
wins, whereas whenever there was something really big that got announced,
that would generate quite a bit of attention.
So I would say for our future gold champions, try to focus on the big wins.
You know, that's more motivating.
And the final thing here is that it's just really difficult to change things,
especially when the status quo is good enough.
We have incredible engineering talent in KDE. And so people are already largely
accustomed to doing things like writing auto tests, keeping up documentation,
following good practices in their commit messages, being collegial.
And so our status quo is already pretty darn good.
It's, I would say, in many ways,
much better than what you see in a lot of private companies out there.
And so when the status quo is already good, it can be challenging to keep up
the motivation to improve it even further.
And that's something that I think we can all have a thought about,
you know, how we can take a lot of this stuff to the next level.
And, yep, that's the end. Thank you, everybody, for your support in this goal
and for supporting me and doing all this work. It was fantastic to be your gold champion.
I'm going to hand it off to Cornelius now.
Here we go. Thank you.
You. Let's move the mouse pointer out of the way. So yeah, I will present you
what we achieved with the sustainable software goal.
That's the third goal in the row.
And what I will present is mostly what we did in the two years,
but also a little bit what happened before and what will happen after.
So you already heard it in our keynote this morning, we have a problem.
The way we are living is not sustainable and we are contributing to it,
but we are also able to do something about it.
So I won't go into the details why it's important, but I think we all agree
that it is important to do something.
And software plays a role in that. KDE as a project, KDE as in what we produce
in terms of software products, this has an impact.
Software has an impact on how IT is used, how computers are used,
how other devices are used, and we can do something there by focusing on doing
that in a more sustainable way.
And that was what this was about, about KDE delivering sustainable software.
And when we started with the goal, we basically approached three perspectives.
So the first one is to do alignment of what already was happening in the community,
also aligning with others more like sorting out
what is important there and trying to put it together
in a meaningful form the second area
visibility quite important because a lot of what we did there was not about
introducing new things but making visible what already happens in free software
and kde specifically there's a lot which is already paying into this goal of
doing sustainable software.
So making this more visible also to the outside.
That was the second part. And the third part, then concrete initiatives where
we did projects to improve things in a lot of different areas.
And what we did there, I will now show you in detail.
First, the alignment area. So you already saw the picture from the joint goal
sprint. sprint that really was nice that we got together there,
there actually was quite a bit of crossover between the goals.
So all the selenium work is really important to also automate tests to measure
energy efficiency. We will come to that in a second.
So getting together there really was a nice thing to bring people together and
to work together on the goal topics.
And what we also saw is that, basically, the alignment is that we had a few
individual initiatives where we put things together.
And it all, I think, culminated in the KDE eco-community becoming a thing.
So now we are really collecting things under this. We have regular meetups. We have a website.
And we have discussion forums and so on.
And i think we we are developing this common understanding that this is the
umbrella where we can really bring these topics together so a lot of that is
actually happening there,
i will talk about the individual points
in detail and when we come to the initiatives and
you will all find that on the website and that
actually was also a result of the sprint um we did
there we did some brainstorming there
you see some sketches there so this was a really nice initiative
to be in together there in person to be able to sketch things on whiteboards
and so on and we came up with a structure how we actually want to collect things
and present things and this is now actually live on the website reflected there
so addressing the three areas of users.
Who take benefit from using sustainable software then advocates want to help
others to understand what the issues are and do something about it.
And then the developers, so a lot of people here in this room who are working
on the software which is used by these groups.
And this all fits really nicely together with KDE's overall vision.
So what we really saw with the Sustainable Software goal and the values which
are behind that, that aligns with KDE's mission.
This is about control for everybody, for everybody with the digital devices,
with the software that they are in control of not contributing to this burning planet we saw before.
So this aligns very well and now we come to the second area of visibility.
So we also already saw that in the keynote, and this actually happened before
we started the sustainable software goal. We got the Blue Angel for Ocula.
And this really was, I think, you can ask a question how useful it is to have
a label for a piece of software when nobody else really has adopted the label yet.
But I think it sends a quite important message. It sends the message that it
is possible to do the sustainable software.
The criteria of the blue label make a lot of sense in terms of resource efficiency energy efficiency.
Also in preventing hardware to become obsolete and also
to give people autonomy about how they use their software so this is reflected
there we proved that it's possible to do with our software with free software
and this gave us attention so you see the award ceremony where we got the official
paper document with the Blue Angel on it.
And this also led to quite some other things which were only possible because we did that.
So one thing we did over the last year or so was we were being involved in revising the Blue Angel.
There was initiative by the Umweltbundesamt, the German Federal Environmental
Agency who was doing the labor,
and they were extending the scope
revising it and they asked for feedback where we
were involved with a couple of workshops we participated could
contribute our experience with actually fulfilling the
criteria and yeah the
result of that is now extended set of criteria
which not only covers desktop software was also servers and server software
and mobile software and for ocula that we checked that it basically means we
will continue and it will we'll continue to have the Blue Angel label so we
can work with us in promotion and everything else to continue.
One open question is, do we want to certify more applications? So.
So we have an answer. Perfect. So it's possible we have set up a framework to do that.
It actually has become easier with the revised criteria because the measurement
process is more flexible.
It's more about documenting than about following a certain procedure.
And we can help you with that. So if you're interested in your application being
certified with the Blue Angel, talk to me. Talk to the ECHO community.
We are well prepared for that.
And a few things happened also as a result of that, so this is one opportunity
where we got invited as an expert to a conference in the German Parliament about
design and sustainability issues.
Because we were present on the landscape with the Blue Angels, so we could talk there.
It was actually quite an interesting event, talking to the people who actually
are quite in line with what we are thinking there.
So I was surprised how much alignment there is actually to people outside of our community.
We usually don't really see that much because we are staying in our respective bubbles.
So it was really nice to get this outreach and meet other people there.
And another thing which also was indirectly triggered by the Blue Angel was
this article in the second biggest German newspaper,
where they had actually a pretty nice article about how programming is possible
in an environmentally friendly way.
So they reported about what we did with BuAngel, what this means for society
and for sustainability, and gave us a really nice audience there.
And that was not the only thing where we actually got press attention by what
we are doing there, which again, I think is a nice effect of doing these things,
which, yeah, visibility and.
And we also gave a lot of presentations, Joseph was very busy with that, on many conferences.
I also gave one of the more impactful conferences was the Bits and Boimer, so Bits and Trees.
That's a crossover of technology conference and other sustainability groups.
And I was talking there in detail about what we did to get the Blue Angels,
so if you're interested in that, you can watch the presentation, there's a recording.
And again, I think that was really nice because we saw that our vision,
how we see KDE, our values align with many other people's and many other people's values.
And there's a bigger crowd there than just us who was following the same goals.
So that was a nice effect of this goal to see that we are not alone.
This continues. So, some of the events, we are present now in many areas,
one example of a bring it back to life event going about installing software
on old hardware, we'll talk about that a little bit more.
We have a list of actually events and presentations, if you follow the URL there
where you can reach out to the people who did that, and also see the presentations
and many more things there.
And a different form of visibility, as I said, KDE already is doing a lot of sustainable software.
We already did that before, but often it's not very visible.
People don't recognize that. So one way we approached that was to add on the
Ocular website a nice new tab, which actually shows all this information,
make people understand why it's important and how free software does that and Ocular specifically.
So addressing all the different areas we are addressing in our software,
which are also covered by the Blue Anger.
So, some more initiatives we did where we worked on specific things.
So, one thing which I think helped us quite a bit in working on the Sustainable
Software Goal was that we already had the funded projects funded by the German Bundesamt,
to work on Blue Angel for free software.
That was the name of the project. So there we helped.
The idea was to put together information how you can actually get the Blue Angel
and how you can fulfill the criteria even if you are not going to the certification
that you actually have help with doing the measurements and what is involved in there.
So this is actually the resource, the handbook, which got out of that.
If you want to get the Blue Angel, start reading there.
It already contains a lot of information. probably needs
an update now after the criteria got revised but that's certainly still a very
helpful resource and this project got us yeah the funding to have people have
some time to get the community going to get projects going so this was really helpful.
And there's another project and this already was mentioned in the keynote this
morning as well the OptGreen project to help people to use free software,
a sustainable software, on older hardware so that hardware doesn't have to go to waste.
And this is now ongoing.
And again, I think having the goal helped us to get the project,
but also helps us to keep the activities and the goal moving.
So this is really, at the moment, current. So have a look there.
There are things where you can help.
And one thing I like about this project, that it's again about reaching out
to an extended audience,
reaching out beyond the technical people who are programming KDE,
but us going to people who align with our values,
who also think about sustainability, maybe from a different perspective,
and see where are the synergies, where can we get together,
how can we help them to get over the technical obstacles, but also learn from
them how to address things in a broader scope.
Another initiative which also was ongoing before we started with the goal which
was necessary to get the Blue Angel certification is KE-EcoLab.
So this is a measurement lab where we measure energy efficiency and resource efficiency.
We have set up a small system there where it's possible to follow the procedure
which is defined by the original Blue Angel criteria and
there was a lot of activity on this
making this more accessible so that you could
also do remote measurements also the tooling
using the automation which is necessary to do these measurements there we also
looked into this selenium based automation and different things so this lab
is available and it's the yeah it's continuing and we want to expand that Also,
I think this is now one lab.
The setup is not very complicated, it's not very expensive, so you could set
up a similar lab anywhere else if you're interested to do your own measurements.
If you have an old computer somewhere, the only thing you need is a measurement
device and some software to actually run it.
And a lot of things which helped with the Ecolab, but also beyond that,
happened in the season of KDE and some of code initiatives.
So we had quite a number of projects there looking into energy consumption and
different other aspects helping with the Ecolab.
So if you are interested in these, these are actually clickable links.
If you download the slides after the talk, you can look them up.
Yeah and thanks to to all the people there who helped with
mentoring that but also of course who are doing the projects i
think this really is a very nice way how to keep people
coming to kde helping them to grow and get really really good results from that
so yeah and in this sense I mentioned it before, but to make it a little bit more specifically,
especially with K-Ecolab, we had a lot of help from people who already worked
on measuring energy in different ways.
So the Umweltcampus Birkenfeld, that was the group of scientists who were working,
who have actually created the first Blue Angel criteria and the measurement procedures there.
So they also helped us a lot. We were in good contact, but also other groups
we met through this goal and what we did there, like Recoding Berlin.
I think they renamed themselves, but these are great guys who also have a similar
direction in what they're doing.
Um and and that's i think also quite helpful to
to get together so um that we can actually see how others approach that and
we can just broaden um our activities there because we are limited number of
people and i think we can need all the help we get so doing things together always is a good idea.
So, maybe a few words about what didn't work, what did we learn.
So of course there were a lot of ideas when we started the goal,
but not everything came to life.
So one thing we sketched out at the beginning was that it would be nice to make
it more transparent in KDE, where we already have documents explaining sustainability aspects,
where we have energy management measurements and stuff like that.
So the idea was to have something similar to the translation dashboard where
you can see, okay, how different applications are there.
So this didn't happen. We did, I think, that's basically all what happened there.
We have a sketch. I think the idea is a nice one. Maybe something happens there.
But that's where we, I think, didn't manage to engage the rest of the community
in a way that there would be any visible progress.
So I think that's one of the challenges there.
Another thing we wanted to do where we did a few steps with CAEcoLab,
but we are not done yet, was to make, adding to performance and other measurements,
but really energy efficiency measurements,
adding that to our CI so that we could have something like a sustainability
gate in our release process, making sure that applications are not consuming
twice as much energy as before without us knowing.
So having these tests integrated in the CI, that was one of the original visions
very long ago, but we are not there yet.
Again that is something of course which affects much more people and which also
needs more support from the community.
So it would be nice to continue to work on that.
But in general, I think one thing I perceived as something where we weren't
successful, although we achieved a lot, is that we achieved that as this KDEco
team, and that was a really good group, and it was nice to get new people in there as well.
But the engagement, and Karl also mentioned that, with the rest of the community.
We didn't manage to get many people involved there.
So that was, I think, I don't know.
My feeling is that we have a lot of sub-communities in KDE which work really
nicely together and have great results, create great applications and so on.
But these overreaching goals, these things which we really need people to come
together, I mean, we are here.
That's a great thing. But we are a very distributed community.
And how can we act more as one community?
I think we are a little bit separated there in a group of more decentralized communities.
Maybe we can really find ways how to
get together with these goals like sustainability or the upcoming goals.
I'm really curious to see what they are, but get people together.
So I can only encourage you to look into what is happening in the goals and
see how this could relate to the area where you are working on and how we can make a bigger impact.
Because as we have seen, KDE, I think we underestimate how much the impact is
we can have with KDE. People know KDE.
And I mean, we can get into the press, we can get invited to conferences,
we can do things which really make a difference.
So I think we should do that and use the strength of KDE as the one community we are.
Yeah, the sustainability software goal. So officially, we are now wrapping up,
but the goal work is not finished yet, of course.
There's still more to do, so the goal is on.
Please get involved if you're interested in that. We have a mailing list.
We have the community website where you can find all the information.
We have a GitLab group where all the projects are there.
So there are lots of things which still need to be done. so please get involved
and help with sustainable software in the future as well.
And during Academy there will be two BoFs I want to point out about specific
topics I mentioned before.
So one about K-Ecolab and one about the OpGreen project.
I think there also will be a presentation about the OpGreen project later.
So these BoFs, attend them. That's a great way to group.
Okay so the times are the other way around the opt green both is at 10 and the other one at 15.
So check the wiki to be sure you get to the right room at the right time,
so yeah um we don't want to plan it to burn we still want to have a good living here,
um so we have to do something we can do something as KDE I think we are in a
position to actually change things and we are doing that and let's do it together.
Doing q a now yeah cool come on up All right, now we have some time for questions
for all of our gold champions.
Yeah, does anyone have questions?
Test, test, test. Not a question, but in the context of the accessibility goal,
I would also like to thank NLNet for sponsoring some of the accessibility work
in Plasma Wayland. That's it.
Thank you.
So I have two questions. The first one is about automation.
I would like to ask about the switch from Fabricator to GitLab.
So actually, I would prefer Fabricator than GitLab because Fabricator actually
pressures you to write small changes.
And it will get revealed more quickly.
But in GitLab, you know, the merge request might get larger and larger and it's
harder and harder to reveal and it will get stale.
So what do you think about this?
Does this work? Yes, sounds like it works. Thank you very much for the question.
When it comes to Fabricator and... Uh-oh.
Apparently,
it turns out I'm a Terminator this is the mic like that does that work okay
I know how to use technology no I don't,
okay this thing goes over here.
Okay uh anyway the decision was kind of made for us because fabricator was abandoned upstream,
maybe it's right here i don't want.
Testing? No. Switch is turned on. Says Mike.
Is this better now? Okay, this is better now. Anyway, sorry about that.
So I was going to say to a certain extent the decision was made for us because
Fabricator was abandoned upstream
essentially and we wanted to move to something that was maintained.
I'll say that personally there were some aspects of Fabricator that I did prefer.
Some of the things that you're talking I also preferred Fabricator's very flexible
task tracking system that was quite freeform.
Tasks didn't have to belong to a particular project.
But one thing that's really nice about GitLab is that it's very extensible.
So we've been able to do a little bit of what you were talking about in the
form of merge request templates, for example, that encourage people to write
a test plan and split their changes up into smaller pieces. This is something that isn't universal.
It doesn't come for free. But
we are all free as project maintainers to adopt it in our own projects.
And several KDE projects have now adopted this.
I'm always in favor of more projects doing it.
So I think even if there are aspects of GitLab that are imperfect,
we can extend it over time to make it better, which is a good thing.
Thank you.
I think there was a follow-up question.
So a continuation of this.
First of all, although Fabricator is abandoned, there is an active fork called
Forge, and I personally am using it, and I like it pretty much.
And another thing that Fabricator allows you to do is to stack the diffs.
Like if you have one change that depends on another change that is pending review,
it will make your life much easier than GitLab.
And actually, I'm using both Fabricator and GitLab, and I have a way to make
the Fabricator use GitLab CICD.
If you want to do something like that, you're free to talk to me about this.
Yeah, thank you. Those sound like some interesting improvements there.
Without getting too much into the technical weeds here, I might recommend that
you reach out to the SysAdmin team.
They're the ones who maintain our infrastructure, and it might be that some
of the technological improvements you've discovered or invented could be broadly
useful to KDE. So, I think that would be a good resource for you to reach out to.
Hey, check. Yeah. Hey, so there's a project called, yeah.
There's, there's a project called open QA that.
Check check check okay does it
work okay so there's a project called openqa that
helps with dating testing your party
system as a whole it's using open susie
and fedora and i think it would be great if
we could in some form get it into kd infrastructure
um is that like some so
i i've never used selenium so i don't
know exactly how much you can test with selenium but there are some things that
like require the full operating system to test and so that would be a good candidate
to have this right test that involve the full cycle of the of the system so
yeah it's not a question sorry but it's a suggestion,
testing okay so this is um it's cornelius directly addressed the issue of trying
to engage the community the larger community and it kind of came up in carl's
presentation as well and it's kind of related to the automation and systematization
i'm just going to yell it out.
I just wanted to ask if.
So the question was what can we actually do to unite the goals to get the activities
more broad to involve the whole community.
So I already touched that a little bit. I think for me, one thing which is missing
is this kind of central place where the community can meet not only at the conference, but also online.
We don't really have that in any way. So where things can be presented,
where people meet, where you can read about what KDE is doing as a whole.
That would be one thing I think could help with that. But what's your thoughts?
Yeah, I would agree with that. I think at last Academy, Joseph,
you gave a presentation about our communications channels and how we often have,
it's like a system of highways that go in all different directions.
I think at KDE, we're very good at categorizing and subdividing and putting things into buckets.
And I think we're often a little bit less good at broadening and seeing the
connections between disparate things.
So I would share the idea that if we have a place to come together.
Venues, largely online, because that's how we work, where everybody can talk
together and we aren't limited in scope to a narrow subject,
I think that could help us to see the connections between things.
Yeah, and to extend a bit to what Ava said,
I think like a bit more public communication and for like what we saw with the
accessibility goals is that I wrote like maybe like two,
three blog posts in the two years and that might be not enough,
there need to be like regular communication to the community,
to what the committee see what's going on and my apps involvement movement.
Thank you.
I think that we are all we are
all uh all of kde is eco-friendly
so my main question is how far along are we to get this everywhere and if is
it even possible to uh to do this automatically for applications instead of
having people go to eco labs and make more manual testing,
yeah so the question how we can get more of this automated testing and where
are we i mean with getting this overview you saw where we are we have a piece of paper with a sketch,
regarding integration with the ci.
The current measurement process of the blue angel has has a problem that basically
prescribes a physical setup where you need to put a measurement device in front
of a computer so you need really this physical thing in one specific way.
It is remotely accessible already.
If it's good enough to be integrated in a CI where it has to work reliably and
not break the CI for no reason, that is something we have to see and have to try out.
From my point of view, it's a matter of iterating and I don't think we should
enable it for all of KDE as a whole thing and see what what breaks,
but really make it useful maybe for Ocular as the first application where we
already have all the setup done.
We need to write usage scenarios for other applications.
We also have some of them, but then we could gradually enable it step by step by having,
one application after the other enabled with that and see how much of automation
actually also makes sense because we have to balance the effort we put into
the automation to the the value of the results of that.
Sometimes it's not very easy to measure the energy efficiency of an application
and might just be overhead we introduce. Because that's another aspect.
CI also needs energy. So we have to see how we can be smart about not introducing
more energy consumption and trying to be more energy efficient.
I think that was a very important point. This also gets to the previous question,
which is how can we make the goals more visible?
I think anything that we can do to kind of push information in front of people
who don't see it, that helps.
So in this case, for example, if we have eco stuff in the CI,
developers who aren't accustomed to thinking about that, all of a sudden have
exposure to it because they push a change, the eco CI turns red,
and then they'll say, oh, wow, this change regressed the energy efficiency of
the software in a way I didn't even expect.
And that's a way to gain experience of familiarity with the topic that you might
not have, it might have been invisible to you before.
Hello. Yeah. Okay, so the question about the KDE co, you are saying that we
were not able to reach out to more people.
So I think two questions regarding that.
Have we tried reaching out to some of our open source community friends,
like, for example, genome or as such?
And have we tried including them also in the same goal kind of thing?
And second question is
like one thing or one
general idea i see like
the giddy eco project is like it is limited to a lot of what is being done in
the europe rather than having it part of the like global community so are there
any already like plans or discussions happening in terms of like extending it
outside of the europe Cool.
So this is the key question, right?
How we get more of the KDE community involved and more of the global free software community involved.
We actually had quite some conversations with other projects about the Blue Angel certification.
That was one hook which worked. For example, we had a number of discussions
with the Document Foundation where they said, okay, we are really interested
in that, but we can't do it.
So we first had to show them that it's possible to do it.
I think we also approached the Blue Angel there with
a little bit of a hacker spirit not following the
letters of the word but following the spirit and this
worked out quite well so explaining that to
others where you can maybe compromise on some things and still get forward that
that helps quite a bit so and i think there's still a lot more to do um i would
say so we what what we have with the free software um the blue angel for Free Software project,
what we saw is the fact that still Oculus, the only application,
shows that the adoption of the label itself in the industry was not as they would have hoped for.
So there's still, of course, a lot more to do.
At the moment, I think our focus is more on users with the next project,
so less about the community, friends and family.
So this would be something where you all could help with your individual projects
with the specific groups you are in.
And also, if there's opportunities where we can bring this in,
we are not taking at the moment.
So I don't know, conferences, free software conferences where we are not presenting
the stuff yet or not getting into conversations with others.
We should use that. I think at the moment it's not really on the top priority
of the agenda of the eco-community, so outside input would actually help a lot there.
Short question i have a question about the energy measurement does it work in any,
hardware and produce the same results or for example if we run it on amd or
until it produces different numbers so can we have the same numbers running
the test locally compared to the candy the infrastructure?
Yeah, so the system at the moment is focused on the procedure which is prescribed
by the Blue Angel, which specifies a specific computer you have to run it on.
And it's not meant for comparison, but more to get some impression about the
consumption and that you can compare over time how it changes and so on.
So this is not very much in focus, these comparisons and so on.
But I think with the current systems, it's possible to implement that and do that.
And I personally would think it would be quite helpful to look more into not
only do the measurement as a means to get the criteria fulfilled,
because that's kind of a formal thing, but more really to get an understanding,
compare different hardware platforms, different software frameworks,
whatever, to get an impression what actually has an impact on the actual energy consumption.
Consumption so but again that is something where i think there's still a lot to do,
thank you so much um to you and everyone else who helped with the goals we just
wrapped up and in five minutes we will start revealing the new ones.