I don't think it is *all* doable indeed... but if the author of that goal put some more research effort into it to improve the wording it could become a strong follow-up goal to the on-boarding one. Indeed, helping users to turn into contributors would be really nice. Even though some of the point in there are a bit shoot-to-the-moon like, some others are actually very doable I think and would help a lot. Please, take time to improve it, I think it could pay off. ;-)

@ervin thank you! I didn't think anybody would notice this and actually reply...

First off, I don't think that there's anything in the wording to improve, or any research to be done... it's not that the text itself is unclear, but that its meaning is psychologically difficult to accept, because the moment you accept it, the realization of just how much progress the free software movement has robbed itself of when it comes to the desktop will hit you like a wrecking ball...

What's the lifeblood of proprietary software? Why, it's DRM, which propels it towards new horizons at the speed of light!

What's the lifeblood of free software, when it comes to desktops? It's clear that desktop free software will never be profitable, so much of it is volunteer work.

For people to do something voluntarily, it has to be fulfilling enough and frustration-free enough. Because software development is obviously a computer-related activity, it has to compete with addictive proprietary games and social media, which means anything but one-click initial setup, less than 5 second iteration time, and instant access to documentation for any given function should be considered unacceptable. I think that psychological barriers are just as impenetrable as legal barriers and lack of free time and should be given the same amount of attention.

Most of the times I try to raise this point I get back hostility and accusations... I've got a theory as to why: making development frustration-free would be an amazingly huge boon for free software, but there there's one huge and obvious problem that stands in the way of doing it that's impossible for any one person to even begin to solve, not to mention the general shortage of manpower, and thus free software fans prefer to convince themselves that everything is the way it should be and suggesting otherwise is clearly a tell-tale sign of trolling... this is self-perpetuating and becomes worse with time, because as free software keeps missing opportunities, thinking about what could have been becomes more and more disheartening for a free software fan.

So what's that huge and obvious problem? Let's look at one of the main criticisms of Linux: that you often have to compile stuff yourself... so what? It's the computer who does the compiling, not the person using it, right? Well, it all goes back to a basic and simple truth that Linux and C++ truthtellers have been pouring into everybody's ears for probably almost the entire time they both have existed, only for the said truth to flow back out of the ears of the very people who have the power to make any meaningful impact, right down the drain... I think everyone here can already guess which truth it is...

The truth is that the world of Linux, C++, build systems, and documentation generators is too fragmented for fully automated setup of development environments to be possible. This is extremely difficult to overcome, after all before the Language Server Protocol it was obvious that auto-completion could be and would be nice to standardize, but it still took Microsoft to get any kind of auto-completion standard to be widely accepted.

That said, I don't think that this is even an unreasonable goal when it comes to applications... GNOME for example is currently way ahead of KDE on this front: for most GNOME applications, you can enter the git URL into GNOME Builder, and have dependencies, auto-completion, documentation access for at least for GLib-based libraries, etc, automatically set up for you, thanks to Flatpak and its standardized software base. Maybe KDE could do the same, but present this feature to everyone, even to regular users, e.g. via "Edit" buttons in Discover, just like it's done for color schemes, rather than sweeping it under the rug...

More documentation for third-party application would be awesome. Currently, in the userbase we have:

• Plasma/Create_a_Look_and_Feel_Package
• Plasma/How to create a Unity-like look and feel theme using Plasma’s Desktop Scripting API

And maybe some more, in the community and techbase wikis.

You probably saw how Blender GUI is build, where in developer mode each buttons, can open a text editor with the widget code and with support for live modification in the python code. This can't be achieved with Qt.

But having a button for opening Kdevelop with the source code of the application loaded is probably doable. And you are not the first with this idea, I already read that some want to make Kdevelop install all the decencies automatically in some discussion about the onboarding goal.

@churaev
In fact, people around here agree with you so much that onboarding became an official KDE goal last time. We continue to make improvements on ease of compilation-and-running, and in fact just made a big improvement for Plasma itself which I'm going to be blogging about tomorrow. See https://community.kde.org/Get_Involved/development

It's not perfect of course, but it's getting better.

This blog post seems relevant: https://www.inkandswitch.com/end-user-programming.html

I don't feel I can agree to this goal at all for how is stated.
Proliferation of options has been an historic KDE problem to the point of looking very unpolished and unprofessional.
since kde3 times we got much better at this, but we must pay attention we don't add complexity in our codebase that impact overall quality and maintainability.
It's ok to be very flexible, and we are already more than any other desktop environment, but we should put more work in the "simple by default" part.
adding super configurability everywhere as a big overarching goal i feel it will hurt us in the long time as all the complexity added will have to be maintained over the years

@mart, it looks like mental blocks are preventing you from understanding the goal... Honestly, I fully expected it to be misunderstood, after all it's probably psychologically difficult to even think about, because all of what I proposed for the goal is so obvious and would be just so good for free software, but will likely prove impossible to implement in practice. More info on that in this comment.

Proliferation of options has been an historic KDE problem to the point of looking very unpolished and unprofessional.

This goal does not propose any new options, instead it proposes making it easy to add user code to KDE software, so people can make their own options!

since kde3 times we got much better at this, but we must pay attention we don't add complexity in our codebase that impact overall quality and maintainability.

I think that all of the necessary changes would be helpful rather than detrimental, the biggest problem is probably the degree of standardization and cooperation needed...

adding super configurability everywhere as a big overarching goal i feel it will hurt us in the long time as all the complexity added will have to be maintained over the years

All free software is already super-configurable by virtue of the access to source code, you can even add new features, the only problem is the number of hoops you have to jump through to actually make use of this configurability...

Probably the best first step to achieving goal would be to spread the following beautiful truth: at this point it should be obvious to everyone desktop free software will never be profitable, and nowadays any free software volunteering has to compete with addictive games and social media. Therefore, anything but one-click initial setup, low download and initial build times, less than 5 second compilation and launch times, and instant access to and source documentation for any class or function (even those from external libraries) should be considered unacceptable.

Please! Use every communication channel available to KDE to spread it.

I'm sure that there are people within the KDE community who can tell this wonderful truth much more eloquently and persuasively than I will ever be able to, and coming from a reputable source like KDE rather than an outsider like myself, this marvelous truth is more likely to break through people's psychological barriers and mental blocks.

In my opinion, there exists a vicious cycle: the degree of standardization and cooperation that would be required to fix the mess that is the world of build systems, documentation generators, version control, C++, packaging, etc. to the degree necessary to enable fully automated setup of complete development environments is astronomical, which causes people to develop mental blocks to avoid thinking about all the progress the free software movement could have made if it were this easy to get into, thus making this problem even more intractable: cooperation is not possible if everybody prefers not to think about the problem...

I agree with @ervin. The goal seems to have good foundation but it is focused on the wrong things in my opinion.

Some suggestions are to change the title to something like: Integrating Plasma with the contribution platforms or Make possible to contribute without Leaving plasma

Also instead of urging people to become developers maybe we should urge users to get involved in the community as a start. Right now we have no UI to suggest bugs or features. And the IRC is not very welcome. Maybe it should be changed to Martix?

Another good idea would be to add a welcome screen with links to the community.

We already have Matrix, but there's a lot of old documentation that needs to be updated to point people towards it.

Do I get it correctly that this is a lot about empowering people to influence their world - specifically adapt software to their needs through simple code changes?

@lydia Yes, exactly! But it also about providing the environment where people can learn everything they need for that naturally, gradually, and smoothly, and where doing it is actually fun for as many people as possible! Imagine for a moment that free software became a proprietary game (nourished by DRM) - it would be either universally panned by critics for its tutorial system, or regarded as a niche hardcore game. Then this goal would be to turn FOSS development into an "easy to learn, hard to master" type of a game.

👍
I wonder how we can capture that in something short and sweet to give this goal a heading. I really like the current one but I am not sure it makes it easily understandable what this goal is about unfortunately.

Let's also speak about the "gameplay" of desktop free software a bit...

What does it take to define a property? Apparently, it takes this (and that's Qt, on GNOME side, it's MUCH, MUCH worse, so much that it's insane):

class ... {
    /**
     * @brief Name of the object.
     * The name of the object identifies the object.
     */
    Q_PROPERTY(QString name READ name WRITE setName)
public:
    /** Gets the name of the object. */
    QString name() const;
    /** Sets the name of the object. */
    void setName(const QString &name);
signals:
    /** Emitted when the name of the object changes. */
    void nameChanged(const QString &name);
};

QString ...::name() const { return m_name; }
void ...::setName(const QString &name)
{
    if (m_name == name)
        return;
    m_name = name;
    emit nameChanged(name);
}

Really? I can neither comprehend nor understand why the free software community is willing to tolerate this... I mean yes, in the grand scheme of things this is nothing compared to the actual logic, but when you compete for time with addictive games and social media, every roadblock, no matter how tiny, starts to matter.

Any more adaptions based on the comments and other discussions? When done please move it to the ready for voting column.

That's all. Moved myself to "willing to work on this", since I've been thinking about a better alternative to KSysGuard for quite some time now (the current one doesn't extract nearly as much as I'd like), that'll probably be more like "truth extractor" than "guard"... Might prove to be too ambitious for me, but if I get a prototype done, I'll post here.

Quick reminder that there are two days left before the voting starts. Please make any changes you still want to make soon.

Quick reminder that "At this point it should be obvious to everyone desktop free software will never be profitable, and thus has to rely on volunteers." is baloney. It's meaningless dribbling without any real relationship to the real world. Can we please can this nonsense? Can "churaev" please look outside their bubble and check out desktop applications like Blender and Krita, please?

Anything but single-click initial setup, reasonable download and initial build times, less than 5 second compilation and launch times, and instant access to source code and documentation of any class or function (even those in external libraries) should be considered unacceptable.

How you want to implement this? 5 second compilation looks like something *physically impossible*, because of different computers have significantly different compilation possibility and different programs have a significantly different code amount.

Fixed both issues, also hope it's OK to add an extra link at this point in time.

If we remove all the undoable and unreasonable points we have here:

• Add plugin support and API documentation to as many KDE applications as possible — Most probably JS. Few apps like Kate does have one but compared to Atom or VS Code this is nothing, also plugin publishing is important
• Show links to source code of applications in Discover.
• Show alphas, betas and nightly builds by default in Discover, allow installing them in parallel with stable versions. — Doable with flatpack (the code is already there), almost undoable with deb/rpm due to dependencies
• Make developer documentation translatable. — Doable but it will become an outdated mess as it were in PHP (they were able to clean it up a bit lately but we have much more documentation and fewer maintainers)
• Easier themes/widgets/scripts creation and publication in the store.
• Generally become more new contributors-friendly

@churaev

Why is this important? As a computer-related hobby, nowadays free software volunteering has to compete with addictive games and social media

More when competing with "addictive games and social media" we're competing with Windows, Mac and proprietary applications with the same functionality as ours.
Most of the contributors use the KDE apps as their working tools and Plasma as their working desktop.

at this point it should be obvious to everyone desktop free software will never be profitable

This one is plain wrong

This goal does not propose any new options, instead it proposes making it easy to add user code to KDE software, so people can make their own options!
Really? I can neither comprehend nor understand why the free software community is willing to tolerate this... I mean yes, in the grand scheme of things this is nothing compared to the actual logic, but when you compete for time with addictive games and social media, every roadblock, no matter how tiny, starts to matter.

You see, we don't want just more contributions, we want high quality contributions.
And making a contribution for a newbie to an actively maintained KDE project is super easy nowadays if he want to put just a little effort to understand how is the build process and how we use the versioning system (git), all of this is well documented.

Vote invite were sent to everyone subscribed to the KDE community mailing list and everyone with a developer account. Any contributor who didn't receive one please subscribe to the mailing list to not miss future announcements and send me a quick email (lydia@kde.org) and I'll send you a vote invite.

[spam comment removed by sysadmin]

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board.