Ambitious KDE Goal: Briding the Gap

[Jos van den Oever]

I feel like I should join in as well in pitching ambitious ideas for KDE.

For mortals, it is hard to understand how KDE applications work. It is very 
hard to get into KDE coding. There is a lot of implicit knowledge in the code 
base. I think we should make this better by having testable high level 
descriptions of applications.

There is a lot of testing code in KDE applications and it often follows the 
test driven development approach where a situation is presented (Given), and 
action described (When) and an outcome verified (Then).

These functional descriptions from the tests can go into their own files. This 
would give simple files that any user can read and comment on. The same 
description is used in the text and this way, the desired features are linked 
to the tested features. The .feature files are stored in git and a change in 
software behavious is easily discovered.

These .feature files are easy to read and should stay the same even after 
large refactorings (Qt6!). We can make insightful what part of the features 
has tests and what part of the tests passes.

This method is used in projects where new developers should be able to jump in 
quickly. It makes it easy to add new features in a structured way: you start 
with the .feature file, then write tests and then the implementation.

It works the other way around too. There's lots of code lying around where it 
is not obvious that it is still needed. If it is not covered by tests or 
features, then it can go, or a feature of the code is not documented.

Here is a simple example of a .feature in the Gherkin language.

===
Feature: About box

  Scenario: Show the about box menu
    Given that Dolphin has started
    And it is showing the main window
    Then a user action for showing the about box is present

  Scenario:
    Given that Dolphin has started
    And it is showing the main window
    When the user activates the about action
    Then the About dialog is shown
===

This is user readable and so users can more easily understand how an 
application is supposed to behave. They do not need to understand the code 
that implements these features. People that would like to document KDE 
applications can read the .feature files to write their documentation.

This helps to communicate our prinicples to users. We can describe the 
behaviour of telemetry in a .feature file. It will describe opt-in telemetry: 
"When the application starts with default values Then the option telemetry is 
turned off".

Working with these .feature files is a new thing for desktop software, but one 
that makes the workings of our software more relatable for users. They will 
value this and see our work less as magic and will understand the value of an 
open project. They might even be led down to the path of being a developer 
eventually.

Best regards,
Jos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20170820/8570b453/attachment.sig>