Contributing

Code Quality

A new release can happen at any time from th' main branch o' th' GitHub project without further accknowledgment. This makes it necessary that, every pushed set o' changesets into th' main branch must be self-contained an' correct, result'n 'n a releas'ble version.

Stay simple fer th' user by focus'n on th' mantra “convent'n over configuration”.

At installat'n th' ship should work reason'ble without (m)any configurat'n.

Stay close t' th' Cap'n Hugo way.

Don’t use npm or any preprocess'n, our contributors may not be front-end developers.

Document new features 'n th' exampleSite. This also contains entries t' th' What’s new plank.

Don’t break exist'n features if ye don’t have t'.

Remove reported issue from th' browser’s console.

Check fer unnecessary whitespace an' correct indent'n o' yer result'n HTML.

Be compat'ble t' IE11, at least fer main functionality, this means:

  • test 'n IE11
  • check caniuse.com
  • don’t use JavaScript arrow funct'ns
  • don’t use JavaScript template literals
  • don’t use other fancy JavaScript ES5/6 stuff

Conventional Commits

Write commit messages 'n th' conventional commit format.

Follow'n be an impomplete list o' some o' th' used conventional commit types. Be creative.

Common Feature Structure Shorrrtcodes
build a11y favicon attachments
browser archetypes search badge
chore alias menu button
docs generator history children
shorrrtcodes i18n scrollbar expand
theme mobile nav ay'con
print toc include
rss clipboard math
variant syntaxhighlight mermaid
boxes notice
piratify
siteparam
swagger
tabs