release announcements, talking points, release notes, and how we group features into audiences or stories

Jaroslav Reznik jreznik at redhat.com
Wed Mar 27 13:44:57 UTC 2013


----- 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/marketing


More information about the marketing mailing list