Rationale
Some developers were justifiably annoyed that the notes they had made for the Applications 19.08 release had been cut out of the final published version of the announcement.
However, data from past announcements show that a more accessible, mor digestible (=shorter), article-like format gets the release announcement more coverage in external outlets. This is something Promo has to work towards as per our goals.
To achieve the goals of Promo (maximizing coverage for KDE in general) and those of individual projects (getting more coverage for their applications and the work they carry out on them), we are carrying out this task.
Procedure
During the BoF we held during Akademy 2019, we discussed three ways we could make announcements fairer for the work developers do, giving them the recognition they deserve, while still maintaining the more accessible and copy-pasteable format we started to move to in 19.04.
These are the ideas we came up with:
- Seek out and talk to developers who submit to the notes document and discuss their work. Explain one-to-one the criteria we use (see below) so they are aware of what we are looking for.
- Ramp up the level of detail one notch from the Apps 19.08 announcement to cover more of developers' work. The level of detail included in 19.04 seems to have hit the sweet spot.
- Add links to projects' home pages from the changelog (can this be done automatically?) so they benefit from more traffic.
- Retroconning: using small changes to tell/remind users about applications they may not know about.
- Make the criteria Promo applies to choose content explicit so developers can think about and reformulate their notes in a way Promo can use.
Current criteria looks something like this:
We tend to favour "interesting" over the "important". "Important" here referst to "every change, big or small that improves the software, contributing to its stability, usability, improving its usability, and/or adding useful features".
"Interesting", on the other hand, are changes that we can use to explain easily, concisely and often visually how the users benefit without having to give massive background explanations. A change can be both important and interesting, of course, in which case it is sure to be mentioned.
"Interesting" and "important" are not absolutes. They are more of a scale and you can also move a change from not-interesting to interesting by reframing it in such a way so that the effects of the change can be clearly shown to the users.
Here are some examples:
Important (but not very interesting)
- Squashed bug stops slider from turning green on Thursdays
- Changed from X framework to Y framework to make application future proof
- Added the size of the file on the disk info to the status bar
- Moved feature A from X menu to Y menu to improve usability
Interesting
- Application no longer crashes when opening graphics in the CMYK colorspace (very annoying and dealbreaking bug corrected)
- Application supports X file format, which is an industry de facto standard
- Application got collaborative editing
TODO
- Invite in developers (for example, the people from Cantor) for feedback
- Discuss and brainstorm the above: What else can we do?
- Formalise into a policy and put it on the wiki
