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

[Robyn Bergeron]

On Wed, Mar 27, 2013 at 6:44 AM, Jaroslav Reznik <jreznik at 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 at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/marketing
> --
> docs mailing list
> docs at lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/docs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/docs/attachments/20130401/3e59498c/attachment.html>