Hi everyone!
Today's F32 Beta Go/No-Go meeting earlier today resulted in a no-go status, but nevertheless, it's about time we started working on F32 release notes. As usual, we aim to cover notable Changes[0]. Ben Cotton has been tracking those in the relnotes repo's issues for us, which allows us to grab a list of everything that needs to be documented[1].
Some of you are already familiar with the process, so go ahead and grab some issues; branch f32 is waiting for you. For those of you who are new or need a refresher, here's how it works:
1. Pick one or more issues in the list linked above.
2. Open each issue you picked, and click the Take button on the right to claim it. (If you claim an issue but later find out you don't have time to write about it, remove yourself from the issue ASAP so others can see it's free and take it!)
3. Find some information about the issue. A lot of them have plenty of info in them already; if not, find out who's responsible for the change, and talk to them on IRC or via mail. Of course it's always better if you try to do research before you ask questions. Note that you might not always be able to reach the owner in a reasonable timeframe; in that case just do your best, I'll be reviewing PRs, so if we publish something wrong, it's on me.
4. Write a release note about the issue. If you're not sure how exactly a release note looks, check out some of the previous releases for inspiration. We don't want any long, overly technical texts, the release notes are meant to highlight changes, not to tell people how to use something.
5. Now the workflow diverges based on your permissions and technical skills:
5a. If you know how to use git and asciidoc, we'd appreciate if you wrote up the release note and sent a pull request[2] against the main repo, branch "f32". Your contributions should go into one of the files in "modules/release-notes/pages/", which one exactly depends on the contents of the change you're documenting. Use the "build.sh" and "preview.sh" scripts in the repository root to preview your changes locally; see the repository README for specific instructions. If you can't see the section where you added your contributions at all, make sure it's included in "modules/release-notes/nav.adoc".
5b. If the above sounds like gibberish to you, it's fine: just add a comment with your text into the issue, and ping me on IRC/Telegram or through e-mail; I'll mark it up for you and make sure your contribution appears in the final document.
If anyone has any questions, go ahead and ask either here on the list or on IRC/Telegram, I'm happy to help. The current schedule[3] gives us until April 14 (see line 9), after that we'll be handing the release notes to the localization team. This gives us a month, which should be enough to cover the 55 open issues.
Happy writing!
Petr
[0] https://fedoraproject.org/wiki/Releases/32/ChangeSet [1] https://pagure.io/fedora-docs/release-notes/issues?status=Open&search_pa... [2] https://docs.pagure.org/pagure/usage/pull_requests.html [3] https://fedorapeople.org/groups/schedule/f-32/f-32-docs-tasks.html
Le 2020-03-13 00:45, Petr Bokoc a écrit :
Hi everyone!
Is there a reason not to see all changes? I wanted to take the change about the translation platform migration, but can't see it. Is that fine to add a new issue about it or should it go through a specific workflow?
Jean-Baptiste
On 3/13/20 9:18 AM, Jean-Baptiste Holcroft wrote:
Le 2020-03-13 00:45, Petr Bokoc a écrit :
Hi everyone!
Is there a reason not to see all changes? I wanted to take the change about the translation platform migration, but can't see it. Is that fine to add a new issue about it or should it go through a specific workflow?
Yeah, go ahead and open an issue. Make sure it has "F32" in the title since that's how we filter them.
Petr
On Fri, Mar 13, 2020 at 4:19 AM Jean-Baptiste Holcroft jean-baptiste@holcroft.fr wrote:
Is there a reason not to see all changes? I wanted to take the change about the translation platform migration, but can't see it. Is that fine to add a new issue about it or should it go through a specific workflow?
I generally don't open issues for changes that are "internal". If there's no user-facing change, there's no need IMO for a Release Notes entry. If Petr's okay with it, I won't argue against including the translation platform migration.
On Fri, Mar 13, 2020 00:45:37 +0100, Petr Bokoc wrote:
Hi everyone!
Hi Petr,
Do you think this could also be sent to the announcement mailing lists, or at least -devel. Lots of folks who may be interested do not keep an eye on team specific mailing lists, so spreading the word out would be quite a good thing.
On 3/13/20 9:30 AM, Ankur Sinha wrote:
On Fri, Mar 13, 2020 00:45:37 +0100, Petr Bokoc wrote:
Hi everyone!
Hi Petr,
Do you think this could also be sent to the announcement mailing lists, or at least -devel. Lots of folks who may be interested do not keep an eye on team specific mailing lists, so spreading the word out would be quite a good thing.
Good idea, I'll do that. I also pinged a few Red Hat writers who helped in the past.
Petr
Hello again!
We've made some good progress on F32 release notes so far - big thanks to everyone who contributed! Just a reminder, as of today now have one week to finish up and hand the doc over to localization. At the same time, some parts of the world will be celebrating Easter around this weekend (well, as much as one can during a pandemic :), so please make sure to finish as much as you can, preferably this week, and drop any issues currently assigned to you that you won't be able to finish so that someone else can potentially pick them up.
Cheers,
Petr
On 3/13/20 12:45 AM, Petr Bokoc wrote:
Hi everyone!
Today's F32 Beta Go/No-Go meeting earlier today resulted in a no-go status, but nevertheless, it's about time we started working on F32 release notes. As usual, we aim to cover notable Changes[0]. Ben Cotton has been tracking those in the relnotes repo's issues for us, which allows us to grab a list of everything that needs to be documented[1].
Some of you are already familiar with the process, so go ahead and grab some issues; branch f32 is waiting for you. For those of you who are new or need a refresher, here's how it works:
Pick one or more issues in the list linked above.
Open each issue you picked, and click the Take button on the right
to claim it. (If you claim an issue but later find out you don't have time to write about it, remove yourself from the issue ASAP so others can see it's free and take it!)
- Find some information about the issue. A lot of them have plenty of
info in them already; if not, find out who's responsible for the change, and talk to them on IRC or via mail. Of course it's always better if you try to do research before you ask questions. Note that you might not always be able to reach the owner in a reasonable timeframe; in that case just do your best, I'll be reviewing PRs, so if we publish something wrong, it's on me.
- Write a release note about the issue. If you're not sure how
exactly a release note looks, check out some of the previous releases for inspiration. We don't want any long, overly technical texts, the release notes are meant to highlight changes, not to tell people how to use something.
- Now the workflow diverges based on your permissions and technical
skills:
5a. If you know how to use git and asciidoc, we'd appreciate if you wrote up the release note and sent a pull request[2] against the main repo, branch "f32". Your contributions should go into one of the files in "modules/release-notes/pages/", which one exactly depends on the contents of the change you're documenting. Use the "build.sh" and "preview.sh" scripts in the repository root to preview your changes locally; see the repository README for specific instructions. If you can't see the section where you added your contributions at all, make sure it's included in "modules/release-notes/nav.adoc".
5b. If the above sounds like gibberish to you, it's fine: just add a comment with your text into the issue, and ping me on IRC/Telegram or through e-mail; I'll mark it up for you and make sure your contribution appears in the final document.
If anyone has any questions, go ahead and ask either here on the list or on IRC/Telegram, I'm happy to help. The current schedule[3] gives us until April 14 (see line 9), after that we'll be handing the release notes to the localization team. This gives us a month, which should be enough to cover the 55 open issues.
Happy writing!
Petr
[0] https://fedoraproject.org/wiki/Releases/32/ChangeSet [1] https://pagure.io/fedora-docs/release-notes/issues?status=Open&search_pa... [2] https://docs.pagure.org/pagure/usage/pull_requests.html [3] https://fedorapeople.org/groups/schedule/f-32/f-32-docs-tasks.html
docs mailing list -- docs@lists.fedoraproject.org To unsubscribe send an email to docs-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/docs@lists.fedoraproject.org
docs@lists.stg.fedoraproject.org
-
Ankur Sinha -
Ben Cotton -
Jean-Baptiste Holcroft -
Petr Bokoc