I agree: this is still a default assumption for me, that free software is intended to run on personal computers. The PC experience (which includes KDE) is not the same as the mobile-first/online/cloud experience. And yet there is room for mobile operating systems to be more PC-like too.

OK, that makes sense.

Personally I agree with you, it's just that these goals have to be actionable at the community level. Professionalization involving more paid employees, a formal management chain, etc. are all things that basically have to be done by the KDE e.V.; there's little an individual member of the community can do about it. So by removing those elements, the goal became actionable. Given how popular those elements seemed to be, I still plan to pursue the professionalization idea from another angle.

In T15627#279336, @lydia wrote:

I'd very much support this. It addresses a major problem I have with the proposal as it stands. (Happy to jump on a call to bounce off ideas if that'd help you.)

The other problem I see is the title: do we want to talk about "professionalizing KDE" for the next few years in our public communication? I'm not sure we're doing ourselves a favor by portraying the current situation as unprofessional. Maybe we can find a better framing for that? (I don't have a good idea yet.)

There was a very similar goal a few years ago in the first round of goals: T7116

Oh really 😂

FWIW the time window to add new goals for this round has been closed for several weeks now, and goals are already being voted on, so this is too late to be considered.

In T15647#277682, @niccolove wrote:

File indexing, as an example, is not a feature that you can simply remove or disable by default. It is something that users rightfully expect out of their operating system.

@jpetso Thanks for bringing up your thoughts. You mention a lot of valid points, and you are right that labs and certifications are some of the tools, but that they are certainly not enough to fully cover the topic of sustainable software. We do need to think beyond that. Currently the criteria for the Blue Angel are a great starting point, because they are concrete and actionable. But they also only cover one specific perspective. They are meant as first steps and what you mention about the effect of hardware and making this and other sustainability aspects visible to users is very much in scope of this goal. We don't want to prescribe how this is done, but use what research and community come up with. So while the plan focuses mostly on what we know how to do today, I would see it as a very natural evolution to add other ways to support the goal of sustainable software while we are going and learning.

In T15624#279787, @adam wrote:

The voting starts in a week, so any changes that you intend to do should be done soon :)

Hi @pgess, thanks for the comment. The book How We Became Posthuman by N. Katherine Hayles is probably the best book to fit the "plain English" requirement. The latest two books from Arthur and Marilouise Kroker, Exits to the Posthuman Future and Technologies of the New Real also explore the problem in depth, albeit in a more difficult prose.

Thanks for excellent articulating of the importance of this issue.

I'm a little late for commenting but I'd like to add some thoughts.

I'm happy that the discussion has come back, but sadly the proposal has missed the deadline to be included in the voting.
Of course, feel free to continue using the ticket for discussing the ideas mentioned in the proposal.

Centralization of documentation should definitely solve a lot of problem. About User documentation I do agree that every app are different but core KDE development tools or any kind of development documentation/tutorial should be centralized. But even in case of User documentation there should be proper guidelines and APIs to organize all the documentation from KDE applications.

I agree with Carl's feedback - just note that "add rst" or other formats is not so straightforward as it may seems.

My feedback on the state of documentation in KDE:

I am adding some additional steps that I understood from the feedback. Not being a software developer is a huge disadvantage for me, but I wanted to start the discussion.

In T15621#280077, @Nowshed wrote:

As other users have mentioned, the solved part is not actually solved. The main git based documentation is kind of stalled.

As other users have mentioned, the solved part is not actually solved. The main git based documentation is kind of stalled.

I was extremely busy with my professional life. Let me see what I can do now.

Thanks @joseph, I added a summary at the beginning of the proposal.

I think this is a very valid goal, and I think it totally deserves to be voted. I'm willing to focus on this if it gets selected, so I'll step in to make sure it gets its chance. If Janet wants to come back to the community and lead this goal in the future I'll be happy to shift this to her anytime.

Yeah, I agree with that. You can close this goal, or whatever is the proper procedure.

It's a shame, this is an important and actionable goal proposal. Is anyone interested in taking it over? Or is @Nowshed still around?

As the author did not act on the comments here, I will not move this proposal to the voting stage.

As the author did not act on the comments here, I will not move this proposal to the voting stage.

@ws I agree that this could be part of the accessibility Goal proposal, based on this discussion I propose to not move this to the voting stage. Of course, feel free to submit your ideas in the other proposal!

Thanks @cwunder, based on your response, I will not move the Goal proposal to the voting stage, but you're very welcome to talk to our Promo team to discuss the overall ideas of visible collaboration between the two projects.

Move clang-format from a git hookscript to pre-commit CI so that merge requests will show a CI failure when badly-formatted changes exist, and people can see this in a nice UI and fix them