Contribuire alle note di rilascio

Fedora Documentation Team <https://discussion.fedoraproject.org/tag/docs> v0.0.1, 2022-09-26

Questa sezione descrive come contribuire alle note di rilascio di Fedora. Prima di iniziare a seguire questa procedura, assicurati di soddisfare tutti i requisiti elencati in Prerequisiti.

Il processo di contribuzione alle Note di Rilascio è descritto in una pagina separata, poiché è diverso da quello della restante documentazione di Fedora. Se sei interessato a contribuire ad altri documenti, consulta la pagina corrispondente.

Le Note di Rilascio sono uniche in quanto, a differenza di tutta la restante documentazione, vengono scritte quasi completamente da zero per ogni nuova versione, mentre tutte le altre documentazioni vengono mantenute tra una versione e l’altra, aggiornandole solo quando necessario. Questo significa che alcune parti della procedure descritta di seguito, come il branch git utilizzato o il calendario, cambiano con ogni nuova versione. Prima di iniziare a scrivere le Note di Rilascio, consulta il link:https://discussion.fedoraproject.org/tag/docs[#docs su Fedora Discussion, in particolare la barra laterale a destra. Troverai lì informazioni aggiornate.

Come contribuire alle note di rilascio di Fedora

  1. Check the sidebar on Fedora Discussion, and note the provided information: Release, schedule, branch, and link to the list of relevant issues.

  2. Pick one or more issues from the list of open and unassigned issues for the release which you want to contribute to.

  3. 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 finish it, remove yourself from the issue ASAP so someone else can pick it up.
  4. Find information about your issue. A lot of them have plenty of info in them already, especially in the Wiki link; if you need more, find out who is responsible for the change (also listed on the Wiki page linked in the issue), and @-mention them in the issue comments or talk to them on IRC/Matrix or via mail. Keep in mind that 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 time frame; in that case just do your best, if something ends up being wrong, we can always update it later.

  5. Write a release note about the issue. If you’re not sure what exactly a release note looks like, check out some of the previous releases for inspiration. We don’t want any long, overly technical texts, the release notes are generally meant to highlight changes, not to tell people how to use something.

  6. Now the workflow diverges based on your Pagure permissions and technical skills:

    • If you know how to use git and ASCIIDoc, write up the release note and send a pull request against the main repository. Make sure you open the pull request against the correct branch, not main - see first step of this procedure for info. (The main branch is only used as a template for each new release, so it only contains an empty structure and some pages that do not vary between releases.) 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.

If you can’t see the section where you added your contributions at all, make sure that it’s included in the table of contents in modules/release-notes/nav.adoc.

+ * If the above sounds like gibberish to you, it’s fine. Just add a comment with your text into the issue, and someone will mark it up and add it to the final document.

Repeat the above for as many issues as you want.