Style Guide #223
ka2in/Documentation:branch2 into main The proposed style guide is a starting point. Feel free to adjust, extend, and modify according to the community's needs.
@ka2in: That is a great remark. Should we add it to the start of the document?
Maybe slightly adapted like:
"The proposed style guide is a starting point. Feel free to create an issue, open a Pull Request, and modify it according to the community's needs."
Sorry for the late review, and thank you very much.
TBH, I think we should try to point out that you should still try to contribute to the docs, even if you don't know if you can fully fulfill the styleguide. This is kinda overwhelming when you "just wanted to write some sentences about x", and might turn off potential contributors.
@ -0,0 +81,4 @@
Use the following format for dates in running text: **dd MMMM yyyy**, e.g. 15 March 2022.
Use the following "short" format for dates outside the running text: **dd.mm.yyyy**, e.g. 9.3.2022.
I propose to use the same example date
Done.
@ -0,0 +104,4 @@
|:------------------------------------|:---------------------------------------------------------------------------------------------------|
| 6.20 p.m | 18.20 |
| 12 | 12.00 |
| 09.03.2022 | 9.3.2022 |
Since this is repetitive, maybe merge the two sections (Time and date) with the no-leading-zero section
Done.
@ -0,0 +145,4 @@
## Document structure
If you write an excessively long article, your readers might get lost on the way. Break your article down in smaller parts for a better reading experience.
Just for clarification: Does that mean to add more subheadings in the article itself, or create multiple articles?
I mean breaking the article down into smaller articles, and readjusting the document structure, not only adding more subheadings.
Thank you for reviewing the PR!
A style guide is meant to be used as a reference when there's a doubt about something specific. It's not a novel that we must read from A to Z.
If somebody comes here and wants to know how to format date and numbers, he can check the relevant section immediately. Think of it as a set of recommendations to avoid time-consuming discussions about grammar, typography, and layout aspects.
In an ideal world, the reviewer is the person that must be in charge of enforcing the guidelines provided in the style guide.
A style guide is meant to be used as a reference when there's a doubt about something specific. It's not a novel that we must read from A to Z.
If somebody comes here and wants to know how to format date and numbers, he can check the relevant section immediately. Think of it as a set of recommendations to avoid time-consuming discussions about grammar, typography, and layout aspects.
In an ideal world, the reviewer is the person that must be in charge of enforcing the guidelines provided in the style guide.
Great explanation. Would you mind adapting it a little to be more generic and then adding it to the introduction?
Explanation added to the introduction.
This was open for quite a while and all review remarks addressed as far as I could see.
Thank you @ka2in
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?