Hi docs people,
It's that time in the release cycle again when your help is needed to
put together release notes for Fedora 28. (Actually the time was like a
month ago, but we still have time to produce something for beta.)
There is a number of open issues against the release notes repo on
Pagure, which is where everyone should start:
https://pagure.io/fedora-docs/release-notes/issues
Note that 1) there's a page two, and 2) some of the issues are filed
ahead for F29, so please pay attention to what you're assigning to
yourselves.
Detailed instructions:
1) Go to the link above
2) Identify one or more issues you want to cover for this release
3) Assign yourself to the issue (if you're logged in to Pagure using
your FAS account, there will be a "Take" button in the left sidebar when
you open the issue)
4) For issues that were created for covering Changes, there's always a
link in the description. Follow it to learn more about what you're
covering. Some issues also have additional links provided by their
owners or anyone else in the comments, check those out too.
5) Write something about the subject matter using the information you
just gathered. Pro tip: a lot of Changes involve introducing a new
version of an existing component, like a programming language, into the
next release, which means the component has an upstream version with its
own documentation including release/patch notes. In these cases, it's
good to pick a few notable changes and mention them in Fedora's release
notes, and link upstream for the rest. "For more information about this
release of Python, see <link>." Saves you a ton of work and it's still
useful to the reader.
6) Contact the Change owner(s), or in case of issues that aren't
covering Changes, contact the person who opened the issue - or really
anyone you can think of who might have some insight into the matter -
and ask them nicely to check out what you wrote and make sure it's
technically accurate. To make this review easier, I recommend doing this
through issue comments, and @-pinging people so they get a notification.
If they don't respond within a reasonable time frame (give them a few
days), try contacting them in other ways - typically #fedora on FreeNode
or e-mail.
7) Once your contact(s) tell you your text is fine (this may or may not
take a bit of going back and forth), you have two choices:
* If you're familiar with ASCIIDoc and git, fork the release-notes
repo, mark up your text and make a merge request. Once it's accepted,
close the issue. (This might actually happen automatically during the
merge, I can't remember...)
* If you're not familiar with any of the above, just leave the final
version in the comments, and then add a tag to the issue indicating it
needs someone to do that. To do this, open the issue page, click "Edit
metadata" in the sidebar, and add a tag that says "needs_markup". Me and
hopefully a couple other people will check the issue list occasionally
and mark up and commit anything with that flag.
Important note: If you are assigned to an issue, but something happens
and you know you're unlikely to actually be able to cover it for any
reason, please drop the issue as soon as you find out. We want to avoid
a last minute rush.
There's a lot to go through and F28 Beta is coming out in a few weeks
(March 27 by current schedule). The main target is to have hopefully
everything written up by final release, which is currently scheduled for
May 1, but that's always subject to change. The sooner stuff is done the
better, obviously.
Finally, if you know of any notable changes in F28 that don't have an
open issue but you feel should be covered by the Release Notes, go ahead
and open an issue. Note that we prefer to focus on new features; writing
about bugs that have been resolved or known issues would be nice but
it's a massive amount of work, so let's avoid that unless it's really huge.
Have fun,
PB
_______________________________________________
docs mailing list -- docs@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to docs-leave@xxxxxxxxxxxxxxxxxxxxxxx
