Bijdragen aan Semantische kernel
U kunt bijdragen aan Semantische kernel door problemen in te dienen, discussies te starten en pull-aanvragen (PULL's) in te dienen. Bijdragen aan code wordt zeer gewaardeerd, maar het indienen van problemen die u ondervindt, is ook een uitstekende manier om bij te dragen, omdat het ons helpt ons te concentreren op onze inspanningen.
Rapportageproblemen en feedback
We verwelkomen altijd foutrapporten, API-voorstellen en algemene feedback. Omdat we GitHub gebruiken, kunt u de tabbladen Problemen en discussies gebruiken om een gesprek met het team te starten. Hieronder vindt u enkele tips bij het indienen van problemen en feedback, zodat we zo snel mogelijk op uw feedback kunnen reageren.
Problemen melden
Nieuwe problemen voor de SDK kunnen worden gerapporteerd in onze lijst met problemen, maar voordat u een nieuw probleem opgeeft, zoekt u in de lijst met problemen om te controleren of deze nog niet bestaat. Als u problemen ondervindt met de Semantische kerneldocumentatie (deze site), kunt u een probleem indienen in de Semantische kerneldocumentatieopslagplaats.
Als u een bestaand probleem vindt voor wat u wilt melden, neemt u uw eigen feedback op in de discussie. We raden ook ten zeerste aan om het oorspronkelijke bericht (š reactie) te stemmen, omdat dit ons helpt bij het prioriteren van populaire problemen in onze achterstand.
Een goed bugrapport schrijven
Goede foutrapporten maken het eenvoudiger voor onderhouders om het onderliggende probleem te verifiƫren en de hoofdoorzaak te achterhalen. Hoe beter een foutenrapport, hoe sneller het probleem kan worden opgelost. In het ideale geval moet een foutenrapport de volgende informatie bevatten:
- Een algemene beschrijving van het probleem.
- Een minimale reproductie, dat wil zeggen de kleinste grootte van code/configuratie die nodig is om het verkeerde gedrag te reproduceren.
- Een beschrijving van het verwachte gedrag, vergeleken met het waargenomen werkelijke gedrag .
- Informatie over de omgeving: besturingssysteem/distributie, CPU-architectuur, SDK-versie, enzovoort.
- Aanvullende informatie, bijvoorbeeld een regressie uit eerdere versies? Zijn er bekende tijdelijke oplossingen?
Feedback verzenden
Als u algemene feedback hebt over Semantische kernel of ideeƫn over hoe u deze beter kunt maken, kunt u het delen op ons discussiebord. Voordat u een nieuwe discussie start, zoekt u in de lijst met discussies om er zeker van te zijn dat deze nog niet bestaat.
We raden u aan de categorie ideeƫn te gebruiken als u een specifiek idee hebt dat u wilt delen en de Q&A-categorie als u een vraag hebt over Semantische kernel.
U kunt ook discussies starten (en feedback delen die u hebt gemaakt) in de Discord-community door deel te nemen aan de Semantische Kernel Discord-server.
Help ons prioriteit te geven aan feedback
We gebruiken momenteel up-votes om ons te helpen prioriteit te geven aan problemen en functies in onze achterstand, dus stem eventuele problemen of discussies die u wilt aanpakken.
Als u denkt dat anderen baat hebben bij een functie, raden we u ook aan anderen te vragen om het probleem bij te werken. Dit helpt ons prioriteit te geven aan problemen die van invloed zijn op de meeste gebruikers. U kunt collega's, vrienden of de community op Discord vragen een probleem bij te stemmen door de koppeling naar het probleem of de discussie te delen.
Pull-aanvragen verzenden
We verwelkomen bijdragen aan Semantic Kernel. Als u een foutoplossing of nieuwe functie hebt die u wilt bijdragen, volgt u de onderstaande stappen om een pull-aanvraag (PULL) in te dienen. Daarna controleren projectonderhouders codewijzigingen en voegen ze samen zodra ze zijn geaccepteerd.
Aanbevolen bijdragewerkstroom
We raden u aan de volgende werkstroom te gebruiken om bij te dragen aan Semantische kernel (dit is dezelfde werkstroom die wordt gebruikt door het Semantische kernelteam):
- Maak een probleem voor uw werk.
- U kunt deze stap overslaan voor triviale wijzigingen.
- Gebruik een bestaand probleem in het onderwerp als er een probleem is.
- Zorg voor een overeenkomst van het team en de community dat uw voorgestelde wijziging een goede is door gebruik te maken van de discussie in het probleem.
- Geef duidelijk aan wat het probleem is dat u gaat implementeren. Hierdoor kunnen we het probleem aan u toewijzen en ervoor zorgen dat iemand anders er niet per ongeluk aan werkt.
- Maak een persoonlijke fork van de opslagplaats op GitHub (als u er nog geen hebt).
- Maak in uw fork een vertakking van het hoofd (
git checkout -b mybranch
).- Geef de vertakking een naam zodat deze duidelijk uw intenties communiceert, zoals 'issue-123' of 'githubhandle-issue'.
- Breng uw wijzigingen aan en voer deze door in uw vertakking.
- Voeg nieuwe tests toe die overeenkomen met uw wijziging, indien van toepassing.
- Bouw de opslagplaats met uw wijzigingen.
- Zorg ervoor dat de builds schoon zijn.
- Zorg ervoor dat de tests allemaal worden doorgegeven, inclusief uw nieuwe tests.
- Maak een pull-aanvraag voor de hoofdbranch van de opslagplaats.
- Geef in de beschrijving aan welk probleem of welke verbetering uw wijziging is gericht.
- Controleer of alle controles voor continue integratie worden doorgegeven.
- Wacht op feedback of goedkeuring van uw wijzigingen van de code-onderhouders.
- Wanneer eigenaren van gebieden zijn afgemeld en alle controles groen zijn, wordt uw pull-aanvraag samengevoegd.
Dos and Don'ts while contributing
Hier volgt een lijst met Dos en Don'ts die we aanbevelen bij het bijdragen aan Semantic Kernel, zodat we uw wijzigingen zo snel mogelijk kunnen bekijken en samenvoegen.
Doe het volgende:
- Volg de standaard .NET-coderingsstijl en Python-codestijl
- Geef prioriteit aan de huidige stijl van het project of bestand dat u wijzigt als het afwijkt van de algemene richtlijnen.
- Neem tests op bij het toevoegen van nieuwe functies. Bij het oplossen van fouten begint u met het toevoegen van een test die laat zien hoe het huidige gedrag wordt verbroken.
- Houd de discussies wel gefocust. Wanneer er een nieuw of gerelateerd onderwerp wordt besproken, is het vaak beter om een nieuw probleem te maken dan om de discussie naast elkaar te houden.
- Geef duidelijk aan wat een probleem is dat u gaat implementeren.
- Blog en/of tweet over uw bijdragen!
Don'ts:
- Verras het team niet met grote pull-aanvragen. We willen inzenders ondersteunen, dus we raden u aan een probleem in te dienen en een discussie te starten, zodat we het eens kunnen worden over een richting voordat u een grote hoeveelheid tijd investeert.
- Voer geen code door die u niet hebt geschreven. Als u code vindt die u denkt goed te kunnen toevoegen aan Semantische kernel, dient u een probleem in en start u een discussie voordat u doorgaat.
- Verzend geen PULL's die licentiegerelateerde bestanden of headers wijzigen. Als u denkt dat er een probleem is, dient u een probleem in en bespreken we het graag.
- Maak geen nieuwe API's zonder een probleem in te dienen en eerst met het team te bespreken. Het toevoegen van een nieuw openbaar oppervlak aan een bibliotheek is een groot probleem en we willen ervoor zorgen dat we het goed krijgen.
Wijzigingen die fouten veroorzaken
Bijdragen moeten api-handtekening en gedragscompatibiliteit behouden. Als u een wijziging wilt aanbrengen die bestaande code onderbreekt, dient u een probleem in om uw idee of wijziging te bespreken als u denkt dat een wijziging die fouten veroorzaakt, gerechtvaardigd is. Anders worden bijdragen met belangrijke wijzigingen geweigerd.
Het CI-proces (continue integratie)
Het CI-systeem (continue integratie) voert automatisch de vereiste builds uit en voert tests uit (inclusief de builds die u ook lokaal moet uitvoeren) voor PULL's. Builds en testuitvoeringen moeten schoon zijn voordat een pull-aanvraag kan worden samengevoegd.
Als de CI-build om welke reden dan ook mislukt, wordt het pull-aanvraagprobleem bijgewerkt met een koppeling die kan worden gebruikt om de oorzaak van de fout te bepalen, zodat deze kan worden opgelost.
Bijdragen aan documentatie
We accepteren ook bijdragen aan de Semantic Kernel-documentatieopslagplaats.