Promo/Release Announcement Guidelines: Difference between revisions
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. | ||
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 | 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 | 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 | 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=== | ||
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 === | === 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.