About seeing what you all voted on.
All right. So what we're going to do is we first talk a bit about,
who here has actually proposed a goal this year.
All right. Very good. Very good. Good. Then.
Goal number one.
We're doing drum rolls, but not like that.
All right. Goal Goal number one, streamlined application development experience.
I see that is getting some applause. So you like this one. Very good.
This is how this is supposed to be. Goal number two.
Goal number two is we care about your input.
And the final one.
The third one is KDE Needs You.
Formalize and boost KDE's processes for recruiting active contributors.
Thank you everyone who has proposed the goal. and what we will be doing now
is getting the people on stage who proposed these,
who is here come on people.
Hello hi do we have anyone yes very good All right.
What we're going to do now is have all of you talk a bit about your goal. What is it all about?
It's all about the apps, in a way.
So, jokes aside, it really is a continuation of some of the goals we had in the past.
First and foremost, the all about the apps goal, which was great.
But it focused a lot on everything around applications, how we advertise them,
how we build them, how we deploy them, but not so much about how we write them.
So that's why I want to come in. But it's also an extension of,
for example, the consistency goal, the usability goal, the accessibility goal,
the automation goal, the sustainability goal.
I want to take input from all of these goals and also everything else and make
sure that we have all of the technical and non-technical things in place that
people can write and enjoy great applications.
Okay, so I've been involved with the input goal. We care about our input is
not meant to be about user feedback in this case. It's a slight...
I mean, we care about that too, but this is about the input stack.
So any kind of input devices you might be using, your mouse,
your keyboard, your game controllers, your accessibility needs all of these things,
KDE has many good foundations to build on and there are small things missing
in many of these areas some of them are sort of easy fixes we just have to figure
them out others are medium-sized projects,
and this goal is about trying to figure out how we can get from something for
everyone to something really good for everyone.
So you can stick with any one input device or you can use all of them in combination
with most productivity, good accessibility, all these things. Also, where is Joshua?
He just has his talk, but he's missing here. He should also be on stage.
Stage um yeah i don't know what what else to say right now i'm not prepared
so i'm gonna hand it over okay thanks.
As you can see, I was prepared to come out on stage, you know,
dressing like a nine-year-old going to camp.
Yeah, ours is more like soft skill-like thing because we're not so technical.
We think that there is a fundamental problem that would probably interfere with
the continuity of KD if it becomes a really,
really problematic problem, which is that as you know a lot of the original
open source developers are getting older.
Right and we need renewed blood we do have new people coming in all the time
and it's normally coming in through things like the mentoring programs and stuff
like that but there's the people who do the mentorship know uh the number of
people who stay on is normally very very, very small,
talking about maybe less than 10%.
So we want to reinforce that. We want to reinforce that.
We want the mentorship, the people who are just doing Google Summer of Code
and Season of KDE is going to become the mentorship team,
I guess, and will include recruitments.
So we're going to take on more mentorship programs. We have talked with the
people who do mentoring, with Johnny and other people.
And we already started with a Chinese mentorship program.
And we're going to expand that, and we're going to include recruitment,
and we're going to include talking to academic institutions like schools and
technical schools and universities, et cetera, so that we can get more people
interested in KD and doing stuff in KD during their courses.
So we're not going to be looking only at recruiting individuals,
but we're going to be recruiting institutions that will supply us with people to work on KD projects.
Because as we know, we have plenty of KDE projects that are awesome and big and complicated.
And there's only maybe two people working on them. And that is a problem.
Okay. And I mean, the people at KDE Live back there are shaking their heads
and saying, yes, that's us.
I mean, but we could look at the people who are developing Plasma or Krita or
whatever. However, many of our applications are great, but they're really small,
and there's maybe one or two people working on it.
Well, I mean, in the case of Tokodon and NeoChat, there's not one or two people.
It's like one person divided into 50 different projects, right?
So this is a problem that could become, and I don't use this word lightly,
an existential threat if we do not increase the number of people contributing
to the code base and stuff like that.
So this project is doing everything we have to do.
It's very ambitious to change that, to have a constant stream of people coming in.
Hoping some of them, a certain percentage, will stay, and then we can ensure
the continuity of the KDE project and all its applications and the desktop, etc. Yeah.
All right. Then there will be more questions.
So one thing you might have noticed is that this year there were more names
than just one for each of the goals because we said we would like to have a team behind the goals.
For the first goal, we don't have a team yet. But are you looking for someone?
And if so, are you looking for someone specific to help you?
I'm looking for everybody.
No, I'm the solo champion that is named on the goal.
But there were a lot of people in the fabricator task indicating that they are
willing to help so I'm looking forward to all of them helping out with that.
And for your goal who else was on the on
the ticket yeah i mean our goal was a
team effort from the start sort of uh gernot who's not here at academy uh proposed
this it was it was his initiative um he talks to a lot of people on in chat
rooms uh support in general um He came up with this.
I helped to spread it out a little bit, expand the scope.
And we also have Joshua Goins on it, who really provides the technical deep
knowledge that we also need to guide this forward.
So hopefully we have some of every expertise on it, but there are a lot of components to it.
So we definitely hope this is going to be an inclusive goal.
We made it deliberately a little larger than just the three of us could necessarily do it.
We're going to rely a lot on the community. There are some people who have projects
going on that already go into this direction or who have started something that
needs more work, that needs other people,
and they've been distracted by other important projects.
So we really want to get everyone into this boat, helping out.
Hopefully we can do a little bit of publicity effort because that's what being
a champion is all about as far as I understand so we'll try to help people find
the right kind of work that is good for them and also support them where we can let's see how it goes,
And how about you two? We do have kind of... Is it working? Yeah.
We do have a kind of a team.
Well... I'll pause. Her?
No, and there are several people who have also pledged to help us out.
This project is kind of integral of Promo, because Promo, you must remember,
is pro and communication.
So we have to communicate with all these institutions which we have already
started doing going to some events where there have been academic institutions
and companies etc they've come to us with tears in their eyes well no,
but they've come to us and said,
what can we do or what can I do for my students or how can our company help
And the answer is always kind of like, well, get them into mentoring and stuff like that.
So it's part already of Promo's kind of job to do this.
We also have as allies the people who are working on the mentoring.
They did not have a website and we pushed them to have a website.
And now they have a website.
And it's not Google Summer of Code and Season of Katie anymore.
What it's mentorship so and there we can include all that so as I said again
Johnny and what's the other guy.
In the mentorship with us, Johnny okay, Johnny and the other guy I can't remember,
yeah so they are
going to participate actively in this project too because basically that is
what they are going to end up doing our project has a clear goal which is the
mentorship program become a mentorship recruitment program,
by the end of the two years and will just be another part of KD like any other
project, right? So that is our objective.
Yes? Not too related, but just be careful of this guy. He's going to drag you.
And even if you're not interested, he will just approach you and say that,
I don't care, you just have to work on it.
That's what he did with me and Nate. it so yeah be prepared well yeah fix everybody
i mean come on so that you know there's my team.
That's the spirit which actually brings me to my next question for all of you
is on the one hand the goals are here to unite the kitty community around some
common causes and on the other hand it's a great way for getting people who
are kind of on the fringes and maybe thinking about helping out in KDE to give them some direction.
So do any of you already have some ideas what someone from the outside on the
fringes or someone from inside KDE could do to help move your goals forward?
So part of my goal is also making it easier and encouraging third-party applications to be KDE aligned,
making it easy for them to use KDE libraries or otherwise make applications
that work nicely together with Plasma but aren't necessarily a part of KDE and
also by that encouraging outside contributions to, for example, KDE frameworks.
So I think that's a great angle for bringing new people into KDE and generally
also showing the world that we
have nice software which naturally also attracts new people all the time.
Yeah. So for the input goal, the goal description,
the proposal was split into different parts, generally mapping to the various input devices.
And each of those has things that we can do about it. I think there are some
areas that might require deeper involvement or learning.
Anyone can take it on, but getting involved with Quinn on the input side directly.
There are other things that can be done on the settings front.
System settings can use a lot of work
for drawing tablets, for improving configuration for mouse and touchpad.
The keyboard KCM has recently been rewritten, so that's in pretty good shape,
but there are things that need to be done in order to make all the features or the.
Ways to input your commands to make that configurable so that can be done by
other people that jump in,
anyone can jump in so it really depends i think we'll have to look at the various
tasks um it's going to be our responsibility to make a good list of these tasks
to promote what can be done um and then find the right people for it.
I think in many ways what what
we are trying to do affects both of these projects
as it affects most other projects i mean you're trying
to improve the the experience of developing for
applications in general this is
something that we have heard quite a lot you know because i don't
know how to start we we hear this a lot
so by uh working with
the other goals and with uh the
organizations organizations from outside for example
with technical schools and things like that we can
probably get not only get new contributors to contribute code which is basically
what we are thinking of right now.
We're not thinking of necessarily of users, we're thinking of people who actually
contribute actively to the community.
We can get people into to these projects.
And if, no, if no, when you achieve your goals, sorry, when you achieve your
goals, this will make it easier both for us and for you, you know.
So, yeah, we have been talking to, we have been to several events recently where
we have been talking to especially lots of schools and things like that, right?
And they are thinking, oh, how are things like end-of-year projects?
And so an end-of-year project could be a KDE project.
It could be like a Google Summer of Code project, but organized within KDE.
The problem is that our calendars don't normally coincide with end-of-year, right?
So we would have to think of how to do that. you
know change our calendars and so on but yes we have
talked to several institutions we have them we have them we
have their contacts we talk to them often etc and
we're trying to figure out how we can get academic institutions
into that we're also going to talk to people who
are outside this room in the
hall right to get them to because we
have also have several um companies
say how can we contribute more well so if
you have uh uh people doing stuff that
uh you know you give them 20 of the time to work on
stuff like uh they want well try and convince them to work on kd stuff you know
because it's relevant to your business or new recruits that need to brush up
on their c++ and qt and stuff like that well so we have talked to people uh so we are working on it.
That's great um thank you so much for being good sports and uh taking the plunge
in the deep and love the ball with me um and now we have some time for questions
from the audience do we have any yes.
This question is directed to
katie needs you um so one
of the problems of like uh recruiting
contributors is that my uh
if you are doing a mentoring session
they might only
see the projects as
like a side project
and not really committed to it and
after the session ends they might like uh like give it up or just uh like use
it for you know to get a job which does as proprietary software,
and after that, they might just stop doing free software, which I think, well, is unfortunate.
What can you do to reduce the possibility of this happening?
Yeah, you know what? That's fine. People come in and do stuff and maybe use
it to get a job and then move on, that's going to happen always.
The thing is, I don't think we can actually reduce the amount of people,
the percentage of people who do that, the proportion.
I mean, let's say that of every 10 people, only one sticks around for longer
than a year or something like that, okay?
But the solution is not to focus on that one.
The solution to that is instead of going to 10, it's to go to 100,
and then you end up with 10 people sticking around and now you have a team, right?
So the purpose of this is not to solve that problem because you can't of the
number of people who just leave, just do the Google Summer of Code and then
fuck off, you know? You can't do that.
But what you can do is get more people.
If you have an actual mentorship and recruitment team, you can get many more
people in and then you will end up at the end of the year with many more people sticking around.
So it's a question of not proportions but absolute numbers, right?
Does that answer your question? Okay.
I have a question about the KDE NSU, about involving students to make some world
code contributions and so on.
So we have a lot of institutes that teach programming in C++,
JavaScript, Python, Devolves, and every day they do some tasks to learn.
And the teacher can, Instead of giving some virtual tasks, they can choose tasks
from KDE software and give them to students to do.
For example, five students will do the task, and the best student will be chosen
to commit these changes.
And this will be a lot of students that will be involved into open-source software
from their childhood, from their studying.
And then it's really
a lot of free resources and it's interesting and they
will be motivated to continue this so do you
have some ideas about how
to involve teachers from institutes into this process yes
mostly we've have in the events we have been to we have been to i don't know
uh i have personally been to like three this year where we have talked to the
teachers and the teachers Teachers have actually asked about how they can get
their students to contribute into free software.
And they're thinking along the lines of getting students involved in free software
so they can do stuff academically.
So they want to help teach,
but they also want us to be able to
provide uh stuff like end of
year projects or uh stuff like what you're saying right get them programming
for uh kd so that they can test their programming skills and things like that
yeah it's it's it's basically what they're thinking of so i i hope this happens
because there are several,
every academic setup in each country of Europe, which is what I have been looking
into at the moment, is different.
So we're going to have to do stuff so that it works legally in Spain,
and then we're going to have to do other stuff so it works legally in France,
and we're going to have to do stuff so it works legally in Germany,
all different stuff, right? Right.
But yeah, that is more or less what you said is more or less the idea.
Right. So KD become part of their academic work.
Right. Hopefully some of those will also get inspired and will also become regular contributors.
Right. Because it is also true that many of the people that come into KD come in as students.
So, you know, hopefully that will also contribute to that. Okay.
A very broad question for the streamlined application development experience.
Just listening to the KDE Needs You, I was wondering how you think that goal and your goal align.
It aligns in the sense that a huge part of my goal is outreach to potential
application developers,
both people who have never written applications themselves or have written applications
but aren't KDE aligned or part of KDE.
So that definitely is a huge overlap.
Also, in terms of outreach specifically to, for example, schools and universities,
encouraging people to get into real application or software project development
with concrete KDE projects instead of academic toy projects, maybe.
And just showing people that open source is a very nice path to get real world
experience, build skills, build employability, so to say.
So yeah, outreach is a very, very important part of my goal.
I was intrigued by the diagram Nate showed, this mountain skype of KDE developer
generations where you could see their peaks and their valleys.
So my question and that I think is to the KDE Neets You, but maybe also to the
development goal, what do you think we can learn from these numbers and how
could we use these numbers to track progress?
Well, in that graphic, there's a clear peak at the beginning of KD5.
That great peak is at the beginning of KD5. Then there's a smaller peak at the beginning of KD6.
Obviously, people like new shiny stuff. That's one thing we can learn and like
contributing to new shiny stuff.
Stuff the thing is that kd has
much more new shiny stuff than
only plasma if we can get that message out
there yep and also uh every uh uh so so many years uh uh a kd application comes
along that takes the world by storm like critter came along and now kd live
is coming along and they They are really bringing in a lot of people.
Most people don't know that there are KDE applications because they don't know
that KDE exists even, right?
They just use KDE Live. They just use Krita. They never think about the K at all.
So if we can transmit to the rest of the world that KDE is more than that and
we have more shiny stuff that comes out with a regular,
We can probably help sustain those numbers so that it's not only peaks when new plasmas come out.
And we can have a steady growth, which is what we want.
And people who contribute to KDE projects tend to contribute to several KDE projects.
So hopefully that will filter to other projects, so
people who start maybe developing for tocodon or
or uh camel or whatever
will also end up contributing stuff to plasma so or you know it's one of those
situations where a rising tide raises all boats hopefully that is what we want
to attain right does that answer your question.
Something we that we've seen in the graph and also
from general community experience and it
was already mentioned before is that we are very multi-generational community
so we we have multiple generations of people coming in maintaining things and
then leaving for some reason or another and many projects can be traced down
to really the end of the 90s when it all started,
like KMailCureOrganizer, really one of those applications that live on forever.
But we also have a lot of applications that are much younger and replaced older applications.
For example, we have ELISA, which is, given the overall history of KDE,
a very young application, which, well, not technically, officially,
but in spirit, a bit replaced older applications like Amarok.
So in a way that's a good thing and in
a way that's a bad thing it's a good thing because it shows
that people come in and want to create new applications and
our platform is attractive enough for people to
do that but it's also a bit
of a bad thing because we sometimes have
a pattern of there's an application it it
grows and matures and then sometimes it
starts crusting and squeaking and then somebody
comes along and thinks I want to make a fresh new application and
something I want to also work on is not only encouraging new applications but
also making sure that applications age gracefully and can live on a long time
without becoming obsolete and need replacement at some point.
Very cool. Any more questions from the audience? Peace.
Yeah maybe not so much a question but a comment on your last statement,
and maybe it's a good thing to have new applications that,
reduce the amount of old code if you can.
Make sure that there's a core a stable core that that transfers the knowledge
embedded in the application.
So if I have a core library and my Shiny application is built on that library
and it's doing all the work and it matures, it gets older,
it gets harder to contribute for new contributors,
because naturally that's the way it goes.
And then afterwards you can write a new application that just takes the core
part and then makes a good, nice interface on that.
Yeah, absolutely. I think a very good example of this pattern we are seeing
right now in KDE PIM, we have the traditional applications like KMail,
KOrganizer, KAddressBook,
which are building on all of the foundations like Akonadi and now we have new
applications like Melkuru, Which take all of these building blocks that are
already there and don't need to be reinvented and build a fresh,
modern user interface on it with different goals than the original one,
but still benefiting from the decades of work that went into the old system.
ScanPage versus ScanLight is another example of that. There was a new developer
coming in, taking the old library and even drawing in the previous maintainer
to improve it a little bit.
Yeah, so it's a good strategy.
Thank you so much to all of you. Now it's on all of you to help them make all of this happen.
Because this is not only their work. and some of the things you can do is join
the BoFs on Monday there will be BoFs one for each of the goals,
and you can also join the Goals Matrix channel that is on the slide,
and with that thank you so much thank you,
well that was really great thanks guys for the new goals So now we're five minutes
early or so, but that's okay. So up next, we've got lunch.