@nicolasfella that's a really major issue, yes. However, I think we should stick to the "Get Involved" page here in this task, so that we don't broaden its scope/discussion too much. Cleaning up the whole wiki could be a separate task, with subtasks for every main section that people can assign to themselves (because doing the whole thing at once might be too much for one person).

One thing I noticed in the Wiki is a huge amount of broken links. Those should be updated (if possible) or removed. Maybe one could do some kind of webcrawler that scans our whole wiki for broken links.

Thanks @lueck for pointing these applications out; I have now re-added them to my active list.

In T6832#143007, @xyquadrat wrote:

knetattach

Not able to find a repository on cgit.kde.org nor a release in Ubuntu 16.04...

plasma-desktop/knetattach/

konsolekalendar

I can find the package in Ubuntu 16.04 (from a very old version), but not a repository

pim/akonadi-calendar-tools/konsolekalendar/

korgac

Not able to find a repository on cgit.kde.org nor a release in Ubuntu 16.04...

pim/korganizer/korgac/

kwikdisk

Not able to find a repository on cgit.kde.org nor a release in Ubuntu 16.04...

kdeutils/kdf

libalkimia

I can find the package in Ubuntu 16.04 (from a very old version), but not a repository

extragear/office/alkimia/

pimsettingsexporter

I found pim-data-exporter, which might be the same thing (?)

Yes pim/pim-data-exporter/

In T6832#142931, @schweingruber wrote:

Hm, is there a compelling reason to remove obsolete products from the database? If they are marked as obsolete, no new bugs can be filed against it anyway, and those should not show up in a browsable list for the user. Of course if you have admin rights they will show, but how often does an admin have to browse a product list without a filter?

I must admit that I just realized that the list of apps you can report a bug against is not the same as the ones accessible through clicking "Browse"...
But I think we should consider hiding the obsolete products not only when reporting bugs, but also in a) the advanced search & b) in the list from Browse. It'd simplify the search process for triagers a lot. Additionally, there are some products which are obsolete but you can still file bugs against them (e.g kaveau).

In T6832#142824, @xyquadrat wrote:

I decided to do something remotely useful with my free time and sifted through all applications/libraries present on bugs.kde.org, removing most obsolete products. My guidelines to determine whether a product was deprecated were:

1. Is the product not marked as "unmaintained"/"deprecated"/"replaced"?
2. Is the product in the repositories of Ubuntu LTS?
3. Is the product on cgit.kde.org?
4. If it is on cgit.kde.org, does it have any activity in the last year?
   
   After applying this criteria to all 737 (!) products available, only 455 remained (so nearly 300 products are obsolete, and should be removed from bugs.kde.org). It is of course entirely possible that I have either missed a deprecated product or have accidentally deleted an active product... Feedback is always welcome!
   
   All products:
   kdeOldProducts41 KBDownload
   
   
   Only active ones:
   kdeProducts25 KBDownload

Ok, so it seems that you only created a list and you are asking for feedback. Fine then, sorry for the misunderstanding, the wording could be misleading.

Just to be sure, @xyquadrat : did you already remove the products? In the future, don't remove first and ask later, but do the opposite. It's a bit too late to ask whether you had accidentally deleted an active product.

Hm, is there a compelling reason to remove obsolete products from the database? If they are marked as obsolete, no new bugs can be filed against it anyway, and those should not show up in a browsable list for the user. Of course if you have admin rights they will show, but how often does an admin have to browse a product list without a filter?

Following a discussion with @bshah about T8685, we opted for revamping Plasma Mobile phabricator tasks. The status of many tasks has been changed in order to avoid offering to the potential contributor a task already done.

I decided to do something remotely useful with my free time and sifted through all applications/libraries present on bugs.kde.org, removing most obsolete products. My guidelines to determine whether a product was deprecated were:

1. Is the product not marked as "unmaintained"/"deprecated"/"replaced"?
2. Is the product in the repositories of Ubuntu LTS?
3. Is the product on cgit.kde.org?
4. If it is on cgit.kde.org, does it have any activity in the last year?

In T8712#142098, @hein wrote:

It's worth noting we have this in a non-formalized way. The Getting Involved pages have always listed mentors you can contact for 1on1 questions (I've responsed to mails due to this for many years).

I'm not a developer, so perhaps I'm missing important aspects here, but how about using a common template with the things that would interest people, so they can quickly review what's it about before going into the details?

What constitutes a "junior job" does indeed vary immensely. The maintainers or "lead" developers need to flag bugs carefully and appropriately. I've worked on junior jobs that ranged from string and icon changes, to adding a new API call to KWin. These were all referred to as JJ's, but they're definitely on different levels.

I sometimes try IRC but that does not work very well, because a developer needs to be online at the same time you are online

The link to the Mentoring page is literally the last word of the Getting involved page. I did read the getting involved page (maybe with not too much attention), but I did not reach the mentoring page and did not figured out I could contact a developer directly. Maybe this link can be highlight better somehow?

Great stuff.

even if it requires a bit of effort up front to help people get started

I don't think anyone's proposing an easy-but-broken method of brute-forcing the first commit. Rather, I think we're all discussing how to make it easier to get started the right way so that first commit is not only easier, but also conforms to KDE best practices.

In T8685#141924, @aacid wrote:

The translation teams have said various times in the past that translations from random people in the internet with no commitment usually just bring in more work than they help since they totally fail at syntax, style guide, etc. I wouldn't be sure this has changed at all.

I mean would you let people edit code form the internet and submit a patch directly without having them compile and try it whatsoever? Probably not, so why would it be different for translations?

It's worth noting we have this in a non-formalized way. The Getting Involved pages have always listed mentors you can contact for 1on1 questions (I've responsed to mails due to this for many years).

It's great to see so much valuable feedback rolling in to this thread, especially from people that are new to KDE. Many thanks for that!

As a relative newcomer (January), this is a very real and very powerful
thing. We should do whatever we can to encourage it. When my first
commit got landed (a simple plasmoid fix), it was a great feeling. Now
you'll probably never get rid of me.

I totally agree that the jobs need a better description. This task is all about discussing what should be in there

May I suggest that you don't add more jobs to this list just now but instead focus on making the existing ones really junior friendly.

In T7116#141596, @dhaumann wrote:

BTW, Akademy is nearing, registration is open. Could we send a mail to all (!) contributors who have a KDE commit account? I think this does make a lot of sense to trigger everyone (especially new contributors) to come to this event.

The translation teams have said various times in the past that translations from random people in the internet with no commitment usually just bring in more work than they help since they totally fail at syntax, style guide, etc. I wouldn't be sure this has changed at all.

TBH, my suggestion is primarily focused on the facilitation of a really fast and simple first contribution. Like the case when we learn a new programming language, almost always we try to run a "hello world" example, without having any real knowledge of the language or having read (almost) any page of the language reference. After the successful execution of the “hello world” , we feel a little bit more comfortable to continue studying. It's the "hello world" psychological effect accompanied with the feeling of membership and commitment to the KDE family that the solution tries to reproduce .

We should definitely do something during Akademy but I don't think it should and can replace the sprint.

In T8685#141599, @sharvey wrote:

If we want to create a website (even it it's something like myfirstpatch.kde.org), we should put a link on the user's desktop at installation. That's relatively inoffensive, easily removed, and requires less coding than a desktop widget.

If we want to create a website (even it it's something like myfirstpatch.kde.org), we should put a link on the user's desktop at installation. That's relatively inoffensive, easily removed, and requires less coding than a desktop widget.

Would it make sense to have this sprint as part of the BoFs and Workshops week at Akademy? Or maybe we can have a smaller session as a prep-event for the actual sprint.

BTW, Akademy is nearing, registration is open. Could we send a mail to all (!) contributors who have a KDE commit account? I think this does make a lot of sense to trigger everyone (especially new contributors) to come to this event.

Here are my 2 cents.

Another website like that is https://whatcanidoformozilla.org

One of nice example I found earlier : https://howcanihelpubuntutouch.io/

Perhaps it could also pull Junior Jobs from Bugzilla? It’s a good idea, having it readily (and semi-permanently) available. I don’t know if we could get it done in time for Plasma 5.13 (assuming the idea is approved).

We can choose any topic from the sub-tasks listed on the overarching Onboarding Goal task. I will be adding some more sub-tasks there in the following days (like improving documentation, gathering feedback etc). Feel free to leave a comment there if you came up with anything that needs to be tackled and is not mentioned already.

Definitely possible. Having never planned or attended a sprint before, I'm completely unqualified to organize one. I was just proposing things that seemed like they needed urgent fixing.

In T8621#140403, @ngraham wrote:

Maybe we need two sprints? One for Usability and one for Productivity? The thing is, they're inter-related. All the KCM porting work you guys did at the plasma sprint was more codey than designey, but definitely improved usability.

The Usability & Productivity initiative isn't just about design and user interfaces; that's only the "Usability" part. "Productivity" definitely includes efficiently accessing, saving, and streaming files from remote locations--particularly Samba shares, which are ubiquitous in the business and professional worlds. This is a major pain point that I hear about over and over and over again from our users, and experience myself.

I'm a bit confused as to the intention of this sprint. The people commenting on T6831 this is a sprint for are all designers and usability people. This list of goals is effectively an extreme very low-level KIO bug sprint.

It's usually pretty hard unfortunately :/

Any chance these could be streamed or recorded for those who can’t attend? Or is a sprint too chaotic to capture effectively?

Under the subheading of "Documentation", can we discuss code commenting? And ideally - encourage it? The API docs are good and generally well-maintained, but inside the applications themselves, the quantity and quality of code comments varies quite a bit. Some of our products are quite large and use many of the Frameworks together. It can be daunting at times to decipher how a block of code works and why it was constructed in the way it was.

In T6832#136906, @neofytosk wrote:

And more about bugzilla's usefulness here:
https://mail.kde.org/pipermail/kde-community/2018q1/004274.html

Maybe it's worth to add to the describtion of this task:

Vault uses FUSE, no block-level for the time being. I was toying with Tomb and preallocated fixed-size containers in the filsystem which uses Luks in the back, but I'm not sure it can be made to work properly.

In T8447#136980, @dvratil wrote:

@gregormi This is only partially related. We already have an option how to automatically decrypt all incoming emails in KMail, although it's not very intuitive to set up. You can create a local filter (Settings -> Configure filters) for all incoming emails and choose the "Decrypt" action. The reason it's not done by default is due to privacy concerns. For example you may want to keep your personal emails always encrypted on your employer's computer so they can't read your private emails.

@ivan: tanx for the input

Vault does not support public-private key encryption - it is out of the project's scope. And it would be quite strange for the user to see items like "KMail Index for ABCDEFGH01234... key" in the list of existing vaults. :)

@gregormi also think about the privacy impact. If you use an unsecured laptop, the mails can be accessed without any password etc. Also when you use IMAP the unencrypted mails would saved back to your mailserver and would be accessible there. It might be usescases for that. But I think the propper way is to make sure, that we can handle the encrypted mails all the way down without removing the encryption.

@gregormi This is only partially related. We already have an option how to automatically decrypt all incoming emails in KMail, although it's not very intuitive to set up. You can create a local filter (Settings -> Configure filters) for all incoming emails and choose the "Decrypt" action. The reason it's not done by default is due to privacy concerns. For example you may want to keep your personal emails always encrypted on your employer's computer so they can't read your private emails.

I have a question to that because I encountered this issue years ago when I used Thunderbird with Enigmail. I assume the indexing we are talking about here takes place in the local mail client, not in a web client, right? I wonder why incoming encrypted mails are also stored encrypted? Why not always decrypt those mails permanently? This would prevent losing old mail because of lost private key and there would be no problem with indexing. In this Enigmail bug report (https://sourceforge.net/p/enigmail/bugs/1/) from 2003 this request was made. The main reason for not implementing it is a technical one ("this feature is blocked by necessary Thunderbird changes") not fundamental ones. I thought the goal of end-to-end encryption is protect the data when it is underway and not also on the end-points themselves. Are there any reasons why KDE PIM does not decrypt incoming encrypted mail permanently? (or is there already and option to do that? Then sorry for the fuzz)

Related to T7014

In regard to UNCOFIRMED/CONFIRMED status, there's a relevant discussion here:
https://mail.kde.org/pipermail/kde-community/2018q1/004395.html
And more about bugzilla's usefulness here:
https://mail.kde.org/pipermail/kde-community/2018q1/004274.html

It should be added to the kdepim workboard