Aller directement au contenu

Contribuer


Intéressé à rendre GhostWriter encore meilleur ? Veuillez lire les sections ci-dessous pour voir comment vous pouvez contribuer.

Rapports de bogues

Vous avez trouvé un bug ? Veuillez le signaler sur le système de suivi des bogues de KDE. N'oubliez pas de suivre les directives pour la production de rapports de bogues ! Plus important encore, n'oubliez pas d'inclure le numéro de version de GhostWriter que vous utilisez.

AVERTISSEMENT : en cas d'impossibilité de fournir les informations requises dans le modèle de rapport de bogue, le rapport de bogue sera fermé automatiquement.

Triage de bogues

Vous pouvez aider sur les problèmes de tri dans le gestionnaire de problèmes en reproduisant des bogues et en obtenant plus d'informations des personnes ayant signalées les bogues pour aider à mieux cerner l'endroit où se situe le problème. La fermeture des problèmes en double et d'autres classements seraient également appréciés. Pour plus d'informations, veuillez consulter les directives de tri des bogues.

Nouvelles fonctionnalités et corrections de bogues

Savez-vous comment coder ? Veuillez suivre ces étapes :

  1. Soumettez un problème pour votre fonctionnalité ou votre bogue sur le gestionnaire de problèmes de KDE.
    **Remarque : ** Cette étape est nécessaire pour s'assurer que la nouvelle fonctionnalité atteint les objectifs du projet ou que le bogue n'est pas vraiment une fonctionnalité. Vous voudrez également coordonner les zones de code que vous mettrez à jour pour éviter de fusionner les conflits au cas où quelqu'un d'autre travaille également sur cette même zone de code.
  2. Après discussion pour votre nouveau problème, lancez vous dans le codage de votre fonctionnalité ou votre correction de bogue. Veuillez suivre le Guide de style de codage des environnements de développement de KDE. ** IMPORTANT** : *Veuillez conserver votre code concentré sur le problème en question. *Les modifications non liées au code appartiennent à des problèmes / demandes de fusion séparés pour faciliter l'examen et les tests de code.
  3. Soumettez une demande concernant la branche principale avec vos mises à jour de code.
    IMPORTANT : Veuillez écraser vos commits dans Git avant de soumettre la demande !
  4. Attendez une brève revue de code et au moins deux autres bénévoles pour tester votre fonctionnalité ou votre correction de bogue.
  5. Faites des mises à jour de votre demande lorsque vous recevez des commentaires.
  6. Une fois que votre demande est approuvée par au moins deux autres personnes bénévoles de l'équipe de tests, votre demande sera fusionnée.

Revues de code

Savez-vous comment coder et avoir un œil pour les détails ? Soyez volontaires pour des revues de pairs pour les nouvelles demandes de fusion !

  1. Recherchez une nouvelle demande de fusion et ajoutez un commentaire que vous êtes bénévole pour le revoir.
  2. Soumettre des commentaires suite à revue de code.
  3. Attendez les mises à jour de la demande de fusion (Si nécessaire).
  4. Continuez à fournir des commentaires jusqu'à ce que vous soyez convaincu que le code est robuste.
  5. Laissez un commentaire avec votre approbation de la demande de fusion.
  6. Une fois que deux testeurs bénévoles ont soumis leur approbation, la demande de fusion sera réalisée.

Vous trouverez ici quelques conseils sur ce qu'il faut rechercher dans les revues de code :

  • Le code soumis suit-il le guide de style de codage des environnements de développement de KDE ?
  • Le code est-il lisible, avec des commentaires expliquant des lignes non évidentes ?
  • Le code est-il « pessimiste » ? En d'autres termes, vérifie-t-il les valeurs non valables avant de les utiliser et gère-t-il les conditions d'erreur possibles ?
  • Les comparaisons multiples ou les énoncés entre parenthèses font-elles partie des blocs « si » pour prévenir les accidents selon l’ordre d’exploitation ? Exemples :
    // Faux
    if (a == b || c > d);
    
    // Correct
    if ((a == b) || (c > d));
    
  • Les termes sur le côté gauche de l'opérateur « == » pour empêcher une faute de frappe avec l'opérateur « = » échappent à l'analyse du compilateur ? Exemples :
    // Faux
    if (variable == 1);
    
    //         Raison : et s'il y avait une faute de frappe ? Le compilateur ne la laissera pas passer !
    if (variable = 1); // Oups !
    // Correct
    if (1 == variable);
    
    //         Raison : cette fois, le compilateur rattrapera la faute de frappe.
    if (1 = variable); // Oups !
    

En test

Aux personnes volontaires pour revoir le code ainsi que tester les nouvelles fonctionnalités et les corrections de bogues ! Suivez ces étapes :

  1. Recherchez une nouvelle demande de fusion et ajoutez un commentaire que vous êtes volontaire pour le tester.
  2. Créer la demande de fusion sur votre plate-forme.
  3. Testez la fonctionnalité / correction de bogue et essayez de le casser !
  4. Fournir des commentaires sur les résultats des tests dans la demande de fusion.
  5. Attendez les mises à jour de la demande de fusion (Si nécessaire).
  6. Continuez à tester et à fournir des commentaires jusqu'à ce que vous soyez convaincu que le code fonctionne.
  7. Laissez un commentaire avec votre approbation de la demande de fusion.
  8. Une fois qu'au moins un autre testeur bénévole fournit son approbation, la demande de fusion sera acceptée.

Traductions

Veuillez envisager de rejoindre l'équipe de traductions de KDE pour traduire vos applications préférées dans d'autres langues.

Support technique

Vous connaissez Linux ou la compilation pour macOS ? Vous savez comment corriger ce problème que d'autres personnes ont rencontré ? Vos réponses aux questions des utilisateurs et vos informations de dépannage dans le [système de suivi des bogues de KDE] KDE_Bugs seraient très appréciées !