release announcements, talking points, release notes, and how we group features into audiences or stories
Hi,
(Sorry for evil double-posting :D)
I was taking a look at the oft-neglected Talking Points, which were originally designed as a handy list of "new shiny" for each release that could be handed off to Ambassadors as a quick reference list of features to talk about, and have also at times served as a starting point for choosing features to be highlighted in release videos, interview stories / articles, blog posts, etc. It's entirely possible that they have also been a reference point for writing release announcements as well. Talking points tend to be very focused on *totally new* things, and not generally on incremental improvements.
And so I figured I'd take a crack at it again - see https://fedoraproject.org/wiki/Fedora_19_talking_points - though the mail to mktg list is still yet-to-be-written (the content of this mail sort of got in the way, ha). (For those unfamiliar, it's sort of an iterative process, wherein a number of features are proposed, and marketing whittles them down into a list, which is likely shorter than perhaps the feature-related content in a release announcement might be.)
A few things stood out as I was going through the list:
1: We have bucketized items into a handful of groups over time, in the talking points as well as release announcements, as well as for docs beats and eventually, release notes - User, Developer, Sysadmin (and Cloud/Virt have popped up here and there in more recent releases for announcements). Those lines seem to be increasingly blurry - there are tools/apps that cross the dev and sysadmin roles, user and sysadmin roles, etc. - and while these groups are probably good for beats/release notes, esp. since content can just be duplicated / retailored if absolutely necessary, I'm wondering the following:
Is bucketizing a bunch of stuff into "User, Sysadmin, Developer" the best answer for marketing highlights of the release? It seems like... well, a listing of car parts, but not really telling a story about the car, for lack of a better metaphor. And it seems a lot like "we made a bunch of improvements here and there" isn't as compelling as "we have improved overall state of ($experience, $usecase, etc) and here's how."
Looking at the list of features it seems like there are a few main themes, for which I've suggested some marketing-i-fied names/groupings, though (as you can see in the Talking Points link) it's certainly open to other suggestions (or the option of leaving as-is):
Develop and Distribute: Languages, compilers, and tools for developing software, and tools for packaging software. (Could also be: Create, develop, and distribute?) Start and Recover: Enabling a variety of options for improving boot times, as well as quicker recovery from system or software failure. (Boot and Recover? Launch and Recover?) Monitor and Manage: Systems and resource management, and tools for diagnosis, monitoring, and logging.
2. Note that I'm not advocating for the "user, sysadmin, dev" categories to change in docs-land; I think that these stories/themes are likely to change with each release. But, given the intertwinement of docs and marketing when it comes to the release announcement, it seems like (if docs is crafting the tech-bits of the release announcement) if we were to bucketize by stories, that we'd need to get marketing to figure out what those stories are. And I don't just mean the overarching stories, but also the individual feature stories, in some cases; I can't tell you how many times I look at a feature and say, wow, I wish I spoke that language, I wonder what the bigger picture is, what this effectively enables? Maybe the talking points is a launch point for that as well, in additoin to being the list that gets handed off to ambassadors, and then can drive the story collections in a release announcement, or in one-page release notes; I'm not sure. Thoughts? The workflow, as often seems to be the case between docs & mktg, is key.
Basically: Seeking feedback? Thoughts, anyone? :D
-Robyn
Robyn Bergeron wrote:
Is bucketizing a bunch of stuff into "User, Sysadmin, Developer" the best answer for marketing highlights of the release? It seems like... well, a listing of car parts, but not really telling a story about the car, for lack of a better metaphor. And it seems a lot like "we made a bunch of improvements here and there" isn't as compelling as "we have improved overall state of ($experience, $usecase, etc) and here's how."
We have the big problem of Fedora generally perceived as 'not intended for "normal" users', imagine this, a "normal" user parsing fast the announcement, his reaction "Develop and Distribute, Start and Recover, Monitor and Manage - which of those is for *me*?"
On Mon, Mar 25, 2013 at 6:42 AM, Nicu Buculei nicu_fedora@nicubunu.ro wrote:
Robyn Bergeron wrote:
Is bucketizing a bunch of stuff into "User, Sysadmin, Developer" the best answer for marketing highlights of the release? It seems like... well, a listing of car parts, but not really telling a story about the car, for lack of a better metaphor. And it seems a lot like "we made a bunch of improvements here and there" isn't as compelling as "we have improved overall state of ($experience, $usecase, etc) and here's how."
We have the big problem of Fedora generally perceived as 'not intended for "normal" users', imagine this, a "normal" user parsing fast the announcement, his reaction "Develop and Distribute, Start and Recover, Monitor and Manage - which of those is for *me*?"
Take a look at the feature list. I think I can classify the following things as being for "normal" users:
* Improved mobile broadband support (incremental changes, but nice, I suppose)
Well, that's it. Anaconda improvements are incremental and not an overhaul, mostly focused on enabling advanced/more complex options. We have a handful of desktops with nothing earth-shaking enough in terms of changes to highlight individually, other than in a section dedicated to Spins/Desktops, where we've commonly detailed those items.
There's obviously options around *explaining* in the course of the announcement/talking points / etc that "fedora can be for everyone" - but I think it's fairly difficult to say, "Hey! look at all the new shiny things we have for $generaluser" when ... well, there aren't a lot of shiny new things.
My intent was really around use cases and not identities - perhaps those sections above could really be longer descriptions of a story/use case - "Improved management and monitoring capabilities," "Efficient tooling to enable rapid boot time and system recovery," etc?
-r
-- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
-- marketing mailing list marketing@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/marketing
----- Original Message -----
On Mon, Mar 25, 2013 at 6:42 AM, Nicu Buculei nicu_fedora@nicubunu.ro wrote:
Robyn Bergeron wrote:
Is bucketizing a bunch of stuff into "User, Sysadmin, Developer" the best answer for marketing highlights of the release? It seems like... well, a listing of car parts, but not really telling a story about the car, for lack of a better metaphor. And it seems a lot like "we made a bunch of improvements here and there" isn't as compelling as "we have improved overall state of ($experience, $usecase, etc) and here's how."
We have the big problem of Fedora generally perceived as 'not intended for "normal" users', imagine this, a "normal" user parsing fast the announcement, his reaction "Develop and Distribute, Start and Recover, Monitor and Manage - which of those is for *me*?"
Take a look at the feature list. I think I can classify the following things as being for "normal" users:
- Improved mobile broadband support (incremental changes, but nice, I
suppose)
Well, that's it. Anaconda improvements are incremental and not an overhaul, mostly focused on enabling advanced/more complex options. We have a handful of desktops with nothing earth-shaking enough in terms of changes to highlight individually, other than in a section dedicated to Spins/Desktops, where we've commonly detailed those items.
There's obviously options around *explaining* in the course of the announcement/talking points / etc that "fedora can be for everyone" - but I think it's fairly difficult to say, "Hey! look at all the new shiny things we have for $generaluser" when ... well, there aren't a lot of shiny new things.
My intent was really around use cases and not identities - perhaps those sections above could really be longer descriptions of a story/use case - "Improved management and monitoring capabilities," "Efficient tooling to enable rapid boot time and system recovery," etc?
I'd say too complex story/use cases could be more alien to "general" user - and I'd say, I'd have a big trouble with "Efficient tooling to enable rapid boot time and system recovery" too.
Main issue here is - do we want to take only the accepted changes (and yes, there could be a problem there's no interesting change for some groups at all) or take these and add some "general" addition, usually same or very similar (just updated) between releases? Maybe.
Generally I'd say I like your idea, it should be really more flexible than that "old" categories.
Jaroslav
-r
-- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
-- marketing mailing list marketing@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/marketing
-- marketing mailing list marketing@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/marketing
----- Original Message -----
On Mon, Mar 25, 2013 at 6:42 AM, Nicu Buculei nicu_fedora@nicubunu.ro wrote:
Robyn Bergeron wrote:
Is bucketizing a bunch of stuff into "User, Sysadmin, Developer" the best answer for marketing highlights of the release? It seems like... well, a listing of car parts, but not really telling a story about the car, for lack of a better metaphor. And it seems a lot like "we made a bunch of improvements here and there" isn't as compelling as "we have improved overall state of ($experience, $usecase, etc) and here's how."
We have the big problem of Fedora generally perceived as 'not intended for "normal" users', imagine this, a "normal" user parsing fast the announcement, his reaction "Develop and Distribute, Start and Recover, Monitor and Manage - which of those is for *me*?"
Take a look at the feature list. I think I can classify the following things as being for "normal" users:
- Improved mobile broadband support (incremental changes, but nice, I
suppose)
Well, that's it. Anaconda improvements are incremental and not an overhaul, mostly focused on enabling advanced/more complex options. We have a handful of desktops with nothing earth-shaking enough in terms of changes to highlight individually, other than in a section dedicated to Spins/Desktops, where we've commonly detailed those items.
There's obviously options around *explaining* in the course of the announcement/talking points / etc that "fedora can be for everyone" - but I think it's fairly difficult to say, "Hey! look at all the new shiny things we have for $generaluser" when ... well, there aren't a lot of shiny new things.
My intent was really around use cases and not identities - perhaps those sections above could really be longer descriptions of a story/use case - "Improved management and monitoring capabilities," "Efficient tooling to enable rapid boot time and system recovery," etc?
I'd say too complex story/use cases could be more alien to "general" user - and I'd say, I'd have a big trouble with "Efficient tooling to enable rapid boot time and system recovery" too.
Main issue here is - do we want to take only the accepted changes (and yes, there could be a problem there's no interesting change for some groups at all) or take these and add some "general" addition, usually same or very similar (just updated) between releases? Maybe.
Generally I'd say I like your idea, it should be really more flexible than that "old" categories.
Jaroslav
-r
-- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
-- marketing mailing list marketing@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/marketing
-- marketing mailing list marketing@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/marketing
On Mon, Mar 25, 2013 at 2:42 PM, Nicu Buculei nicu_fedora@nicubunu.ro wrote:
We have the big problem of Fedora generally perceived as 'not intended for "normal" users', imagine this, a "normal" user parsing fast the announcement, his reaction "Develop and Distribute, Start and Recover, Monitor and Manage - which of those is for *me*?"
Maybe we should 'borrow' user facing material from the main user environments we ship? gnome and kde (possibly, others) makes a good job already about documenting new features
-- Gianluca Sforna
http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu
----- Original Message -----
Hi, 2. Note that I'm not advocating for the "user, sysadmin, dev" categories to change in docs-land; I think that these stories/themes are likely to change with each release. But, given the intertwinement of docs and marketing when it comes to the release announcement, it seems like (if docs is crafting the tech-bits of the release announcement) if we were to bucketize by stories, that we'd need to get marketing to figure out what those stories are. And I don't just mean the overarching stories, but also the individual feature stories, in some cases; I can't tell you how many times I look at a feature and say, wow, I wish I spoke that language, I wonder what the bigger picture is, what this effectively enables? Maybe the talking points is a launch point for that as well, in additoin to being the list that gets handed off to ambassadors, and then can drive the story collections in a release announcement, or in one-page release notes; I'm not sure. Thoughts? The workflow, as often seems to be the case between docs & mktg, is key.
I'll skip directly to the workflow here - as I generally agree with the idea you'd like to implement.
So for workflow - what we have now? We have features/change proposals, from these we have to in some way prepare release notes -> extend to documentation for bigger changes, the second part are talking points -> featuring "shiny" changes -> and finally flipped to release announcement and other marketing stuff. Currently all of these are tracked in different places, we still don't have a strong ownership of individual tasks and it often goes out of sync (aka was this feature/change really finished, so we can document it and market it?).
What I do right now, I'm trying to revamp feature/change proposal template, the Feature List and I'd like to "centralize" the planning and tracking of not only development but also these tasks.
How could it look like?
Instead of plain Features List, I'd like to have a clear overview, generated (I have scripts) from Change Proposals pages. It's very rough draft! https://fedoraproject.org/wiki/Releases/20/ChangeSet
The template could be extended - not only to be change owner place, but to offer planning/tracking space for Docs, QA, Marketing etc. See our current draft: https://fedoraproject.org/wiki/JaroslavReznik/ChangeProposalTemplate
My question is - what would be useful for your teams to be available in the change proposal page? What's needed for tracking RNs, TPs etc. - tracking bugs, ownership etc. I can definitely help here with coordination - one place for the process from beginning to the end - to release could make it more manageable.
I'm not saying it's perfect, very theoretical for now - but we can be flexible, there's not so much time for Fedora 20 but it can be on going effort - to make it better and perfect one day ;-)
Robyn, sorry - I don't want to kidnap your topic :) just it's one part - the wokflow, how.
Thanks Jaroslav
Basically: Seeking feedback? Thoughts, anyone?
:D
-Robyn
marketing mailing list marketing@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/marketing
On Wed, Mar 27, 2013 at 6:44 AM, Jaroslav Reznik jreznik@redhat.com wrote:
----- Original Message -----
Hi, 2. Note that I'm not advocating for the "user, sysadmin, dev" categories to change in docs-land; I think that these stories/themes are likely to change with each release. But, given the intertwinement of docs and marketing when it comes to the release announcement, it seems like (if docs is crafting the tech-bits of the release announcement) if we were to bucketize by stories, that we'd need to get marketing to figure out what those stories are. And I don't just mean the overarching stories, but also the individual feature stories, in some cases; I can't tell you how many times I look at a feature and say, wow, I wish I spoke that language, I wonder what the bigger picture is, what this effectively enables? Maybe the talking points is a launch point for that as well, in additoin to being the list that gets handed off to ambassadors, and then can drive the story collections in a release announcement, or in one-page release notes; I'm not sure. Thoughts? The workflow, as often seems to be the case between docs & mktg, is key.
I'll skip directly to the workflow here - as I generally agree with the idea you'd like to implement.
So for workflow - what we have now? We have features/change proposals, from these we have to in some way prepare release notes -> extend to documentation for bigger changes, the second part are talking points -> featuring "shiny" changes -> and finally flipped to release announcement and other marketing stuff. Currently all of these are tracked in different places, we still don't have a strong ownership of individual tasks and it often goes out of sync (aka was this feature/change really finished, so we can document it and market it?).
Talking points aren't the basis for release announcements. The only thing they are a predecessor to is feature profiles (and even this association is fairly loose; feature profiles can be chosen and completed without doing talking points.) They can share content, but: from the Marketing POV, Release Announcements are, in my mind, "do or die"; talking points, feature profiles, etc. are more or less NTH. (And let me be clear: VERY nice to have, we really really should do these things, but we aren't going to have people in death matches on mailing lists if talking points/feature profiles don't get done.)
I also don't think that the marketing and docs portions necessarily need to be intertwined with one another, aside from perhaps the release annoucement (I'll get to that in a second). The marketing things - talking points, feature profiles - were never intended to cover every single thing, the SOPs around them are fairly specific about picking a handful of items; they're really intended to help catch people's attention and give them a reason to install Fedora. Release notes (and by some extent the rest of the documentation) are more comprehensive, give details on the less "shiny" things that tend to not get press attention as well as the Shiny Things, because they're a useful reference for when folks have their system installed, and in the case of release notes, specifically for folks who are previous users who want to see what has changed. The basis for how items are chosen are fairly different for marketing and docs.
The release announcement tends to be where there is more crossover, and I think it's mostly because folks writing the release announcement tend to look to the release notes for some pre-canned materials to write from, whether they are folks from docs or marketing writing the announcement, but marketing tends to guide a bit as to what bits should be highlighted.
What I do right now, I'm trying to revamp feature/change proposal template, the Feature List and I'd like to "centralize" the planning and tracking of not only development but also these tasks.
How could it look like?
Instead of plain Features List, I'd like to have a clear overview, generated (I have scripts) from Change Proposals pages. It's very rough draft! https://fedoraproject.org/wiki/Releases/20/ChangeSet
The template could be extended - not only to be change owner place, but to offer planning/tracking space for Docs, QA, Marketing etc. See our current draft: https://fedoraproject.org/wiki/JaroslavReznik/ChangeProposalTemplate
My question is - what would be useful for your teams to be available in the change proposal page? What's needed for tracking RNs, TPs etc.
- tracking bugs, ownership etc. I can definitely help here with
coordination - one place for the process from beginning to the end
- to release could make it more manageable.
I think at the bare minimum: Having a page that lists Changes (both systemwide and self-contained) that were "dropped" - and having a way for both marketing and docs to individually ack that features were removed from "upcoming" documentation/collateral/"written anything" (that is to say: we don't want to "retroactively" remove a "change" from an announcement that already went out).
Notification could either be a ticket, weekly mail that has a list of "adds" and "subtracts" to changes (subtracts going in a page of "removed changes" or etc), or something else. And then have a checkpoint near alpha/beta/final change deadlines for individual teams to double-check the list for any changes/subtractions to the feature set, and make sure those removals aren't being written about.
The sticky part here is that once we get into beta mode, release notes have to be ready well before the deadline where we'd know features got dropped - things are moving from wiki to publican, and then they have to be translated, so anything dropped after that point not only needs to get tracked back through marketing and docs but also translations.
I'm not saying it's perfect, very theoretical for now - but we can be flexible, there's not so much time for Fedora 20 but it can be on going effort - to make it better and perfect one day ;-)
Robyn, sorry - I don't want to kidnap your topic :) just it's one part - the wokflow, how.
Thanks Jaroslav
Basically: Seeking feedback? Thoughts, anyone?
:D
-Robyn
marketing mailing list marketing@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/marketing
-- docs mailing list docs@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
----- Original Message -----
Hey, sorry - I completely missed your reply :( I'll skip the first part for now and let me more to the docs/marketing team discussion (so heads up docs guys, expect marketing visit on Monday's meeting!).
What I do right now, I'm trying to revamp feature/change proposal template, the Feature List and I'd like to "centralize" the planning and tracking of not only development but also these tasks.
How could it look like?
Instead of plain Features List, I'd like to have a clear overview, generated (I have scripts) from Change Proposals pages. It's very rough draft! https://fedoraproject.org/wiki/Releases/20/ChangeSet
The template could be extended - not only to be change owner place, but to offer planning/tracking space for Docs, QA, Marketing etc. See our current draft: https://fedoraproject.org/wiki/JaroslavReznik/ChangeProposalTemplate
My question is - what would be useful for your teams to be available in the change proposal page? What's needed for tracking RNs, TPs etc.
- tracking bugs, ownership etc. I can definitely help here with
coordination - one place for the process from beginning to the end
- to release could make it more manageable.
I think at the bare minimum: Having a page that lists Changes (both systemwide and self-contained) that were "dropped" - and having a way for both marketing and docs to individually ack that features were removed from "upcoming" documentation/collateral/"written anything" (that is to say: we don't want to "retroactively" remove a "change" from an announcement that already went out).
The main idea behind the "Changes" is - these will never be dropped from the list unlike the old "Features", just status will change (aggregated from change bug).
Explanation in more details: Features were changes we wanted to market, and at least by current FESCo it was understood as a primary goal. So Feature that missed any deadline were dropped from the list not to market them(!) but still maintainers could work on these, not being a development ban, even finished. But in this case - we lost track. For Changes - primary goal is to track development, from the beginning to the end of release, even Change is not finished in the end. And only selected Changes with appropriate status will be marketed. That's the main semantic difference between these too kinds.
Notification could either be a ticket, weekly mail that has a list of "adds" and "subtracts" to changes (subtracts going in a page of "removed changes" or etc), or something else. And then have a checkpoint near alpha/beta/final change deadlines for individual teams to double-check the list for any changes/subtractions to the feature set, and make sure those removals aren't being written about.
I like the idea of weekly report/notification - as I said above, I'd like to avoid calling it additions/removals but more status change. I'd be definitely happy to do it.
The sticky part here is that once we get into beta mode, release notes have to be ready well before the deadline where we'd know features got dropped - things are moving from wiki to publican, and then they have to be translated, so anything dropped after that point not only needs to get tracked back through marketing and docs but also translations.
Ok, it's true. With Docs team we decided to follow the same process as for development - to have a tracking bug (that will block the development one). Then it should be easier (if done properly by everyone involved) to see the changes earlier and notify people.
So let's meet on Monday ;-).
Thanks Jaroslav
I'm not saying it's perfect, very theoretical for now - but we can be flexible, there's not so much time for Fedora 20 but it can be on going effort - to make it better and perfect one day ;-)
Robyn, sorry - I don't want to kidnap your topic :) just it's one part - the wokflow, how.
Thanks Jaroslav
Basically: Seeking feedback? Thoughts, anyone?
:D
-Robyn
marketing mailing list marketing@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/marketing
-- docs mailing list docs@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
-- marketing mailing list marketing@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/marketing
marketing@lists.fedoraproject.org
-
Gianluca Sforna -
Jaroslav Reznik -
Nicu Buculei -
Robyn Bergeron