release announcements, talking points, release notes, and how we group features into audiences or stories
by Robyn Bergeron
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
10 years, 12 months
[Bug 450331] New: lack of documentation on restoring from bare-metal (UUID problem)
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=450331
Summary: lack of documentation on restoring from bare-metal (UUID
problem)
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: docs-requests
AssignedTo: kwade(a)redhat.com
ReportedBy: czar(a)acm.org
QAContact: stickster(a)gmail.com
CC: fedora-docs-list(a)redhat.com
Description of problem:
ref: https://bugzilla.redhat.com/show_bug.cgi?id=449299
There is a lack of documentation on restoring a system from bare metal. I have
found (see reference) that restore the root ("/") is not as simple as as just
executing the restore command when running in rescue mode.
With the current emphasis being place on use of UUIDs in both Fedora and RHEL,
the whole business of UUIDs need to be better documented.
Version-Release number of selected component (if applicable):
Fedora 9
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
11 years
Docs Project Meeting Summary
by Pete Travis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As promised, I'm catching up on sending out meeting summaries. The notes below
will cover the most recent 25 March meeting as well as last week's 18 March
meeting.
- - 18 March 2013 -
We talked about the progress towards changing our publishing platform. It was
generally decided that Rudi had things well in hand, but that we'd like to
know what was going on. Lnovich offered to track him down.
I brought up a thread on devel@ containing a proposal for a help center
desktop application, which you can read at
http://lists.fedoraproject.org/pipermail/devel/2013-March/180093.html or
https://fedoraproject.org/wiki/Design/Help_Center_Idea . I expressed concern
that unvalidated content from ask.fp.o would take semantic precedence over
curated content from the docs writers, and urged the other members to comment
on the proposal with their own thoughts.
The group graciously accepted nagging about Release Note beats.
jreznik asked us to review his comments on the docs list, and the wiki page
for the changes process. The general feeling has been that we would like help
with raw content, and want developers to know don't expect polish.
The meeting ended a bit late, apologies to the QA team. Zodbot asked us to
read some links as the meeting closed:
http://meetbot.fedoraproject.org/fedora-meeting/2013-03-18/docs_project_a...
http://meetbot.fedoraproject.org/fedora-meeting/2013-03-18/docs_project_a...
- - 25 March 2013 -
The new publishing platform was on the table again. lnovich spoke with Rudi
about it, as did I. The end result will give us a very simple and effective
publishing process that our RH contributors will probably find familiar. If I'm
recalling it correctly, some magic of publican and git combines to allow us to
publish a single translation of a document with a single command, nicely
wrapping up the RPM packaging process, building in git, and installing to
production in one go.
rbergeron stopped by, and we touched on the Changes/Feature process. [ I'm
still not sure of the appropriate name for it! ] We need to make a point to
validate the information we pull out of the Feature pages into the beats at
each release stage, because the former is dynamic and the latter has been...
less dynamic.
shaiton valiantly volunteered to clean up the duplicate language teams on
transifex. It looks like much of that has been completed by the time I sat
down to write the summary - thanks shaiton!
The logs are available for your review at:
http://meetbot.fedoraproject.org/fedora-meeting/2013-03-25/fedora_docs.20...
http://meetbot.fedoraproject.org/fedora-meeting/2013-03-25/fedora_docs.20...
- Afterthoughts -
If you can't make it to the meeting, please use the list!
- --
- -- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAEBAgAGBQJRUUGSAAoJEL1wZM0+jj2ZX24H/j19yAwuFAiB5R0yU56zhpi4
/HlRHjtUHaEe4KuO82Qajki4E4Icp/z4NfcABAKZ5lAfOGZKuLl1j0VPPzBxx5/G
rxzBQMuR+6dKOdkhqSMKvi4lByxmVEtXaC3HLA00IlPY5BSGflVZr4iHQZSZdvKX
zpKbtil5K1BaP3FJ48q2MRQyP0ex77sLLTGIMZjmgkVrvk5XSqEnnI8vcIJBLUCj
/9RLbMXea6epQk/eqCAueC87eMNJb9oa/B/adkQNMNuOfyWy9ocmgH+4hD3HrlqW
p5YUk6eUJdzdL7K+B1WEFrkewxnMkuh0aqB6eOFX6JT4iteXQiOKz7b/Nlsev/k=
=7U7n
-----END PGP SIGNATURE-----
11 years
Fedora Docs Meeting Reminder - 1400UTC 25MAR2013
by Pete Travis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings, wordslingers!
Boil your coffee and dust off your nibs, we're having a meeting in the morning.
Round up in #fedora-meeting at first light, or around 1400UTC.
The agenda is up at
https://fedoraproject.org/wiki/Docs_Project_meetings#25_March_2013 , with last
week's logs at http://meetbot.fedoraproject.org/fedora-meeting/2013-03-18/ .
I'll double up on summaries to make up for missing them for the last meeting.
- --
- -- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAEBAgAGBQJRT+0BAAoJEL1wZM0+jj2ZRfIH/jpnR7S580JTTQo74UVwpcGL
rX9gYZpYg7I1WEyheot1wLrziy5V5noV3UwrgdPgYs6F06LuJvPRiUnVm9QjM8yG
wxyti3GRkyYjMJpizwRwq0+9XUuOb20qBx8xfTEnjNWjsMOgxjFL5it0Y/C1hOlk
udjEtoXxEp7g2DPHmP5qoayY0qzLy4cz22RKQF5nqBKcHxs4rEjZUGMBJ8bvHl9a
8d6qh7axMQ5bWzDJLNpvJP6/dCPrb4E/xhrJcDwJCQ7iAcUkMMr3KDqbhm2nXYGs
hySyElsMyVlRrZpsgNyo0UrvBcGUj+Qrf3ymY5LFl/LEihMg+rstJMgTDWZ3aCQ=
=ieLS
-----END PGP SIGNATURE-----
11 years
removing dupplicate teams at transifex
by Kévin Raymond
Hi there,
Months ago we merged the dupplicate teams at transifex.net.
I had to remove the old teams, but still haven't done that yet.
I saw some push on the wrong teams...
Therefore, I plan to remove those teams (without any team member) next week.
I have to do them all one by one, not sure if I will have all the access but
will sort this.
You should not notice any thing unless you were pulling the wrong language code.
Which should not happen if you have the right language mapping:
https://fedoraproject.org/wiki/Setting_up_a_document_with_Transifex#Step_...
Please tell me if you think something has to be done before.
I will probably pull them all for backup but since I haven't started.. :)
See ya!
--
Kévin Raymond
(Shaiton)
11 years
An easier way to create Transifex config files.
by Eric Christensen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm guessing that not all Docs folks are glued to my blog[0][1] like you should be. Nonetheless, I'll pass along a tool[2] that I created in hopes of making Transifex client configuration easy to create.
- -Eric
[0] https://sparkslinux.wordpress.com
[1] https://sparkslinux.wordpress.com/2013/03/19/create-tx-configuration/
[2] https://gitorious.org/create-tx-configuration
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQGcBAEBAgAGBQJRSeVGAAoJEB/kgVGp2CYvsMcL/AzIJGgcliUOW+goUUFumiVd
8qa+1tQ056ccaHPLhPrv5nktFn+/4GJg8fpN3g6+QKATneqLBTBp01GVETVqsHR+
QoXhLcrxliYCUANzyuG3PolkgZP5Ij61n+BrFcM80nBIiyKKuEqbzG8rJHSpEm66
iG5LggXwtXvOnyO9nE1mnTHDx/+kehkUXQC+QsmaCXKuZX/PfFT23I+mYYT0A7dm
O+NviqEbl67kcyDXmYkwBim1FXBSoRdB+MdNAhm6CjW5orNLzV+SXUZkdxrpbaTO
cnh+kiWuKA7FsS33SE3jhvw9PxRt9CA0hOcbsNTQpcmd74iCYMCdd98Z2leAae1I
8/t1F8Ky3gOPItXGhS3n/wEWckoSYfWarUDh7qE1dbxFyTMxo9nI3Ra7bZP5FSb/
WlutMKnLb/9+HMC4/rbjyfaFPb7j1Mw+d7jTkH65mOrNcZTHokGq4UPG3SLFGcSl
7+Ogr/joyfk6sfL0/B0ph0pWn1huRROaWSPJzi4WFA==
=MrbP
-----END PGP SIGNATURE-----
11 years, 1 month
Meeting Reminder
by Pete Travis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey Docs Team,
Please join me in meeting at 1400UTC in #fedora-meeting on freenode today, 18
March 2013.
Thanks,
- --
- -- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAEBAgAGBQJRRsLnAAoJEL1wZM0+jj2Z3yIH/RUP+BnrUyR9g+OrzUONn1U3
4+/hxHYI6q9MlX5CWuRjRmEYAZ9rrTklHn2iV6aagorMqHF2L+72MfwZGVRA1o/p
sMnDr9WM9kCDFPm5pacWVBaTp2ct30KK4TFdSe52ctSHoVNVgEgY7saxTRnFeC5L
09R62oVIbKguToZ0qagUdDqyutLTonet6mTL0JrzHvMz2FL9fwpR8HCJjw0JaP+Z
Oep+5hGRO/zFjpY8/lUOVSsqbY0/KhNYM2J42uoDhSl+hBAfH8fG6oMSDFEeldcB
xI3g1y5CcmRKriwz9ZZUGUJq8+zRogAK0uyoGEQhTwuncSYB9YXDZF6djoME5so=
=rsXd
-----END PGP SIGNATURE-----
11 years, 1 month
