This project is used to collect and work on the KDE community's goals in 2017.
Wed, Apr 11
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.
Tue, Apr 10
Fri, Apr 6
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.
@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.
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 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
Thu, Apr 5
In regard to Uncofirmed/confirmed status, there's a relevant discussion here: https://mail.kde.org/pipermail/kde-community/2018q1/004395.html
Tue, Apr 3
Mon, Apr 2
It should be added to the kdepim workboard
Tue, Mar 27
Mon, Mar 26
What do you think about a dedicated stack for web development? As there is C++, Qt/QML for the desktop, like wise a dedicated/preferred programming language(s) and framework can be chosen for the web. This would help in onboarding contributors to the web side of things and potentially make management of the web stack easier for both the developers and the system admins.
Mar 25 2018
@manuelmuzzurru, the best place for that kind of request is in the form of a Bugzilla ticket for frameworks-kio.
hi, did you see my comment for filesystem in dolphin (panel information)?
Mar 21 2018
Mar 15 2018
As a newcomer and junior-jobs guy, I'm happy to see this initiative being pushed forward by the Top People(tm) of the KDE organization. I've been stumbling my way through a few patches with the help of @rkflx and @ngraham, the latter of which agreed to mentor me in the ways of KDE. Henrik has been patient with me as I learn C++ and has given me a few assignments for Spectacle bugfixing. Nate has been a good guide to the environment and community. I'm sure there are many more like these two out there. Busy people, but willing to share their knowledge and expertise.
Mar 13 2018
Mar 9 2018
Feb 19 2018
On thing we could use is an official policy regarding whether the stable or master branch is more appropriate for any given patch. Right now it's often not clear for edge cases such as D10651: Fix thumbnail hover icon show-in-fullscreen action. In that patch, a bug was fixed that led to a behavior change. Stable or master? We committed to master to be safe, but it wasn't as clear as we would have preferred.
Feb 18 2018
hi, i wish to ask you:
Feb 15 2018
Recently, I tried to find out KDE best practices to work with Docbook.
Feb 14 2018
I really like UHD's explanatory text above the login box. We should implement that, with some short documentation and a link pointing to identity.kde.org. Who has the power to do this? KDE Sysadmins?
Feb 13 2018
Well, I reply to myself as I got the following notification just after making the post above :
"This application finds windows using GTK GMenu DBus interfaces  and forwards them through DBusMenu. This way no adjustments in Plasma are needed."
Hi ! I wonder whether this one would fit in the KDE usability list : global menus don't work with GTK apps, cf :
Feb 10 2018
I have updated https://community.kde.org/Get_Involved#Getting_in_touch_and_working_together and https://community.kde.org/Infrastructure/Phabricator#Logging_in, and included a picture highlighting the login button.
Feb 6 2018
Feb 1 2018
Hi everyone, I feel bad for being quiet over the last couple of weeks. Lots of changes happening in Jan-Feb for me, and also FOSDEM and the KDE Promo sprint are coming up. I'll try to push this goal forward in a consistent way once all these have passed.