Hi @rlengland,
after a long delay I've finally gotten around to writing the second article. You can find the preview here: https://fedoramagazine.org/?p=36919&preview=true&preview_id=36919

I'm fairly happy with the contents at this point. The only thing that needs more attention from my PoV is citations and the references to external documents (Btrfs docs, Btrfs wiki, etc). I'll try to handle that in the next few days, but the contents are there already.

I'm looking forward to your feedback already!

This LGTM as far as the technical details. But I'm not really a Btrfs guru. We'll want to tweak a few grammer things during editing (Silverblue -> Fedora Silverblue, Fedora 36 -> Fedora Linux 36, etc.).

I guess we are mainly waiting on Part 1 to be finalized before publishing this one.

@glb Alright, I tried to address the grammar-related issues, I hope it's ok now?

Do you think there's something like a code block that has numbered lines? I noticed that the output of /etc/fstab may easily wrap on smaller monitors, making it impossible to follow the explanations about the column numbers. I couldn't find an appropriate block, though.

I'm not aware of a numbered code block. I think you might be able to craft something like that if you, e.g., add your own numbers along the left of the pre-formatted block. You might be able to surround the numbers with <span> elements and set a different colored background to make it clear that they aren't part of the file. Or use <ol> so the numbers won't copy-and-paste with the text. I'm not sure what would work best. Unfortunately, I don't thing there is anything formal that can be used with the current theme.

I'm not aware of a numbered code block. I think you might be able to craft something like that if you, e.g., add your own numbers along the left of the pre-formatted block. You might be able to surround the numbers with <span> elements and set a different colored background to make it clear that they aren't part of the file. Or use <ol> so the numbers won't copy-and-paste with the text. I'm not sure what would work best. Unfortunately, I don't thing there is anything formal that can be used with the current theme.

Perhaps a warning/caution that the text may wrap could be included before with each of the pre-formatted blocks. It might help alleviate confusion.

I went over the full article today and verified that all of the commands work in a fresh F36 Workstation VM. I also updated the shown command outputs.

In the preview I noticed two things:

1. The Code block type actually doesn't wrap lines in the Preview, only when editing it, which is great!
2. Somehow the formatting of all my Code blocks has gone bad. They have a weird frame around them, and in the lower half of the article some italicized text is broken, too... Have you seen something like that before? I have no idea what to do about it.

@hartan Tips for article style... indicates that "Pre-formatted" style should be used for command line input/output examples.
I believe that italicized text isn't supported in the "code" style so that would explain the text difference. As for the frame, I suspect that is a code vs pre-formatted difference, as well. You might consider making the italicized text bold to emphasize it.

@glb is more conversant with WP formatting than I am so he may have more input.

Do you have an update on this article @hartan ? Looks like it is close...(?)

@hartan do you have a new status on this article? is it ready for the editors to review?

@rlengland Thanks for the tips! I've changed all code blocks to preformatted and added a note at the beginning of the text regarding line wrapping. Unfortunately, preformatted blocks wrap lines running out of the box, so we'll see how readers accept this "solution".

I consider the article ready for review!

@chrismurphy I greatly appreciated your remarks on the last article. Would you mind giving this one a proof-read with respect to the technical details, too?

@chrismurphy Now would be a good time to chip in with your observations, if you have the bandwidth. :wink: