FYI, since I’ve had my hand in a lot of the QoS documentation over the years, I’ve been wanting to give it a thorough update, as it is a jumbled mess with a mixture of old and current info as well as repeated info, typos and grammar issues. I printed the documentation to paper so I can more easily mark it up, then will update in a word processor before pasting the finished result back online. Any issues with me doing this rather than smaller incremental changes?
11 Likes
Thank you!
whatever works better for you!
2 Likes
Hi Tim and Jon,
I’ve been thinking about this as well.
Would it be possible to create a staging area for the new wiki entries? This could be used to refine any large amendments before merging them into the main documentation. Normally, this wouldn’t be much of an issue, but since Tim mentioned he’s chopping things up and editing in bulk, it might be helpful to keep it separate from the main documentation until it’s fully refined. We could create a page like Quality_of_Service_Staging to collaborate, review, and polish the updates, and then rename it to Quality_of_Service once it’s ready to replace the original.
Do you think this approach would be feasible, @jon?
Thanks,
A G
1 Like
Adam’s idea of a staging area is IMO a good compromise.
For revision a step by step approach is adequate, but I understand Tim’s way to rewrite as a whole.
The staging area allows to do the step by step work on the draft, without disturbing the documentation.
2 Likes
I like the idea of a staging area, or something similar. I am mostly done with the page and it is living in a .ODT document at the moment. I have kept as much of the existing text as possible, just reorganized where on the document it lives, fixed grammar and spelling, and reworded some areas for clarity. Also removed redundant text and some info that is not directly related to setting up QoS. IMO it is a huge improvement. But it would be nice for someone else to fact-check it before it goes live.
The other option is just make it live and have any editing done afterword. We can always retrieve something from a previous rev through the versioning system.
2 Likes
It is so difficult to get people to update the wiki I prefer to make it as easy as possible. The QoS wiki page is the perfect example of a page that needs big help. So I am very happy Tim is taking the time to make it right!
I did a “_playground” or “_draft” wikis in the past. So doing a staging area is perfect!
Again, thank you Tim!
You can tell by the OP likes that many people agree!
4 Likes
Thanks, @jon . So should I just update the page when I get done, if not, I’ll need direction on how to use this “staging area.”
1 Like
click here:
https://www.ipfire.org/docs/configuration/services/qos_staging
click Create Now.
Type away! (or cut and paste away)
Do you know Markdown?
3 Likes
I don’t know Markdown well, but I’ve been able to fake my way through it before by observing and copying existing formatting. 
It shouldn’t be a problem. Thanks!
1 Like
Does the preview section below not live update? I have the text pasted so people are welcome to review it. But as I’m formatting (eg. bolding paragraph headings) I’m not seeing the changes happen live. I don’t want to have to Update and give a reason for the update more often than necessary.
1 Like
Unlike the community forum, the wiki doesn’t have a live preview feature.
Although you could either use a blank forum post to draft it within, or you could use something like StackEdit which has a live preview feature.
Hope this helps.
Thanks,
A G
Yes, you can see the effect of your changes in the preview section below but it is not 100% key press by key press.
I find that most of the time if I want to see the effects of my changes if I press the Enter key to get a new line it then updates the preview section below. I can then view it and always go back and delete the unwanted new line.
It may not be the most correct approach but it works for me to preview the changes before committing them.
2 Likes
Thanks, guys. Looks like formatting may take longer than the rewrite did. Maybe before I go through all that, some of you can read through the content and make sure it is in line with what the community wants. Fact-check, content, typos, grammar, organization. I have gone through three editing revisions with paper and pencil before pasting this up. Make sure I didn’t miss anything obvious. Thanks in advance.
.” CAKE is used throughout IPFire to prevent interface congestion even if QoS is not enabled.
Isn’t it fq_Codel?
1 Like
I can help with the formatting, etc… I do not use QoS so the technical is for the more qualified
1 Like
That line is in the first paragraph talking about CU163-CU187. Next paragraph talks about what it is from CU188 onward.
1 Like
I actually printed out the formatting to paper from the original QoS document, and am using that as a reference to format the staging version. So I think I got it! I’ll let you know if I need help.
I am considering removing the IMQ Device section (just under the Introduction) as it may be too much info for someone just looking to set up QoS. I’ll leave it in there for the moment, but if there’s no compelling argument to leave it in the next couple of days, I’ll nuke it. I’ve already shortened the document by about a page in LibreOffice and am not opposed to shortening it even more. FYI, I know there is some repeat info in the TIPS section, but I figured if someone is just scanning for quick help and not reading every word, the TIPS section is where they are most likely to land their eyes.
I am not familiar at all with QoS as I don’t use it. However I would suggest moving it to an advanced section rather than getting rid of it completely.
From your description it is too detailed or complicated for new users but it might still be of use for advanced users, so shouldn’t be lost.
I think it should be retained.
The virtual IMQ device is a construct not known by the ‘standard’ user.
We think in combined RX/TX devices red0, green0, …
But the QOS function shapes one direction of red0 only, the other direction is delegated to imq0.
2 Likes
The document and formatting are complete. IMQ stays. Thanks @bbitsch
Please look it over and edit as needed before we make it live.
Thanks for all your input, everyone.
2 Likes