<table><tr><td style="">neofytosk added a comment.
</td></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/T8357#136935" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">T8357#136935</a>, <a href="https://phabricator.kde.org/p/James/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@James</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>I like this approach TBH. We can make an educated guess what the most important features are, but to assume that one of those * Item X * points might not be an exciting thing to someone's workflow would be perhaps a bit short-sighted.</p></div>
</blockquote>

<p>That's a very good point. On one hand, it's sometimes safer to assume that "X doesn't crash when opening files" will have  a larger impact on the majority of X's users than let's say "X gained another shortcut to perform an action". On the other hand, you never know what might be the one thing that really affects peoples' use cases or frustrates them, or how much effort the developer put into fixing it and you simply ignore it. I'm often tempted to leave something out when I see a long list of features and fixes, but it's very hard to do this kind of sorting light-heartedly.</p>

<p>If we had a specific target group (end users, developers, organizations) it would possibly make picking out the 2-3 features/fixes or going for a specific writing style simpler.  But my understanding is that we are going for a more generic audience here.</p>

<p>A hybrid approach could indeed work for us. In such a case, I would leave it up to the developers to point out the couple of features they would like to mention first in the short text. After all, they know their users better than everyone. These can be distinguished in devs' initial notes for the announcement. If they don't care for doing that, the persons writing the announcement can decide on what people might be interested in based on their own experience.</p></div></div><br /><div><strong>TASK DETAIL</strong><div><a href="https://phabricator.kde.org/T8357">https://phabricator.kde.org/T8357</a></div></div><br /><div><strong>To: </strong>neofytosk<br /><strong>Cc: </strong>James, dhaumann, knauss, skadinna, mlaurent, rkflx, mkoller, neofytosk, elvisangelaccio, KDE PIM, ngraham, cfeck, davidc, Anachronox, nauticalnexus, nalmeida, alexeymin, genaxxx, s8321414, tcanabrava, lydia, valorie, sebas, apol, duffus, ltoscano, repinc<br /></div>