Soumettre une Contribution
Avertissement
Cette documentation est faire pour une ancienne version de SpongeAPI et n’est plus maintenue. Même si les examples de code fonctionnent toujours pour cette version de l’API, les politiques, lignes de conduite, et quelques liens peuvent avoir changé. Veuillez vous rendre sur la dernière version de la documentation pour ces derniers.
Les Bases
Vous aurez d’abord besoin de configurer votre machine pour pouvoir développer pour et avec Sponge:
lisez Préparation pour le développement et configurez votre machine
familiarisez-vous avec git et GitHub: Comment utiliser Git(Hub)
lisez notre page sur le Style de Code et Lignes directrices des contributions
familiarisez-vous avec notre Git Workflow pour API et Implémentations
Quand vous avez terminé et que vous vous sentez prêts pour développer Sponge, décidez sur quoi vous allez travailler.
Rédiger une Contribution
Corriger des Bugs
Expliquez en quelques phrases:
quel bug vous avez rencontré, en particulier
quel est son comportement
comment pensez-vous qu’il doit se comporter
ce que vous avez corrigé
comment vous l’avez corrigé
Addition Majeure à l’API
Vous avez développé un grand ajout à l’API et vous voulez la proposer. Bien! Les contributions constructives sont celles qui permettent au projet de vivre et de toujours s’améliorer. Ce qui nous amène à une longue et glorieuse rédaction de requête.
Il y a eu quelques uns dans le passé qui vont au-delà des normes, on peut citer:
Bien sûr, ces exemples sont assez extrêmes, mais les contributions qui sont acceptées et qui fournissent un standard de ce qu’il doit être inclus dans une description de requête sont:
Quelques petites choses peuvent être retenues:
Les liens vers n’importe quelle requêtes d’implémentation sont placés de manière aérée en haut de la requête, ceci peut être réalisé avec GitHub MarkDown
*SpongeAPI*|[SpongeCommon](html link)|[SpongeForge](html link)|[SpongeVanilla](html link)
Une description claire de ce que la requête ajoute, ce peut être un bref sommaire comme un brouillon. Le mieux est de faire 4 phrases, mais cela dépend de la fonctionnalité.
Des exemples clairs de code pour montrer comment les plugins peuvent utiliser les nouvelles fonctionnalités (et s’il y avait des anciennes fonctionnalités existantes, pourquoi elles ont dû être changées).