Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Make a contribution guide

Ouverte
#34 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Documentation
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
html, javascript, jekyll, ruby
Domaine
documentation

Piste de recherche

Commencez par examiner _config.yml ainsi que les répertoires _layouts, _sections et _wiki, puis consultez la documentation Jekyll liée. Le guide de contribution doit expliquer la structure du dépôt, la gestion des images, les références aux fichiers, les layouts, les navigateurs pris en charge et les fallbacks JavaScript, comme indiqué dans l’issue.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement meta

Should cover things like:

  • Image optimization BEFORE commit
    • https://imageoptim.com/versions.html or similar
    • This is to avoid making a git clone be needlessly large. Committing one version and then later committing an optimized version still ends up with both versions in the git repo. Rewrite your commits to fix this (git rebase -i origin/main and follow instructions)
  • Image usage
    • <picture> preferring webp with png fallback?
  • Suggest the contributor to read the Jekyll docs: https://jekyllrb.com/docs/ but also write the guide assuming contributors have not read this thoroughly, for now.
  • Referencing other files (using {% link %} etc)
    • It's a compile-time file check, basically
  • Site structure
    • What goes where and what's what
      • /assets/: generic site assets
      • /_sections/: pages that get their title assigned to the website root, e.g. /_sections/blarg.md with title: Test in front matter gets http://site/Test as permalink, but try to keep file name (and casing) consistent with the title used.
      • /_wiki/: uses the path of the file as permalink and defaults to the wikipage layout, e.g. _wiki/Install/Linux.md becomes https://site/Install/Linux
      • Generic Jekyll files:
        • /_config.yml: main Jekyll config, see Configuration | Jekyll
        • /index.md: frontpage content, see front matter for which layout is used
        • /404.html: the 404 (page not found) page used
        • /Gemfile (and Gemfile.lock): ruby files used by rubygems and bundler, see Ruby(?) docs.
      • Generic folders:
        • /_data/: data accessible via {{ site.data }}, see Data Files | Jekyll
        • /_includes/: files used in {% include <file> %} statements, see Includes | Jekyll
        • /_layouts/: files used for layouts, inheritance is heavily used here, see Layouts | Jekyll
        • /_site/: Contains the processed/built site. Should never be in VCS/git.
        • vendor: Your local ruby files. Should never be in VCS/git.
    • What happens in different folders (collections array in /_config.yml tells us most of that)
    • Detail usage of /_layouts
      • also mention that wiki collections (/_wiki files) always use the wikipage layout, anything else uses the default layout, and inheritance is used (e.g. layout wikipage defining default as its layout, which replaces {{ content }} in default with wikipage contents) (link to Jekyll docs for layouts)
  • Target browsers (Chrome and Firefox, both on Mobile and Desktop - if Chrome works most things should work)
  • Usage of JavaScript
    • Keep to a minimum, but if you have to use it, always consider noscript/no-JS users - at the very least, have a scriptless fallback.

Additions welcome

Langage dominant
HTML
Étoiles
40
Forks
10
Merge moyen
32 min
PR mergées (30 j)
4

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de OpenTabletDriver/opentabletdriver.github.io

Toutes les issues de OpenTabletDriver/opentabletdriver.github.io

Issues similaires

Plus d'issues Documentation

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.