Promo/Release Announcement Guidelines: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
Line 1: Line 1:
== Release Announcement Guidelines ==
== 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.


This is supposed to give 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.
 
==What is a Release Announcement?==
A release announcement informs the press, our users and the outside world about a release. See [http://www.kde.org/announcements/ 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 digg 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 (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.
 
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 ;-)
===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.


The release team maintain a release checklist [http://quickgit.kde.org/?p=sysadmin%2Frelease-tools.git&a=blob&hb=HEAD&f=RELEASE_PROMOTION here].
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.


See the [https://en.opensuse.org/openSUSE:Product_highlights_writing openSUSE Product Highlights writing guide], it was essentially build on how we do stuff.
==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 ===
All screen shots must be taken as follows:
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)
* 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 ;-)
* With default theme, color scheme, window decoration, widgets etcetera. No fancy stuff ;-)
* Try to have application windows big but not maximized
* 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!
* 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!

Revision as of 21:05, 7 January 2014

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.

See the openSUSE Product Highlights writing guide, it was essentially build on how we do stuff.

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 digg 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 (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.

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 ;-)

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.

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 here.

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!