Promo/Release Announcement Guidelines: Difference between revisions

From KDE Community Wiki
No edit summary
m (XYQuadrat moved page Promo/RA guidelines to Promo/Release Announcement Guidelines: RA isn't descriptive nor intuitive)
 
(One intermediate revision by the same user not shown)
Line 2: Line 2:
This gives some information on how a release announcement should be formulated, how screenshots should look and what information needs to be in there.
This gives some information on how a release announcement should be formulated, how screenshots should look and what information needs to be in there.


See the [https://en.opensuse.org/openSUSE:Product_highlights_writing openSUSE Product Highlights writing guide], it was essentially build on how we do stuff.
The [https://en.opensuse.org/openSUSE:Product_highlights_writing openSUSE Product Highlights writing guide] is also a useful resource.


==What is a Release Announcement?==
==What is a Release Announcement?==
Line 11: Line 11:
* 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 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 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!
* The announcement helps our contributors to know what is in our products and what others did


==How Do We Write Announcements==
==How Do We Write Announcements==
Writing an announcement happens in three stages, with different people and skills involved.
Writing an announcement happens in three stages, with different people and skills involved.
===Gathering information===
===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 digg through commit digests and mailing lists.
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!
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===
===Writing Out the Feature List===
While phase one is being worked on (adding info) some 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.
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 - find common themes for example. Link to the original blog posts and don't be TOO wordy ;-)
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===
===The Final Polish===
The last phase is to fill in the final details. 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.
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.
 
We need a summary on top, proper paragraphs, stuff like that. And last of all are the bells and whistles - images and videos to create a rich user experience.
 
==And then we're DONE!==
... but it isn't out yet. Next is putting the text on the dot, preparing mails for the press and our announce mailing list, getting the changes on kde.org done etcetera. The release team maintain a release checklist [http://quickgit.kde.org/?p=sysadmin%2Frelease-tools.git&a=blob&hb=HEAD&f=RELEASE_PROMOTION here].


=== Screenshots ===
=== Screenshots ===
Line 39: Line 34:
* Don't overload the screen with windows: more than 2 really is too much, don't let it get too cluttered!
* 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!
* 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.

Latest revision as of 10:58, 9 June 2020

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.