pboy commented

Owner

This ticket provides a summary of various detailed tickets.

Summary of the state of the discussion as at 19 August 2026

We have at least 4 topics / Types of issues to discuss.

New structure for postinstall

Ticket #228

Already agreed:

The current article will be split into a new subdirectory containing several smaller, more focused articles on topics like "Networking," "Storage," "Security hardening," and "Backups."

Still to decide:

naming
- Alternatives: (1) "post-installation customizations" | (2) "postinstall" | (3) "postinstallation"
contents
- Basic steps Alternatives: First steps
- Network consolidation Alternatives: Networking
- Storage organisation Alternatives: Storage
- Fail2ban and other security measures Alternatives: Security hardening
- Various other brief topics
- DNF / Update Alternatives: Automatic updates
- Organisation of backups Alternatives: Backups
position
- The new subdir may be the 4th after containerization.

Ticket #224

Already done:

rename "Providing Services" to "Services" directory "services"
new section "Use Cases" directory "usecases"

Still to decide:

Rename "Virtualization" (/virtualization/) to "Virtual machines" (/virtual-machines/)
Rename "Containerization" (/containerization/) to "Containers" (/containers/).

linter / vale support

Ticket #234
Ticket #233
No discussion started yet

style issues

Ticket #234
Ticket #233
Ticket #217
No discussion started yet

**This ticket provides a summary of various detailed tickets.** # Summary of the [state of the discussion as at 19 August 2026](https://docs.fedoraproject.org/en-US/server-working-group/wg-minutes-2026/#_wednesday_august_19_2026) We have at least 4 topics / Types of issues to discuss. ## New structure for postinstall Ticket #228 Already agreed: - The current article will be split into a new subdirectory containing several smaller, more focused articles on topics like "Networking," "Storage," "Security hardening," and "Backups." Still to decide: - naming - Alternatives: (1) "post-installation customizations" | (2) "postinstall" | (3) "postinstallation" - contents - Basic steps _Alternatives_: First steps - Network consolidation _Alternatives_: Networking - Storage organisation _Alternatives_: Storage - Fail2ban and other security measures _Alternatives_: Security hardening - Various other brief topics - DNF / Update _Alternatives_: Automatic updates - Organisation of backups _Alternatives_: Backups - position - The new subdir may be the 4th after containerization. ## New structure for navigation bar Ticket #224 Already done: - rename "Providing Services" to "Services" directory "services" - new section "Use Cases" directory "usecases" Still to decide: - Rename "Virtualization" (/virtualization/) to "Virtual machines" (/virtual-machines/) - Rename "Containerization" (/containerization/) to "Containers" (/containers/). ## linter / vale support Ticket #234 Ticket #233 No discussion started yet ## style issues Ticket #234 Ticket #233 Ticket #217 No discussion started yet

pboy added the

meeting

documentation

improvement

labels

2026-09-02 15:14:18 +00:00

pboy added this to the Documentation project

2026-09-02 15:14:26 +00:00

goroboro commented

2026-09-02 15:46:38 +00:00

Member

Another item on postinstall: I merged a recent PR to create boolean values to enable/disable tasks in the role (server/ansible-support#183). I now believe that the boolean variable names should use underscores rather than dashes, as this is more conventional. I might be wrong about this though.
--- Apologies... I noticed that this content item is not about the ansible. So you can probably ignore this comment, unless the ansible gets discussed :)

Another item on postinstall: I merged a recent PR to create boolean values to enable/disable tasks in the role (https://forge.fedoraproject.org/server/ansible-support/pulls/183). I now believe that the boolean variable names should use underscores rather than dashes, as this is more conventional. I might be wrong about this though. --- Apologies... I noticed that this content item is not about the ansible. So you can probably ignore this comment, unless the ansible gets discussed :)

brettweir commented

2026-09-03 00:17:00 +00:00

Member

@goroboro wrote in #261 (comment):

Another item on postinstall: I merged a recent PR to create boolean values to enable/disable tasks in the role (server/ansible-support#183). I now believe that the boolean variable names should use underscores rather than dashes, as this is more conventional. I might be wrong about this though. --- Apologies... I noticed that this content item is not about the ansible. So you can probably ignore this comment, unless the ansible gets discussed :)

You are right, they should be underscores! 🙂

@goroboro wrote in https://forge.fedoraproject.org/server/tickets/issues/261#issuecomment-1352654: > Another item on postinstall: I merged a recent PR to create boolean values to enable/disable tasks in the role (server/ansible-support#183). I now believe that the boolean variable names should use underscores rather than dashes, as this is more conventional. I might be wrong about this though. --- Apologies... I noticed that this content item is not about the ansible. So you can probably ignore this comment, unless the ansible gets discussed :) You are right, they should be underscores! 🙂

eseyman commented

2026-09-03 06:38:53 +00:00

Member

You are right, they should be underscores!

I'm working on this.

> You are right, they should be underscores! I'm working on this.

pboy commented

2026-09-03 11:00:16 +00:00

Author

Owner

=== Result as of meeting September 02, 2026

The WG agreed to create a new main section titled "Postinstallation Customizations".
This new section will be placed second in the navigation tree, immediately after the "Installation" guide.
There was disagreement on the titles for the subsections within "Postinstallation Customizations" (e.g., "Network consolidation" vs. just "Networking"). The initial agreements were revoked, and a formal vote will be held in the ticket to decide on the final names.
The current top-level navigation bar names, including "Virtualization" and "Containerization", will remain unchanged.
Ticket #224, regarding the main navigation bar structure, was agreed to be closed.

=== Result as of meeting September 02, 2026 * The WG agreed to create a new main section titled **"Postinstallation Customizations"**. * This new section will be placed second in the navigation tree, immediately after the "Installation" guide. * There was disagreement on the titles for the subsections within "Postinstallation Customizations" (e.g., "Network consolidation" vs. just "Networking"). The initial agreements were revoked, and a formal vote will be held in the ticket to decide on the final names. * The current top-level navigation bar names, including "Virtualization" and "Containerization", will remain unchanged. * Ticket #224, regarding the main navigation bar structure, was agreed to be closed.

pboy commented

2026-09-03 22:16:08 +00:00

Author

Owner

On our September 02, 2026 meeting we couldn't agree about the naming of the detail-articles for the new postinstallation section and to start a voting.

The Discussion / Consideration was along

"Self-explanatory titles that are as short as possible but clearly state what the section is about and why it is relevant, and a user should read it" versus "Short and just one Word".
Style consistency across the Server documentation.

The Alternatives are

No.	Alternativ a	Alternative b
1	Basic Steps	First Steps
2	Network Consolidation	Networking
3	Storage Organisation	Storage
4	Security Hardening.	Security
5	Automatic Updates	Updates
6	Backup Organization	Backups

Please, vote 6 times, something like

EXAMPLE:
1 a
2 b
3 -
4 -
5 b
6 a

The voting starts now and is - according to our governance rules - running for 2 weeks.
So it will end: Friday September 18, 2026, 23:59 UTC

On our September 02, 2026 meeting we couldn't agree about the naming of the detail-articles for the new postinstallation section and to start a voting. The Discussion / Consideration was along - "Self-explanatory titles that are as short as possible but clearly state what the section is about and why it is relevant, and a user should read it" versus "Short and just one Word". - Style consistency across the Server documentation. The Alternatives are | No. | Alternativ a | Alternative b | |-----|-----------------------|-----------------| | 1 | Basic Steps | First Steps | | 2 | Network Consolidation | Networking | | 3 | Storage Organisation | Storage | | 4 | Security Hardening. | Security | | 5 |Automatic Updates | Updates | | 6 | Backup Organization | Backups | Please, vote 6 times, something like EXAMPLE: 1 a 2 b 3 - 4 - 5 b 6 a The voting starts now and is - according to our governance rules - running for 2 weeks. So it will end: Friday September 18, 2026, 23:59 UTC

korora commented

2026-09-03 22:24:13 +00:00

Member

B
B
b
b
b
6

We can elaborate in each section as to what is covered in each section, but alternative B provides a good top level overview of what to expect.

1. B 2. B 3. b 4. b 5. b 6. 6 We can elaborate in each section as to what is covered in each section, but alternative B provides a good top level overview of what to expect.

pboy removed the

meeting

label

2026-09-03 22:28:25 +00:00

pboy commented

2026-09-03 22:41:51 +00:00

Author

Owner

My vote now:
1 a
2 a
3 a
4 a
5 a
6 a

My vote now: 1 a 2 a 3 a 4 a 5 a 6 a

goroboro commented

2026-09-04 08:55:42 +00:00

Member

My vote, with consideration that this content is for a set of subsections beneath Postinstallation Customizations which already describes the purpose of these sections:

1 b
2 b
3 b
4 b
5 b - Maybe 'Software Updates'
6 b

My vote, with consideration that this content is for a set of subsections beneath Postinstallation Customizations which already describes the purpose of these sections: 1 b 2 b 3 b 4 b 5 b - Maybe 'Software Updates' 6 b

brettweir commented

2026-09-05 10:15:53 +00:00

Member

I think these naming decisions are being made prematurely, because I believe these names will emerge naturally as the content takes shape and we understand the story we're trying to tell. As of now, that story is still very much up in the air, and by adopting these names now, we constrain where the content can live and how it can be presented.

I've been thinking about this document as a whole almost every day for the past couple of months, and I have so many ideas for it. I also have many questions that I don't think I have a good answer to.

What kind of document is this? Is it a guide? A reference manual? A tutorial? Also, who is this for? Who do we want to read this?

Names like "Storage", "Networking", "Security", etc. all imply top-level headers and don't belong in the Post-installation section. The whole point of the Post-installation section is that there are certain decisions that every system administrator must make that can't be made for them. These steps could have been in Installation but the Installation environment is limited and ephemeral, so you do it after Installation instead.

"Automatic Updates" could just be set up by default, but that trades away some amount of stability and control. Every administrator will deal with DNF. Some administrators will also deal with Flatpak and podman containers, and that's a choice they will make, but this choice happens at different times. If this is a reference manual, the "Automatic Updates" page might document all the knobs for automatic update system-wide, but if this is a guide, it makes no sense to talk about registry updates when you haven't even introduced containers yet.

I think the "Security" section that would live in Postinstallation would more appropriately be called "System Hardening". Far from discussing all possible security considerations, it's a few basic hardening measures that every admin should do that can't be done without some decisions being made. A page called "Security" is more likely a high-level overview of what security features Fedora Server has, like SELinux, stack smashing protection, whatever. Security is a cross-cutting concern like logging and metrics that will appear everywhere and affect everything. We will need to talk about security in many different places.

If we had a page called "Networking", it should live at the top-level and have pages that talk abou how to set up, I dunno, IPsec or VLAN or bridge networking or whatever. If it appears under "Postinstallation", it should probably be "Basic Networking" and breeze through setting up your hostname, Ethernet or Wi-Fi. Any more than that is way out of scope.

But even that, I don't think is granular enough. I thought the pages here would be called "Set up a hostname", "Set up Ethernet networking", "Disallow root login", "Configure firewall", exactly what the things are, and express a simple intent, because "Postinstallation" is inherently a start-to-finish tutorial/guide, and should be hyper-focused on these early setup tasks.

I also think we need to choose shorter names for things across the board. Who is our audience? It's definitely not seasoned Linux admins who know this stuff backwards and forwards. Why would they even bother to look at our docs when they can read the man page for firewall-cmd? Or just read the kernel source?

The audience that I am writing for is people who are new to server administration, and are looking for an easy, flexible and understandable way to serve applications for themselves, their community, or their small businesses. This is NOT a career admin. This is someone who has no idea what any of this is and is relying on us to lead them down a path to success. That means smaller words, concise explanations, shorter sections, and assurance that they're on the right track. If I'm not writing to that audience, then I can't serve the audience that I'm here to serve.

My vote is that we need to spend a lot more time thinking about what we want this document to be before we start making permanent naming decisions. As presented, I'm not sure how to respond.

I think these naming decisions are being made prematurely, because I believe these names will emerge naturally as the content takes shape and we understand the story we're trying to tell. As of now, that story is still very much up in the air, and by adopting these names now, we constrain where the content can live and how it can be presented. I've been thinking about this document as a whole almost every day for the past couple of months, and I have so many ideas for it. I also have many questions that I don't think I have a good answer to. What kind of document is this? Is it a guide? A reference manual? A tutorial? Also, who is this for? Who do we want to read this? Names like "Storage", "Networking", "Security", etc. all imply top-level headers and don't belong in the Post-installation section. The whole point of the Post-installation section is that there are certain decisions that every system administrator must make that can't be made for them. These steps could have been in Installation but the Installation environment is limited and ephemeral, so you do it after Installation instead. "Automatic Updates" could just be set up by default, but that trades away some amount of stability and control. Every administrator will deal with DNF. Some administrators will also deal with Flatpak and podman containers, and that's a choice they will make, but this choice happens at different times. If this is a reference manual, the "Automatic Updates" page might document all the knobs for automatic update system-wide, but if this is a guide, it makes no sense to talk about registry updates when you haven't even introduced containers yet. I think the "Security" section that would live in Postinstallation would more appropriately be called "System Hardening". Far from discussing all possible security considerations, it's a few basic hardening measures that every admin should do that can't be done without some decisions being made. A page called "Security" is more likely a high-level overview of what security features Fedora Server has, like SELinux, stack smashing protection, whatever. Security is a cross-cutting concern like logging and metrics that will appear everywhere and affect everything. We will need to talk about security in many different places. If we had a page called "Networking", it should live at the top-level and have pages that talk abou how to set up, I dunno, IPsec or VLAN or bridge networking or whatever. If it appears under "Postinstallation", it should probably be "Basic Networking" and breeze through setting up your hostname, Ethernet or Wi-Fi. Any more than that is way out of scope. But even that, I don't think is granular enough. I thought the pages here would be called "Set up a hostname", "Set up Ethernet networking", "Disallow root login", "Configure firewall", exactly what the things are, and express a simple intent, because "Postinstallation" is inherently a start-to-finish tutorial/guide, and should be hyper-focused on these early setup tasks. I also think we need to choose shorter names for things across the board. Who is our audience? It's definitely not seasoned Linux admins who know this stuff backwards and forwards. Why would they even bother to look at our docs when they can read the man page for firewall-cmd? Or just read the kernel source? The audience that I am writing for is people who are new to server administration, and are looking for an easy, flexible and understandable way to serve applications for themselves, their community, or their small businesses. This is NOT a career admin. This is someone who has no idea what any of this is and is relying on us to lead them down a path to success. That means smaller words, concise explanations, shorter sections, and assurance that they're on the right track. If I'm not writing to that audience, then I can't serve the audience that I'm here to serve. My vote is that we need to spend a lot more time thinking about what we want this document to be before we start making permanent naming decisions. As presented, I'm not sure how to respond.

pboy commented

2026-09-09 14:51:05 +00:00

Author

Owner

@brettweir very good ideas and considerations!

pboy commented

2026-09-09 18:23:56 +00:00

Author

Owner

A summary of our discussion at meeting Sep 09, 2026:

Topic 5: Server Documentation Revision

The working group agreed to create a new documentation section titled "Postinstallation customizations" with a shorter URL slug (e.g., /postinstallation/).
The existing post-installation article will be moved into this new section and then gradually split into smaller, more focused articles.
The new Ansible documentation will likely be placed under the "Administration" section.

Action items:

pboy: to create the new postinstallation section in the Fedora Server documentation.

A summary of our discussion at meeting Sep 09, 2026: #### Topic 5: Server Documentation Revision - The working group agreed to create a new documentation section titled "Postinstallation customizations" with a shorter URL slug (e.g., /postinstallation/). - The existing post-installation article will be moved into this new section and then gradually split into smaller, more focused articles. - The new Ansible documentation will likely be placed under the "Administration" section. ##### Action items: - pboy: to create the new postinstallation section in the Fedora Server documentation.

Rows
Columns

Revision of the Fedora Server documentation #261

Summary of the state of the discussion as at 19 August 2026

New structure for postinstall

New structure for navigation bar

linter / vale support

style issues

Topic 5: Server Documentation Revision

Action items: