I took a second at the site (which looks great already, props to you!) and wanted to share a few things that I'd change:

Thank you @rkflx for your work. The situation is indeed a bit confusing, I think that most old kio bugs either belong to frameworks-kio (if they are related to Dolphin/Gwenview parts) or kio-extras (for the rest), but there are some exceptions...

Two links that might be useful when writing the unit test:
https://community.kde.org/Guidelines_and_HOWTOs/UnitTests
https://wiki.qt.io/Writing_Unit_Tests
Also, there are already a few unit tests in this repo that you could take a look at.

I started writing release notes based on the structure of the 18.04 announcement: https://notes.kde.org/p/_applications_18.08.0_announcement
They are most likely far from publication-ready (I've never written release notes before), but hopefully can serve as a start for the announcement text (which, according to the proposed schedule, should be done by tomorrow).

Okay, I'm really sorry for my late announcement: We are going to do a bug triaging day tomorrow, Sunday the 5th. @ngraham and @nicolasfella have already mentioned that they'll participate, but if anybody else would like to join in, please do so! I'll be online on the #kde-bugs channel for most of my day (so from ~9:00 UTC till 19:00 UTC).

Three suggestions on where you could put it, but I am generally not good in design so others should probably figure out the details.

Sorry that I've gone quiet for a while, this task somehow disappeared from my mind... According to the commits to the Falkon site, @drosca is in charge of the web part of Falkon, so we should ask him to get involved into this effort.

Okay, I further investigated the suggestion from @ngraham and tried to come up with a list of subproducts for kio which can be triaged by pretty much everybody with a computer. Here are the subproducts that I think are a good fit for a bug triaging day:

Does work, thanks!

In T9250#152472, @ngraham wrote:

Gwenview's bugs are already fairly well triaged these days. I would recommend going through the old kio bugs. I think this will yield more fruit since there's lot of crusty stuff in there that's already been fixed over the years or is no longer relevant, and the work will have a real benefit since it will bring us closer to being able to have 0 bugs in kio with everything in the new frameworks-kio and kio-extras components instead. At that point, we can go through those bugs. KIO is super important since it underpins the operation of many KDE apps and features.

In T9250#152469, @rkflx wrote:

Thanks for the initiative, Julian.

To assess how bug triaging could impact Gwenview's bugs, I just clicked randomly on 20 Gwenview bugs:

1. 9 bugs were valid bugs or wishes. In need of patches, and more often than not further refinement of the idea to make them a good fit for Gwenview required.
2. 7 bugs needed further investigation how Gwenview is working today in that situation or the reporter has a weird local setup. Good fit for triaging.
3. 4 bugs contained a request which might seem valid (often wanting to add stuff), but does not fit the current vision of Gwenview (of not adding everything, since it is different from DigiKam). Would need someone to say no, but not someone to post "awesome idea" resulting in disappointment when a patch gets turned down later.
   
   This query results in 397 bugs found. It's probably counterproductive to flood Gwenview's small team with requests relating to advice for bugs fitting case #3 (it often takes quite some thinking to figure out if those wishes are something we want or not). Would it make sense to compile a list of bugs belonging to case #2, which are a better fit for triaging?

Proposal for a first bug day:

Looks pretty good already! Here are some things that I'd change:

How should we go forward about this? Which projects should be contacted next, and who is going to contact whom?

Looks good to me, but I think you forgot to specify any reviewers. There isn't an official KTorrent project here on Phabricator, but you could probably add some developers who have contributed to KTorrent in the past few months (@dvratil maybe?).

Maybe include KDE Promo for now? There may be a more appropriate, group, though. What team set up userbase originally?

In T9122#150008, @paulb wrote:

In T9122#149882, @xyquadrat wrote:

I updated the https://userbase.kde.org/What_is_KDE a bit, it should now be more friendly towards non-Linux users and I've replaced a few old images. Who will contact which project to see how we can get this effort up and running?

Nice. We should probably include updating userbase in general in the web re-design discussion and make it a proper task in its own right. I have the feeling that there is room for a lot of corrections and improvements, right?

I've updated the https://userbase.kde.org/What_is_KDE page a bit, it should now be less hostile towards Windows/Mac OS users but please improve the page further if you do find any issues.

I updated the https://userbase.kde.org/What_is_KDE a bit, it should now be more friendly towards non-Linux users and I've replaced a few old images. Who will contact which project to see how we can get this effort up and running?

Looks great! As discussed in T9122, it'd be good if we could place the KDE icon & something like "A KDE project" in this welcome screen. I'd either propose the area below "Drag Image in window to open" or above the "Start" title. But if you do have another idea (or don't want to add this), that is also totally fine.

In T5782#149762, @scottpetrovic wrote:

Maybe I am just adding more questions but.

1. Is software development rising or falling in general? Where are developers going if they aren't going to KDE? Things like github are nice, but they don't offer nearly the amount of resources that something like KDE does. I am not European, but open source is a very big thing right now in the USA and it dominates a lot of industries such as the internet.

Krita is also currently updating their welcome screen over in D13861, we could suggest that they add a small monochrome KDE logo in a corner or something similar.

I just fixed a few grammatical issue (bear in mind that I am not a native speaker so it could easily still contain some errors), but apart from that I think this sounds very reasonable. KDE is much more than just the Plasma desktop or Krita and we should not be afraid to present us as one of the biggest open source software projects in existence.

In T8871#148006, @ngraham wrote:

Maybe we could combine the content from the kscreenlocker and SDDM KCMs into a new "Lock & Login screen" KCM? Then the KWallet KCM could be a top-level KCM under Personalization or be combined with something else.

In T8871#146953, @ngraham wrote:

One thing I'd really like to do away with is the current inconsistent two-level organizational hierarchy, where some items at the top level take you straight to a KCM, while others take you to another level of navigation where several KCMs are displayed in a little list.

I think you forgot to specify reviewers, so I added them for you.

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

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).

You forgot to specify any reviewers, so I added them for you. +1 from my side, removing code while improving the user experience is always a good thing :)

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?

Yeah, pretty much ;) Nah, real life has been busy and I think that it'll take at least another two weeks until I can pick this up again. Frankly, I don't even really know what to implement now... Assuming that we do not want to WONTFIX the bug, we need to shrink the preview size down. @sharvey suggested that we set this to about 85% of the panel size, but this would not resolve the enormous icons if the panel is very wide. Should we introduce a cap (such as two times Size::Enormous)?

Well, do we still need this code now? Are there any users which have not completed the transition yet? If yes, then we should try to find a way to still avoid these duplicates while preventing this crash.

In T8554#139259, @paulb wrote:

In T8554#139039, @xyquadrat wrote:

• Have you heard of KDE or specific KDE applications before?

Do you think asking about something specific, depending on context, may work better?:

In D12321#249981, @ngraham wrote:

Fabulous. I agree with @rkflx that before committing this, we should also prepare a similar patch for Dolphin to unify the behaviors.

+1 for asking institutions (especially in education). KDE has some great educational apps (GCompris, KStars, KGeography...) and there are even special distributions designed for schools (e.g. the "lernstick", a german project that is pretty much Debian with tons of edu-apps added in).

@ngraham Quick reminder: You can now mark this task as resolved as the 18.04 release happened today. Wohoo! ;)

We can take some screenshots from your blog posts, but the question is how many screenshots are necessary/useful. I think that having three might be a good number, one for the "Empty Trash" button, one for the dockable Terminal plus either sorting by "Date Photographed" or the git integration. Thoughts?

Even though I wasn't able to reproduce the bug itself (probably because of some leftover old files), this patch is really needed as it'd be very bad if suddenly all places entries were displayed untranslated in 18.04. The patch itself seems reasonable (not a lot of changes -> not a lot to complain about), so +1 from me.

In T6832#136906, @neofytosk wrote:

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

Okay, so the functionality we are discussing is already implemented with D10246, but this patch suffers from the same problem. The patch does not apply cleanly for me, so I wasn't able to fiddle around with it. But theoretically, if we could resolve the remaining problem (Ctrl + F also closes the search box), we could simply use D10246 and the wish from bug 353227 would be fulfilled.

Additionally, opening up a new tab could also cause more problems...
We would need to come up with a reliable way of detecting whether the search box is opened in a specific panel or not & update the state of the button respectively. I think we should still strive to implement this (even if this would be more complicated), as the feature itself is rather useful for the UX & we could also consider removing the [X] that currently looks a bit off.

Apparently I misunderstood the goal of the task... Anyways, I guess I'll just wait until you made a decision (if the final result would be to change it, I'd do this if someone wants me to).

Hmm, I cannot really see the "other way" you are proposing... Do you want to simply change the F11 key, or not change anything at all (as we do not have a Full Screen feature right now)?

I agree that the large icon might look too big for wide panels, but I guess the only really good way to optimize for such a corner case would be to increase the font size as well (which is another task, and might look bad).

Thinking about this for a bit, I tried to come up with a function keys setup which should be more consistent/make more sense (changed ones are marked in italics):

In D11022#238047, @elvisangelaccio wrote:

Still, as I mentioned in bugzilla, the only inconsistency that I'd fix is that the information panel does not check whether the preview setting is enabled.

Clean up references to imageSize

Merge the ratingRole with widthRole/heightRole

I am apparently not able to control arcanist... reverting changes which should have been in a different patch.

• Merge branch 'master' of https://anongit.kde.org/dolphin
• Merge branch 'master' of https://anongit.kde.org/dolphin

Well, then we can simply keep the whole animation (as the animation only triggers if the size of the pixmap changes), adjusting it to only work if the panel is resized would probably require more code than the current solution.

In D11022#234894, @elvisangelaccio wrote:

If we make all icons of the same size (which I'm not sure I'd like), that code would become useless and should then be removed.

Also adapt the size of all "Places" icons

The hardcoded value is now removed.

Remove hardcoded value

Should be fixed on a higher level (translations) -> abandoning patch.

This appears to be more complicated than I thought, thanks for the hint @fabiank . I think the best solution would be to notify the translators somehow, so that they can update the respective strings.
But I am not familiar with the translation process of KDE, so I don't know how to contact them... I guess I'll abandon this patch soon because it tries to fix a problem which should be resolved on a higher level.

US English, I guess the German translator already capitalized "Ordner" as this is the correct way in German.

In D11022#218891, @broulik wrote:

I must say I don't really like the larger icon. How does that change the appearance of all the other file icons in the panel?

Abandoning because the behavior before the patch was the actually intended one.

The way I am currently attempting to fix this bug is very inconsistent... I realized that it does not play well with the startup split view option.

In D10059#195173, @elvisangelaccio wrote:

Please use FEATURE: rather than BUG: in the commit message.

In D10059#195152, @ngraham wrote:

Looks great. Any chance you can attach a screenshot to the Summary section, too?

Change name from "Original Date" to "Date Photographed"

Forgot to commit changes before generating the diff...

Removed emptySearch variable, moved "Empty Search" to inline function.

Window title is now "Empty search" when the user hasn't input any search term.

Removed the facetType() and currentFacet() function as proposed by @elvisangelaccio. Merged the search and text variable into searchText, which now uses %1 to add in the current search text for better localization. But I am not entirely sure if the consent is that we remove the facets from the title (which gives more space) or if I should keep it (which gives more information to the user) but adapt to the other comments.

@elvisangelaccio The basic patch is the same, but the "Places" feature has been added & some code style changes were made.

Hmm, I tested it multiple times (also with a completely fresh copy & applying the patch) and it always worked for me.

I am not very experienced with git and arc , but I think that everything should work now. Sorry for all the trouble with this patch.

Weird, when I do

arc patch D8273

on the lastest master, the patch applies perfectly fine for me.

This revision adds the feature proposed by @ngraham. The search text will now change to "Search for [type] named [input]" or "Search for [type]" if the user did not input a search term.

• Changed "Searching [user input]" to "Search for [user input]"
• Instead of using isSearchModeEnabled() I now use viewPropertyContext(), although I am not 100% sure if that will work with all corner cases (@emmanuelp probably knows that better)

In D8273#161201, @ngraham wrote:

@xyquadrat, have you had a chance to look into any of the comments folks have posted?