I'm a mathematician working in academia, hence a heavy latex user. I've used linux for way over 10 years, with the desktop environment provided by KDE most of the time. I've used and recommended Kile, kbibtex, etc. Unfortunately I should say that, despite being an excellent piece of software, Kile has nowadays been overtaken by TeXstudio, and tools like kbibtex have been left behind in favor of more complete ones like Zotero or Mendeley. I'd love to be able to make something to revert this, hence I've written my name in the list.

The ambitious goal here is to improve the onboarding process for all types of contributors. If we succeed, everyone interested in contributing to KDE should have a clear and supportive path to follow. Of course coders are at the heart of KDE and what it does and lots of this work will inevitably go into that. The way I see it, "making it easy to build something and patch it" should be the case/aim for all types of contributions. =)

Ah my apologies, I thought the goal here was to capture the whole spectrum of contributors. Of course if the goal was to focus on non-coding contributors then this is fine.

In T7116#116225, @ervin wrote:

I'll sound like a broken record but: if we don't solve the "how difficult it is to build something and patch it" *first* all the nice things mentioned here with mentoring etc. (which require people we don't have BTW) won't get us far. People will try, fail immediately because it's too hard and leave again.
Seen that enough with my students the past few years.

I'll sound like a broken record but: if we don't solve the "how difficult it is to build something and patch it" *first* all the nice things mentioned here with mentoring etc. (which require people we don't have BTW) won't get us far. People will try, fail immediately because it's too hard and leave again.
Seen that enough with my students the past few years.

Hope it's OK if I slide in with some last-minute suggestions.

For me as an occasional code contributor, I notice that I find it especially tedious to get a proven local runtime environment ready for local testing of non-trivial programs. For example, this tutorial https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Set_up_the_runtime_environment describes which environment variables should be set for this purpose. Quite a few and I am not sure if all entries are still valid. I guess every developer ends up with his/her own script or scripts to handle this issue (including having some convenience message on the bash prompt showing if the correct variables are set). Maybe this could be extracted to a maintained and standardized script that can be used anywhere where Qt/KF5 based-programs are developed. The script and a guide how one would use it in combination with Kdevelop (or automatic integration with the Launch > Environments) could facilitate getting started.

Thanks, I've informed sysadmin. Apparently the server lost various slides ...

@hein the link to the slides is broken: https://conf.kde.org/system/attachments/99/original/Input_Methods_in_Plasma_5.pdf returns to:

Some ideas from a n00b contributor:

Lots of great suggestions here, I will try to add the ideas from the comments and the video asap. Of course, feel free to edit the initial post directly and include them yourself. =)

In T6875#114456, @chfanzil wrote:

@neofytosk, These are good ideas to overcome these problems. Do you think we should now try and approach people that already upload videos/tutorials in order to see if they're interested in this project? Or should we wait for the final vote?

On one hand, having people with these skills interested in contributing could potentially increase the chances of this proposal being voted. But I would be careful in explaining that the voting is still pending.

KDE looses contributors because of large gap between joining the community and making any actual contribution. To overcome this situation we can do two things

"... I don't want to switch to Windows 10."

@gregormi, Exactly! We must respond to this feeling and not ignore it. This is why we should prepare for this event which is going to happen in the upcoming years, and offer them a way to make a clean and easy transition - by training them. In that respect, the timeline for the BHAG is corresponding to this event.
People say that when Windows Vista or Windows 8 emerged, GNU/linux desktop wasn't ready for the masses.
Let us aim for something completely different: Help as many Windows 7 Power Users to switch to Plasma/linux.

+1 for Patreon/Liberapay page.

Please do merge. The comments will still be available in the ticket that is marked as a duplicate. And it will be linked from here automatically when you merge it in.

I've added 'Windows 7 Power Users' as a target groups.
...
Here is a short quote from the conclusion of the post

I've added 'Windows 7 Power Users' as a target groups.
Why? Recently I've read a post titled "The Purpose of Linux: A Windows Power User’s Perspective" (https://raywoodcockslatest.wordpress.com/2016/06/21/windows-power-user-linux/), that raised some interesting points. Mainly - that Windows 7 Power Users look for an alternative - They don't want to switch to Windows 10 (though eventually their OS wouldn't be supported anymore), because it will limit them and make them simple users.
We should also target this market share as Plasma and KDE apps can suit them greatly (Simple by default, Powerful when needed)
Here is a short quote from the conclusion of the post:

The missing piece, in those mission statements and purposes, was an articulation of a realistic target market. This post has suggested that Windows power users comprise an appropriate and significant target market for Linux. For such users, the objective would not be to make child’s play of computing, much less to draw the masses away from Microsoft. It would be, rather, to create a computing environment in which basic commands and appealing graphics, along with clear hardware and software guidance, would enable an intelligent but busy knowledge worker to get things done with minimal disruption, learning helpful and manageable bits of Linux as needed along the way.

@colomar Thank you for the link! This is sounds like a plan! Communicating this information - when ready - should be done using the methods mentioned in #114484

In T7116#114498, @ervin wrote:

Yes, it'd be nice to see them finally merging, we're late in the discussion phase now. Also as a bonus, it would be awesome if the consolidated proposal could contain aspects coming from the talk we held with David Faure this year about the developer story. That'd make for a very strong one then, and would probably add at least David's name in the list of people willing to put work into it. ;-)

Yes, it'd be nice to see them finally merging, we're late in the discussion phase now. Also as a bonus, it would be awesome if the consolidated proposal could contain aspects coming from the talk we held with David Faure this year about the developer story. That'd make for a very strong one then, and would probably add at least David's name in the list of people willing to put work into it. ;-)

@neofytosk Sure, I'm fine with that.

Yup, totally agree with merging as these two obviously overlap. Am just not sure if and how merging can be done through phabricator without all the current comments being lost.

I can close my similar proposal (https://phabricator.kde.org/T6832) if folks are okay with me editing the description of this one to include the elements that I mention in mine.

@colomar I strongly support the merge. I just added https://phabricator.kde.org/T7116#114484 that would also apply to this ticket. So what shall I do? Link it? Repost it here aswell? Or wait for the merge? ;)

In addtion to @neofytosk , I would like to propose some ideas that may be achieveable in the near future:

@neofytosk, These are good ideas to overcome these problems. Do you think we should now try and approach people that already upload videos/tutorials in order to see if they're interested in this project? Or should we wait for the final vote?

So, what do we do with this proposal and https://phabricator.kde.org/T7116 now? They are so similar that it really makes little sense from my perspective to keep them separated.
Can @ngraham and @neofytosk maybe see how to proceed with merging them into one which contains all aspects of both?
Otherwise votes would end up split between the two, effectively reducing the chance for either of them to be selected.

In T6875#112772, @chfanzil wrote:

I would like to add a link to a sort-of course/introduction to Plasma made by BigDaddyLinux's on Youtube. Maybe we can learn something from that. His videos helped me when I first started working with Plasma. He has made a lot of video dedicated to different parts of Plasma desktop - Dolphin, System settings, Window management, Keyboard shortcuts, etc.
Here is a link to the videos: https://www.youtube.com/playlist?list=PLbKR0OXmf-fg-olEJLukx6ytKN2CkVDjZ
I think we should either try to improve on that work or add more software as you suggested (Krita, Digikam, Okular, kdenlive, coding with Qt/frameworks, etc.)
And of course concentrate all of this knowledge in one place and make it KDE official. We can put it in Youtube also, but it should be under the same 'user'. So that people will be able to find it all in one place.

These are indeed educational videos, thanks for sharing. And yes, that is the idea, have all these under the KDE umbrella. We could even reach out to people that already put work into this, and ask if they are willing to help in this effort.

What worries me a bit, is that the software sometimes changes so rapidly that the current version might look different from that which is shown on our videos. For that matter, the real-world courses are always up-to-date, But they too have drawback as they are constrained by time and space (which the online courses don't). Anyway our most important goal is increasing the number of power-users no matter how.

Yes, for videos it is kind of an issue redoing the whole thing once something changes. Annotations could be inserted though to inform people of minor changes. And perhaps the videos could be reviewed periodically to check they are still relevant.

Here are some further thoughts I've made on this:

@navarromorales Mentoring is indeed a very important aspect of improving the contribution process and it can help solving issues like the ones you describe.

@laysrodrigues Yes, that is exactly what this proposal is about :)

Well, if I'm not wrong we can develop an infrastructure with software that allows people to build their smart home systems. People go to Google and Amazon because it's easy and it's already working. But we can develop one more solution that cares about privacy and leaves the user to extend the project without the limitations that Google and Amazon have.
Amazon, for example, allows you to build your own echo device, you can check on this video: https://youtu.be/vreyairMTwY?t=1m40s
There's also this open source platform, Home Assistant, wrote in Python, and is quite modular on the case of automating stuff for home.
What I mean is, we still have time to join the "market", and I think that we already have the boilerplate to do it.
We have on one side the IoT market, that is basically accessible and open source, and the other the software side, that lacks on good and open source solutions(at least in my point of view)

I am definitely all for getting design more involved, but I feel that this proposal needs to be more detailed and concrete before I'm ready to sign it.

I also agree with @colomar
In any case, just to keep in mind the current official status of document format handlers in okular:
https://okular.kde.org/formats.php

Agreed, I didn't mean to start a whole new branch of the conversation. Just mention that it might be beneficial to also to focus on basic productivity software as a part of this goal.

I'm happy that there is a lot of discussion happening here, but maybe the discussion about annotations in Okular is getting a bit too much into detail for this point in the process.
So let's maybe summarize it for now as "There are potentially some issues with compatibility of Okular annotations, so if this goal gets selected, this could be one of the things we look into, together with academic / research users.

Usually I fill in very simple PDF's forms and annotate pdf with okular. I also exchange them with colleges and secretaries at the institute where I work. They work mostly with Win and to a lesser extend with mac. So far I have had very few problems in terms of rendering the information or the annotations, really very few. However, it might be due to the kind of very simple forms and annotations I'm processing in Okular.

In T6895#113154, @ngraham wrote:

Actually Xournal also has PDF annotation features. But there's a broader point: as a former Mac user, let me bring up the unfortunate truth that Okular can't hold a candle to Apple's Preview, *especially* in the annotations department. That's the standard Okular needs to aspire to. Right now Okular's annotations have a major problem: they aren't consistently compatible with viewers that aren't Okular. Annotations are often not visible when printing or viewing with another problem. This is of course tracked by many bugs:

In T6895#113154, @ngraham wrote:

Right now Okular's annotations have a major problem: they aren't consistently compatible with viewers that aren't Okular.

In T6895#113166, @ngraham wrote:

I don't know the technical details. All I know is that I can't remember the last time in the past 16 years of being a (prior) full-time macOS user when a PDF I annotated didn't print properly or display properly in Acrobat Reader, Foxit Reader, or anything else I happened to use to open it.

does apple's preview implement an open standard when it comes to annotations? if there is one in the PDF specs (i'm not an expert on this) it should be implemented. if apple uses its own proprietary standard, it would be a waste of time, because apple often changes those and leaves you stranded (like the multiple times they broke OpenPGP support in mail, and still do from time to time).

In T6895#113154, @ngraham wrote:

Right now Okular's annotations have a major problem: they aren't consistently compatible with viewers that aren't Okular. Annotations are often not visible when printing or viewing with another problem.

Beside the scientific-oriented software, we could list some general software with great application in science. I am talking about Okular because the feature of write/read annotations in the PDF is unique in free software world;