Promo/Release Announcement Guidelines

From KDE Community Wiki
Revision as of 10:58, 9 June 2020 by XYQuadrat (talk | contribs) (XYQuadrat moved page Promo/RA guidelines to Promo/Release Announcement Guidelines: RA isn't descriptive nor intuitive)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Release Announcement Guidelines

This gives some information on how a release announcement should be formulated, how screenshots should look and what information needs to be in there.

The openSUSE Product Highlights writing guide is also a useful resource.

What is a Release Announcement?

A release announcement informs the press, our users and the outside world about a release. See kde.org/announcements for some examples.

Target Readers

  • The announcement helps the press to write about our new product
  • The announcement helps interested current and potential users find out what's new or if it has what they are looking for
  • The announcement helps the outside world see what we are up to
  • The announcement helps our contributors to know what is in our products and what others did

How Do We Write Announcements

Writing an announcement happens in three stages, with different people and skills involved.

Gathering information

We gather data as soon as we can. We ask developers and others regularly to note major/noteworthy features on a etherpad on notes.kde.org. We also gather link to blogs etc. and sometimes dig through commit digests and mailing lists.

This step is crucial: we can easily miss things so we need help from the developers and others in our community!

Writing Out the Feature List

While phase one is being worked on writers can start turning the rough notes into proper text. That means making a short intro to each main section, further dividing it up and turning the bullet points and pasted text into real, consistent text suitable for publication.

See older announcements for guidelines on how to write. In general, gather related things as much as you can. Link to the original blog posts and don't be too wordy.

The Final Polish

Once the text is considered complete, it needs to be reviewed for good English, and most importantly, the 'techy folks' need to review the document, and ensure that facts are correct, nothing has been omitted and everything is up to date.

Screenshots

All screen shots must be taken as follows:

  • 1280*720 or 1366*768 resolution (small and wide screen to fit articles! A high resolution screen shot looses all details when scaled down as part of a publication)
  • With default theme, color scheme, window decoration, widgets etcetera. No fancy stuff ;-)
  • Try to have application windows big but not maximized
  • Don't overload the screen with windows: more than 2 really is too much, don't let it get too cluttered!
  • Screencasts can go on youtube but having a download is often appreciated!

Technical Workflow

The announcement should be written and edited in the work/announcement branch of the kde.org repository. When finalized, this branch should be merged into master.