docs: move exampleSite to docs

This commit is contained in:
Sören Weber 2025-01-29 23:30:53 +01:00
parent df03dac58f
commit db9ca5d295
No known key found for this signature in database
GPG key ID: BEC6D55545451B6D
827 changed files with 656 additions and 652 deletions

View file

@ -0,0 +1,12 @@
+++
categories = ["reference"]
menuPre = "<i class='fa-fw fas fa-code-pull-request'></i> "
hidden = true
title = "Development"
type = "chapter"
weight = 5
+++
This chapter contains information only needed for development and maintaining the theme.
{{%children containerstyle="div" style="h2" description="true" %}}

View file

@ -0,0 +1,9 @@
+++
categories = ["reference"]
menuPre = "<i class='fa-fw fas fa-code-pull-request'></i> "
hidden = true
title = "Development"
type = "chapter"
weight = 5
+++
{{< piratify >}}

View file

@ -0,0 +1,48 @@
+++
categories = ["explanation"]
description = "What to know if you want to contribute"
title = "Contributing"
+++
## Code Quality
A new release can happen at any time from the `main` branch of the [GitHub project](https://github.com/McShelby/hugo-theme-relearn) without further acknowledgment. This makes it necessary that, every pushed set of changesets into the `main` branch **must** be self-contained and correct, resulting in a releasable version.
Stay simple for the user by focusing on the mantra "convention over configuration".
At installation the site should work reasonable without (m)any configuration.
Stay close to the Hugo way.
Don't use npm or any preprocessing, our contributors may not be front-end developers.
Document new features in the docs. This also contains entries to the [What's new](introduction/releasenotes) page.
Don't break existing features if you don't have to.
Remove reported issue from the browser's console.
Check for unnecessary whitespace and correct indention of your resulting HTML.
## Conventional Commits
Write commit messages in the [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) format.
Following is an inpomplete list of some of the used conventional commit types. Be creative.
| Common | Feature | Structure | Shortcodes |
|------------|------------|-----------------|-------------|
| build | a11y | favicon | attachments |
| browser | archetypes | search | badge |
| chore | alias | menu | button |
| docs | generator | history | children |
| shortcodes | i18n | scrollbar | expand |
| theme | mobile | nav | icon |
| | print | toc | include |
| | rss | clipboard | math |
| | variant | syntaxhighlight | mermaid |
| | | boxes | notice |
| | | | openapi |
| | | | piratify |
| | | | siteparam |
| | | | tabs |

View file

@ -0,0 +1,6 @@
+++
categories = ["explanation"]
description = "What to know if you want to contribute"
title = "Contributing"
+++
{{< piratify >}}

View file

@ -0,0 +1,137 @@
+++
categories = ["explanation", "howto"]
description = "What to know as a maintainer"
title = "Maintaining"
+++
## Semver
This project tries to follow the [semver policy](https://semver.org/) - although not followed 100% in the past.
Usually an entry of {{% badge style="warning" title=" " %}}Breaking{{% /badge %}} on the [What's new](introduction/releasenotes) page causes a new major release number.
All other entries on the [What's new](introduction/releasenotes) page will increase the minor release number.
Releases resulting in a new major or minor number are called main release.
Releases containing bugfixes only, are only increasing the patch release number. Those releases don't result in announcements on the [What's new](introduction/releasenotes) page.
Entries on the [What's new](introduction/releasenotes) page are checked and enforced during the `version-release` GitHub Action.
## Managing Issues
Issues are categorized and managed by assigning [labels](#labels) to it.
Once working on an issue, assign it to a fitting maintainer.
When done, close the ticket. Once an issue is closed, it needs to be assigned to next release milestone.
A once released ticket is not allowed to be reopened and rereleased in a different milestone. This would cause the changelog to be changed even for the milestone the issue was previously released in. Instead write a new ticket.
## Managing Pull Requests
If a PR is merged and closed it needs an accompanied issue assigned to. If there is no issue for a PR, the maintainer needs to create one.
You can assign multiple PRs to one issue as long as they belong together.
Usually set the same labels and milestone for the PR as for the accompanied issue.
## Labels
### Kind
An issue that results in changesets must have exactly one of the following labels. This needs to be assigned latest before release.
| Label | Description | Changelog section |
|----------------------------------------------------------|--------------------------------------------|-------------------|
| {{% badge color="#5498d8" %}}documentation{{% /badge %}} | Improvements or additions to documentation | - |
| {{% badge color="#99d856" %}}discussion{{% /badge %}} | This issue was converted to a discussion | - |
| {{% badge color="#d8d104" %}}task{{% /badge %}} | Maintenance work | Maintenance |
| {{% badge color="#d8ae04" %}}feature{{% /badge %}} | New feature or request | Features |
| {{% badge color="#d88704" %}}bug{{% /badge %}} | Something isn't working | Fixes |
### Impact
If the issue would cause a new main release due to [semver semantics](#semver) it needs one of the according labels and the matching badge on the [What's new](introduction/releasenotes) page.
| Label | Description |
|-----------------------------------------------------|---------------------------------------------------------|
| {{% badge color="#d73a4a" %}}change{{% /badge %}} | Introduces changes with existing installations |
| {{% badge color="#d73a4a" %}}breaking{{% /badge %}} | Introduces breaking changes with existing installations |
### Declination
If an issue does not result in changesets but is closed anyways, it must have exactly one of the following labels.
| Label | Description |
|-------------------------------------------------------|-------------------------------------------
| {{% badge color="#9fa2a5" %}}duplicate{{% /badge %}} | This issue or pull request already exists |
| {{% badge color="#9fa2a5" %}}invalid{{% /badge %}} | This doesn't seem right |
| {{% badge color="#9fa2a5" %}}support{{% /badge %}} | Request for achieving a special goal |
| {{% badge color="#9fa2a5" %}}unresolved{{% /badge %}} | No progress on this issue |
| {{% badge color="#9fa2a5" %}}update{{% /badge %}} | A change in behavior after updat |
| {{% badge color="#9fa2a5" %}}wontchange{{% /badge %}} | This will not be worked on |
### Halt
You can assign one further label out of the following list to signal readers that development on an open issue is currently halted for different reasons.
| Label | Description |
|----------------------------------------------------------|---------------------------------------------------------|
| {{% badge color="#998f6b" %}}blocked{{% /badge %}} | Depends on other issue to be fixed first |
| {{% badge color="#998f6b" %}}idea{{% /badge %}} | A valuable idea that's currently not worked on |
| {{% badge color="#998f6b" %}}undecided{{% /badge %}} | No decision was made yet |
| {{% badge color="#6426ff" %}}helpwanted{{% /badge %}} | Great idea, send in a PR |
| {{% badge color="#6426ff" %}}needsfeedback{{% /badge %}} | Further information is needed |
### 3rd-Party
If the issue is not caused by a programming error in the themes own code, you can label the causing program or library.
| Label | Description |
|-----------------------------------------------------|-------------------------------------------------------------|
| {{% badge color="#e550a7" %}}asciidoc{{% /badge %}} | This is a topic related to processing of AsciiDoc |
| {{% badge color="#e550a7" %}}browser{{% /badge %}} | This is a topic related to the browser but not the theme |
| {{% badge color="#e550a7" %}}device{{% /badge %}} | This is a topic related to a certain device |
| {{% badge color="#e550a7" %}}hugo{{% /badge %}} | This is a topic related to Hugo itself but not the theme |
| {{% badge color="#e550a7" %}}mermaid{{% /badge %}} | This is a topic related to Mermaid itself but not the theme |
## Setting Up a Development Environment
Git Hooks are used to automate some tasks. They are stored in the `.githooks` root folder.
Documentation for each hook is contained in each file.
At least the `pre-commit` hook is required, as it updates the version number on each commit. This helps to help debugging of user related issues.
## Making Releases
A release is based on a milestone named like the release itself - just the version number, eg: `1.2.3`. It's in the maintainers responsibility to check [semver semantics](#semver) of the milestone's name prior to release and change it if necessary.
Making releases is automated by the `version-release` GitHub Action. It requires the version number of the milestone that should be released. The release will be created from the `main` branch of the repository.
Treat released milestones as immutable. Don't rerelease an already released milestone. An already released milestone may already been consumed by your users.
During execution of the action a few things are checked. If a check fails the action fails, resulting in no new release. You can correct the errors afterwards and rerun the action.
The following checks will be enforced
- the milestone exists
- there is at least one closed issue assigned to the milestone
- all assigned issues for this milestone are closed
- if it's a main release, there must be an accompanying releasenotes file present in the repo at `introduction/releasenotes/<major>/<minor>.en.md`
After a successful run of the action
- the changelog at `introduction/changelog/<major>/<minor>/<patch>.<lang>.md` is created for english and piratish, including missing generic upper level files
- the `CHANGELOG.md` is updated
- the releasenotes at `introduction/releasenotes/<major>/<minor>.en.md` are updated, including release version and release date
- missing generic upper level files for english and piratish are created
- the version number for the `<meta generator>` is updated
- the updated files are committed
- the milestone is closed
- the repository is tagged with the version number (eg. `1.2.3`), the main version number (eg. `1.2.x`) and the major version number (eg. `1.x`)
- a new entry in the [GitHub release list](https://github.com/McShelby/hugo-theme-relearn/releases) with the according changelog will be created
- the [official documentation](https://mcshelby.github.io/hugo-theme-relearn/) is built and deployed
- the version number for the `<meta generator>` is updated to a temporary and committed (this helps to determine if users are running directly on the main branch or are using releases)
- a new milestone for the next patch release is created (this can later be renamed to a main release if necessary)

View file

@ -0,0 +1,6 @@
+++
categories = ["explanation", "howto"]
description = "What to know as a maintainer"
title = "Maintaining"
+++
{{< piratify >}}

View file

@ -0,0 +1,84 @@
+++
categories = ["explanation", "howto"]
description = "Recipe to create various documentation screenshots"
title = "Screenshots"
+++
Sometimes screenshots need to be redone. This page explains how to create the different screenshots, tools and settings
## Common
**Creation**:
- Use English translation
- Empty search
- Remove history checkmarks but leave it on the page thats used for the screenshot
- After resize of the page into the required resolution, reload the page to have all scrollbars in default loading position
## Demo Screenshot
**Content**:
A meaningful full-screen screenshot of an interesting page.
The content should be:
- timeless: not showing any dates or often edited content
- interesting: show a bunch of interesting elements like headings, code, etc
- balanced: no cluttering with overpresent elements or coloring
- aligned: aligned outlines
**Used by**:
- Hugo Themes info: https://themes.gohugo.io/themes/hugo-theme-relearn/ _1000 x 1500 @ 1_ (`images/screenshot.png`)
- Hugo Themes gallery: https://themes.gohugo.io/tags/docs/ _900 x 600_ @ 1 (`images/tn.png`)
**Page URL**: [Screenshot Link](shortcodes/notice)
**Creation**:
- save as `images/screenshot.png`
- from original screenshot, scale to _900 x 600_ and save as `images/tn.png`
**Remarks**:
The locations are mandatory due to Hugo's theme site builder.
**Preview** `images/screenshot.png`:
![Screenshot](/images/screenshot.png?width=50%25&height=50%25)
**Preview** `images/tn.png`:
![tn](/images/tn.png?width=50%25&height=50%25)
## Hero Image
**Content**:
Show the [Demo Screenshot](#demo-screenshot) page on different devices and different themes. Composition of the different device screenshots into a template.
The content should be:
- consistent: always use the same page for all devices
- pleasing: use a delightful background
**Used by**:
- Hugo Themes notes: https://themes.gohugo.io/themes/hugo-theme-relearn/ _1280 x 640_
- GitHub project site: https://github.com/McShelby/hugo-theme-relearn _1280 x 640_
- GitHub social media preview: https://github.com/McShelby/hugo-theme-relearn/settings _1280 x 640_
**Page URL**: [Hero Image Link](shortcodes/notice)
**Creation**:
- Template: http://www.pixeden.com/psd-web-elements/psd-screen-web-showcase
- Desktop: light theme _1440 x 900 @ 1_
- Tablet: light theme _778 x 1038 @ 1_
- Phone: dark theme _450 x 801 @ .666_
- From original template resize to _3000 x 1500_ offset y: _-330_, scale to _1280 x 640_ and save as `images/hero.png`
**Preview** `images/hero.png`:
![Hero](/images/hero.png?width=50%25&height=50%25)

View file

@ -0,0 +1,6 @@
+++
categories = ["explanation", "howto"]
description = "Recipe t' create various documentat'n scrrreenshots"
title = "Scrrrenshots"
+++
{{< piratify >}}