No response from the original author, so I'm overriding the proposal

Does a bakery need smartcard login or LDAP though?

Here's a (somewhat superficial) list I gathered from various proposals and other conversations:

The proposal talks about adding "API" for configuration management, but we already have means to do that (KConfig from C++ and CLI tools like kreadconfig/kwriteconfig).

I think there is a lot of merit in targeting/improving business/enterprise use cases. The current proposal is a bit short/unspecific though. A combination of this and T11080 (and also T17448) could work well though. Is someone here interested in writing that up?

Here's my take on this goal:

All application will have to come under the same API framework, so you won't have to config each application in a diffrent tools, or diffrent config files

This assumes that removing functionality actually results in less resource utilization, which isn't necessarily the case

This overlaps quite a bit with T17424

You can absolutely design an application layout without knowing how a button looks like. Arguably you even _must_ do that, because how the button is going to look like in the application won't be pixel-for-pixel identical to your design anyway, due to user-specific fonts/font sizes, color schemes, application themes, future design changes etc.

I would avoid explicitly talking about "big" or "small" businesses and just target both

Generally I do think that we are lacking a design vision, so I welcome any proposal to address this

The technical points all have merit, but centering the goal around sandboxing is a bit odd. Sandboxing is a means to an end, where the end is mostly security (and to a degree reliability). Maybe we could rephrase the goal around that?

To me it doesn't matter that much whether applications are first-party or third-party. The important (and more actionable for us) thing would be to make sure our application development story is as good as possible. An uptick in third-party applications would be a sing of us doing something right there.

What makes Redox OS worth supporting, and what does it have to do with Qt?

The days of X11 are numbered, no matter which way you slice it.

Implement more things in the dbus of org.freedesktop.secrets

In T17372#307267, @snoweuph wrote:

In T17372#307262, @nicolasfella wrote:

A goal should be more than a list of your personal feature requests. It should articulate a vision for a specific topic/area of focus. Everyone should be able to look at the goal description and derive their own ideas/todo items from it.

Just giving a list of semi-related feature requests isn't particularly useful, we do have bugs.kde.org for that

I did update the description to fit a bit better.
I'm going to see, if there are already feature requests/ bug tickets for the examples of things to polish, and replace them with URLs to them. (and for the ones without a fitting one, I'm going to create one / tell the other people to create theirs for)

Frequently Asked Questions:

I don't see much concrete content in this proposal, other than "something with cryptocurrency".

A goal is something the entire KDE community (which is far larger than just Plasma) should rally behind. A proposal that solely focuses on window management isn't really suitable for that

A goal should be more than a list of your personal feature requests. It should articulate a vision for a specific topic/area of focus. Everyone should be able to look at the goal description and derive their own ideas/todo items from it.

A goal is supposed to be something the entire KDE community should focus on for the next two years. If the proposal can be summed up as one bug report it is not a suitable goal

SlaveBase is now internal, can be cleaned up at any point

This is "solved" by dropping ResourceInstance: https://invent.kde.org/plasma/kactivities/-/merge_requests/34

I made MRs to adjust the CI config for all consumers

There may also be cases where we prematurely ported to kcmshell6 and we need the ability to open a Qt5-based KCM. This could happen e.g. when running a KF6-based app in Plasma 5 (assuming that's a supported case at all)

WindowEffects was clean up in https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/120

Do we actually use the checkForConflictsAgainst in KeySequenceItem anywhere? Quick grep suggests not

https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1762

"solved" for now by https://invent.kde.org/network/kio-extras/-/merge_requests/296

My proposed course of action:

I got confused by my incomplete Gnome installation, Gnome indeed ships gnome-applications.menu and this is a non-issue

This isn't about services in the KDE sense though, it's about applications. (It's not about konsole*part* but the actual Konsole application)

'service->property("Foo", QMetaType::QStringList).toStringList()' is a bit of a mouthful. Can/should we make it something like 'service->property<QStringList>("Foo")'?

Other things:

https://invent.kde.org/system/kup/-/merge_requests/23