Contribuer

aarshi est un petit projet, et chaque signalement, idée ou correction utile compte. Cette page explique où parler d'aarshi, ce qui fait une bonne issue, et comment proposer une modification.

Signaler un bug ou demander une fonctionnalité

Ouvrez une issue sur le dépôt GitHub. Choisissez le modèle de bug report ou de demande de fonctionnalité ; si aucun ne convient, ouvrez une issue vide. Dans tous les cas, donnez assez de détails pour que quelqu'un d'autre puisse reproduire le problème.

Une bonne issue répond à ces questions :

1. Quelle commande avez-vous lancée ? Copiez-la exactement, options comprises, par exemple aarshi add -s equipe a-propos.
2. Quelle version et quel système ? La sortie de aarshi --version, et votre système d'exploitation.
3. Qu'attendiez-vous, et que s'est-il passé ? Collez la sortie complète de la commande, pas un résumé.
4. Le problème concerne-t-il un projet ? Ajoutez la sortie de aarshi status --json lancée dans ce projet. Retirez avant tout ce qui est privé, comme une URL de site que vous ne voulez pas partager.

Donnez à l'issue un titre court qui nomme la commande ou l'écran concerné, par exemple add -p : page créée sans entrée dans le plan du site.

Proposer une fonctionnalité

Décrivez d'abord le problème, puis la solution. Que vouliez-vous faire, et combien cela vous a-t-il coûté de le faire à la main ? Une commande ou une option proposée est bienvenue, mais c'est le problème qui décide si la proposition est retenue.

Trouver de quoi contribuer

• La documentation. Une phrase peu claire, un exemple manquant, une coquille. Chaque page existe en anglais et en français : corrigez les deux, ou dites dans l'issue que vous ne pouvez en faire qu'une.
• Une règle de status. Une nouvelle vérification demande trois choses : un nom de règle dans le bon sujet, une entrée dans CONVENTIONS.md et CONVENTIONS.fr.md, et un test dans tests/cli.rs.
• Un bug. Toute issue de bug, une fois reproduite, est un bon premier choix.

Proposer une modification

1. Partez du code le plus récent, sur une branche au nom clair, par exemple fix/invite-section.
2. Faites la modification, et ajoutez ou mettez à jour un test pour elle.
3. Lancez les vérifications avant de publier :

   cargo fmt
   cargo clippy --all-targets
   cargo test

4. Ouvrez une pull request. Expliquez en quelques phrases ce qui change et pourquoi, et liez l'issue à laquelle elle répond.

Messages de commit

Chaque message de commit commence par un type et un périmètre, suivis d'un résumé court :

fix(status): exit 2 when aarshi.toml cannot be analyzed
docs(commands): explain aarshi add step by step

Les types que vous rencontrerez le plus sont feat, fix, docs, refactor et test.

Règles qui valent pour toute modification

Langues

Le code et les commentaires sont en anglais. La CLI affiche en anglais. La documentation (README, CONTRIBUTING, CONVENTIONS et ces pages) est écrite en anglais et en français, et les deux versions changent ensemble.

Commentaires

Courts, et seulement là où le comportement n'est pas évident dans le code. Les fonctions Rust publiques ont un commentaire de documentation ///.

Décisions de conception

Une modification de comportement est plus facile à relire quand son issue ou sa pull request explique la décision dont elle découle.