Codeberg/Documentation
42
199
Fork
You've already forked Documentation
161

Proposing: A style guide #216

Closed
opened 2022年04月10日 10:42:21 +02:00 by jklippel · 5 comments
Contributor
Copy link

I am new to codeberg and this documentation. I am not sure whether this is the right place to raise this discussion.
If it is not, please feel free to move it or point me to the correct place.

Is there a style guide of some sort for the documentation?

I just edited an article yesterday and consistently used the word Email all the time, in favour of eMail, email or e-mail.

I just (by chance) saw @ka2in in !215 using " and " instead of quotes (") and using the lower case email.
(No offence @ka2in, just a good example for something that could be added to a style guide of some sort. I am in favour of using " and " and email, too.)

It would be good to have a clear guide on how to use quotes and how to spell email. I am sure there are other things that can be documented as well, like whether to use rendering hints when using triple backticks shell or not .

I found https://docs.codeberg.org/improving-codeberg/docs-contributor-faq/ but it does not say anything about quotes or about how to write certain words. There is also !59 on a general markdown documentation but that would a bit different to a style guide.

Anyway I would favor such a document in which these and other cases are documented.

I would also favour a whole section "Documentation". The current docs-contributor-faq is somewhat huge and could be easily split into smaller documents (How to write an article, How to create a screenshot, etc.) (Maybe thats something for a different issue?)

Don't get me wrong, I do not want a new law, just a guide for new people like me who want to improve the documentation and want to do so in a way consistent with what others already did.

What do you think?

I am new to codeberg and this documentation. I am not sure whether this is the right place to raise this discussion. If it is not, please feel free to move it or point me to the correct place. Is there a style guide of some sort for the documentation? I just edited an article yesterday and consistently used the word Email all the time, in favour of eMail, email or e-mail. I just (by chance) saw @ka2in in !215 using “ and ” instead of quotes (") and using the lower case email. (No offence @ka2in, just a good example for something that could be added to a style guide of some sort. I am in favour of using “ and ” and email, too.) It would be good to have a clear guide on how to use quotes and how to spell email. I am sure there are other things that can be documented as well, like whether to use rendering hints when using triple backticks ` ` `shell or not ` ` `. I found https://docs.codeberg.org/improving-codeberg/docs-contributor-faq/ but it does not say anything about quotes or about how to write certain words. There is also !59 on a general markdown documentation but that would a bit different to a style guide. Anyway I would favor such a document in which these and other cases are documented. I would also favour a whole section "Documentation". The current docs-contributor-faq is somewhat huge and could be easily split into smaller documents (How to write an article, How to create a screenshot, etc.) (Maybe thats something for a different issue?) Don't get me wrong, I do not want a new law, just a guide for new people like me who want to improve the documentation and want to do so in a way consistent with what others already did. What do you think?
Contributor
Copy link

@jklippel: I agree, one major advantage of having a style guide is that it helps to streamline the authoring process.

Besides, the reader should not get the impression that different contributors were involved in the documentation process.

A consistent style helps to make the reading experience more enjoyable. We could include guidelines regarding the use of active vs. passive voice, the use of quotes, sentence length, etc.

@jklippel: I agree, one major advantage of having a style guide is that it helps to streamline the authoring process. Besides, the reader should not get the impression that different contributors were involved in the documentation process. A consistent style helps to make the reading experience more enjoyable. We could include guidelines regarding the use of active vs. passive voice, the use of quotes, sentence length, etc.
Contributor
Copy link

@jklippel I've just submitted a style guide for documentation contributors under #215. Having a glossary with "reserved" terms would be the next step. The goal is to prevent contributos from using different terms to designate the same concept, e.g. "versioning system" vs. "version control system".

@jklippel I've just submitted a style guide for documentation contributors under [#215](https://codeberg.org/Codeberg/Documentation/pulls/215/files). Having a glossary with “reserved” terms would be the next step. The goal is to prevent contributos from using different terms to designate the same concept, e.g. “versioning system” vs. “version control system”.
Author
Contributor
Copy link

@ka2in Thanks for the ping. I think you should raise a pull request for the style guide here. I added a more detailed answer to #215.

@ka2in Thanks for the ping. I think you should raise a pull request for the style guide here. I added a more detailed answer to #215.
Contributor
Copy link

Thanks. Separate pull request raised under #223.

Thanks. Separate pull request raised under [#223](https://codeberg.org/Codeberg/Documentation/pulls/223/files).
Author
Contributor
Copy link

After #223 was merged, there now exists a first version of a styleguide: https://docs.codeberg.org/improving-codeberg/style-guide/

That was the original intent of this issue. I will close this issue now.
Other issues can be opened to improve the style-guide in the future.

After #223 was merged, there now exists a first version of a styleguide: https://docs.codeberg.org/improving-codeberg/style-guide/ That was the original intent of this issue. I will close this issue now. Other issues can be opened to improve the style-guide in the future.
Sign in to join this conversation.
No Branch/Tag specified
main
renovate/major-cspell-monorepo
renovate/mstruebing-editorconfig-checker-3.x
renovate/lycheeverse-lychee-0.x
renovate/font-awesome
renovate/prettier-3.x
renovate/markdownlint-cli2-0.x
renovate/markdown-it-14.x
renovate/davidanson-markdownlint-cli2-0.x
renovate/pipelinecomponents-yamllint-0.x
renovate/11ty-eleventy-3.x
renovate/node-lts-slim
renovate/npm-pnpm-vulnerability
ci_pr_close_no_preview
pr-554
pr/554
gitea-icons-shortcode
No results found.
Labels
Clear labels
Codeberg Pages
Issues affecting Codeberg Pages
Documentation Usability
Issues related to using and reading docs.codeberg.org
Forgejo
Good First Issue! 👋
Kind: Bug
Kind: Documentation
Kind: Enhancement
Kind: Feature
Kind: Question
Kind: Security
Licensing
Part: Generator
This is related to the generation of the documentation, not to the content itself
Priority: High
The priority is high
Priority: Low
The priority is low
Priority: Medium
The priority is medium
Reviewed: Confirmed
Something has been confirmed
Reviewed: Duplicate
Something exists already
Reviewed: Invalid
Something was marked as invalid
Reviewed: Wontfix
Something won't be fixed
Status: Blocked
Status: Help wanted
Contributions are welcome!
Status: In progress
Work is in progress
Status: Needs feedback
Feedback is needed
Status: Ready for Review
Work is completed
Status: Review
Review is in progress / Reviewers wanted
Status: Stale
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Codeberg/Documentation#216
Reference in a new issue
Codeberg/Documentation
No description provided.
Delete branch "%!s()"

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?