Bijdragen

Hé jij daar! Vind je het leuk bij te dragen aan Jetpack?

Ja, jij: weet je dat je kan helpen om Jetpack sterker en veiliger te maken? Als je Jetpack gebruikt en het leuk vindt, waarom zou je dan niet bijdragen aan het project?

(Als je Jetpack niet gebruikt en niet leuk vindt, waar wacht je nog op? Download het nu!)

Net als WordPress zelf is Jetpack een open bron. Je kunt geplande verbeteringen uittesten, de code, het bestand en bug rapporten bekijken en zelfs je eigen patches indienen. WordPress en Jetpack zijn zo sterk dankzij de bijdragen uit de gemeenschap.

Door bij te dragen aan Jetpack, verbeter je de functionaliteit van miljoenen websites terwijl je hands-on ontwikkelingservaring opdoet. Het beste van alles is dat ontwikkelaars van alle niveaus kunnen helpen — of je nu nauwelijks een filter kunt herkennen (of niet weet wat dat betekent) of dat je al je eigen plugins geschreven hebt, er zijn altijd manieren waarop je kunt bijspringen. Daar gaan we:

Mogelijkheden voor beginner, intermediair en geavanceerde bijdrage.
Hoe de broncode controleren.
Hoe een goed bug rapport creëren.
Hoe een patch schrijven en indienen.
Beste werkmethoden voor WordPress ontwikkeling.

Iedereen kan Meedoen!

Backyard Rockets: Jetpack Nieuwelingen

Ben je net met Jetpack begonnen? Welkom!

Installeer Jetpack eerst op een test website en scharrel daar wat rond – zet een paar modules aan en probeer ze aan te passen. (Plek nodig om te beginnen? Probeer het mobiele thema eens, of verplaats je deelknoppen.)

Wat denk je vervolgens van een aanmelding voor bèta testen? Bèta testers proberen updates, reparaties en nieuwe modules uit voordat ze openbaar worden gemaakt. Ze zijn dus een belangrijk deel van het ontwikkelingsproces. Als je geïnteresseerd bent om je aan te sluiten bij de bèta groep, vul dit formulier in om ons hierover te informeren.

Als je eenmaal door hebt hoe Jetpack werkt, neem dan eens een kijkje bij Trac, onze probleem-tracerende tool. Binnen mum van tijd zul je bug meldingen kunnen indienen.

Long-Range Vlucht: Intermediaire Programmeurs

Als je codes goed kunt lezen en bewerken, maar je er nog niet aan toe bent om je eigen codes te schrijven, help de bug zappers door bug rapporten in te dienen. Als je nog nooit een bug rapport ingediend hebt, ga dan naar Een Goed Bug Rapport Creëren om te zorgen dat je rapporten alle informatie hebben die een ontwikkelaar nodig heeft om het probleem snel en efficient op te lossen.

Als je rapporten gaat indienen, is het handig als je ook bekend raakt met Trac. Als je eenmaal goed kunt rapporteren, begin dan naar de code te kijken en bereid je voor op de volgende stap — patches indienen.

Intergalactisch Reizen: Geavanceerde Ontwikkelaars

Schrijf je je eigen codes? Misschien heb je je eigen plugin geschreven of heb je een zonnebril opgezet en diep in het centrum van WordPress gekeken. Kun je goed de code van anderen lezen en verbeteringen voorstellen?

Als je je aangesproken voelt, bind dan de strijd aan en begin met het maken en indienen van patches. Kijk eens naar deze openstaande problemen om een idee te krijgen van het soort dingen waar de gemeenschap graag aandacht voor wil.

De Schroeven en Bouten van het Bijdragen

Aansluiten bij de Bèta Groep

Onze bèta groep is een groep van slimme mensen (een selectieve groep WordPress gebruikers en ontwikkelaars) die ons vertellen wat we fout (en goed) doen in de volgende versie van Jetpack. Je missie als bèta tester is ons helpen de volgende versie van Jetpack uit te testen en ons te informeren over je bevindingen. Is de UI verwarrend? Is er een module die niet goed werkt?

Neem contact op en laat ons weten of je interesse hebt om ons te helpen. Om deel te nemen, moet je de Jetpack Beta Tester plugin downloaden en installeren en zorgen dat je de nieuwste versie van WordPress gebruikt. (Let op: je krijgt geen toegang tot de Bèta Tester plugin totdat je aan de groep bent toegevoegd.)

De Broncode Bekijken

De meeste software projecten, waaronder WordPress, gebruiken een versie-controle systeem om broncodes en herzieningen bij te houden. WordPress en Jetpack gebruiken hun eigen installaties van Subversie als versie-controle. Hier volgt de basis van het verbinden met onze Subversie repository.

(Als je niet bekend bent met Subversie, zijn de leertools op OpenHatch Training Missions een goede plek om te beginnen.)

Subversie Installeren

De makkelijkste manier om Subversie te krijgen is het downloaden van een tweedelig pakket voor je besturingssysteem van de website van subversie — er zijn pakketten voor de meeste belangrijke besturingssystemen, waaronder Mac OSX, Windows, verschillende versies van Linux en nog veel meer. Je kunt Subversie ook rechtstreeks opbouwen vanaf een broncode. Download de laatste broncode release vanaf de Subversie website. Na uitpakking, volg je de instructies in het INSTALL bestand om het op te bouwen.

Voor meer informatie, ga naar “Subversie Installeren” in Versie-Controle met Subversie.

Subversion Navigeren

De broncode en de herzieningen worden bewaard in een repository. Je maakt verbinding met de repository door gebruik te maken van het commando line interface (CLI) of met een klantprogramma, waarmee je de broncode kunt controleren, bekijken, bewerken en patchen. Voor Windows is de aanbevolen SVN klant TortiseSVN (gratis en open bron) en voor Mac is het Cornerstone (betaald).

De Jetpack repository is hier beschikbaar en heeft drie belangrijke secties:

Trunk: De nieuwste ontwikkelingscode.
Tags: Codes die je vertellen om welke versie van Jetpack het gaat (bijv. 2.3.1). Alle openbaar vrijgegeven versies van Jetpack hebben een tag.
Branches: Vorige Jetpack versies. Soms, als er belangrijke nieuwe Jetpack versies zijn, bewaren we de vorige versie met bug reparaties (meestal beperkt tot grote bugs en veiligheidsproblemen).

Je kunt al de bestanden in de repository bekijken met het list commando:

svn list http://plugins.svn.wordpress.org/jetpack/trunk/

De Code Controleren

Als je Subversie eenmaal geïnstalleerd hebt, moet je de code controleren voordat je er op kunt werken — d.w.z. dat je de code downloadt van de repository naar je computer. Hier zie je hoe:

Maak een leeg bestand voor je kopie van de code
Wijzig naar dat bestand
Voer het checkout commando uit op de trunk, branch of tag waarin je geïnteresseerd bent. Om bijvoorbeeld de trunk (laatste ontwikkelingsversie) te controleren:

 svn co http://plugins.svn.wordpress.org/jetpack/trunk/

Als het al een tijd geleden is dat je de code gecontroleerd hebt en je er zeker van wilt zijn dat je de nieuwste versie gebruikt, gebruik je het update commando (zorg dat je eerst naar het originele bestand dat je gebruikte wijzigt):

svn update

Als je al een werkende kopie van de trunk hebt, maar je wilt overschakelen van de code van een vorige versie, gebruik dan het ‘svn switch’ commando om alle bestanden in je werkende kopie te updaten. Dit commando schakelt bijvoorbeeld over naar versie 2.0:

svn switch http://plugins.svn.wordpress.org/jetpack/tags/2.0/

Een Goed Bug Rapport Maken

Trac is een ticket dat gebruikt wordt om projecten en bugs te traceren — we gebruiken het om nieuwe functies te beheren, bugs te melden en voor algemene projecttaken. Het is ontworpen om het de mensen zo makkelijk mogelijk te maken om bugs te melden en patches in te dienen naar de code. (NB: deze Trac is specifiek voor WordPress plugins — WordPress Core heeft zijn eigen Trac, met aparte instructies.)

Je kunt alle huidige open bug rapporten en verzoeken om verbeteteringen aan Jetpack hier zien.

De Anatomie van een Trac Ticket

Een Trac ticket bevat deze velden:

Reporter — de schrijver van het ticket (jij dus).
Type — het soort ticket, zoals een functieverzoek of een a bug.
Onderdeel — de projectmodule waar het ticket naar verwijst (bijv. Photon, Publicize) .
Versie — de Jetpack versie waar het ticket naar verwijst (bijv. 2.3.1, 2.3.2).
Trefwoorden— een lijst trefwoorden gebaseerd op het onderwerp van het ticket, om zoekers te helpen.
Prioriteit — het belang van het probleem, variërend van triviaal tot blokker.
Mijlpaal — de deadline voor het oplossen van het probleem.
Toegewezen aan/Eigenaar— de belangrijkste persoon die verantwoordelijk is voor het ticket (mogelijk ook jij).
Cc — een door komma’s gescheiden lijst andere gebruikers om te informeren.
Resolutie — de reden waarom het ticket afgesloten werd — opgelost, ongeldig, kannietrepareren, dubbel of isgoedzo.
Status — de huidige status van het ticket — nieuw, toegewezen, afgesloten of heropend.
Samenvatting— een korte samenvatting van het probleem.
Beschrijving— een specifieke, beschrijvende, duidelijke en bondige uitleg van de bug of het probleem.

Behalve het rapporteren van bugs en het indienen van patches, kun je het proces van elk ticket waarin je geïnteresseerd bent volgen of gegevens toevoegen aan een bestaand ticket.

Om een ticket te volgen, log je in op Trac, vind het ticket, scrol naar beneden, klik op Ticket Wijzigen en selecteer het vakje naast je e-mailadres:

follow_trac_ticket

Als je gegevens hebt om toe te voegen aan een bestaand ticket, voeg je een commentaar toe door te klikken op Commentaar Toevoegen om een tekstvak te krijgen.

Als je het vakje Toevoegen aan Cc: gecontroleerd hebt en/of een commentaar hebt toegevoegd, zul je zien dat welke veranderingen je ook aangebracht hebt, ze in een Voorbeeld vakje onderaan de pagina zullen verschijnen. Als je tevreden bent, klik je op Wijzigingen Indienen.

trac_modified_ticket

Goed, laten we nu Trac gebruiken om een nieuw ticket in te dienen.

Drie Stappen om een Trac Ster te worden

1. Stel vast dat de bug echt een bug is.

Voordat je melding van een bug maakt, moet je vaststellen of het niet gewoon internet gremlins zijn of een compatibiliteitsprobleem. Voordat je aan je onderzoek begint, zorg dat je de nieuwste versie van WordPress en Jetpack gebruikt.

Begin door alle andere plugins uit te zetten en schakel over naar de standaard TwentyEleven of TwentyTwelve thema’s. Is het probleem er nog steeds? Als dat zo is heb je waarschijnlijk een bug gevonden.

Als het probleem er niet meer is, werd het waarschijnlijk veroorzaakt door een conflict met een van je plugins of thema’s. Test ze nu een voor een — activeer alleen Jetpack en dat thema of die plugin om andere variabelen uit te sluiten. Als het probleem opnieuw verschijnt, heb je de oorzaak gevonden!

2. Kijk of het al gerapporteerd is.

Om te kijken of een bug al gerapporteerd is, kun je:

Wordt het op geen van deze plekken genoemd? Wordt het niet veroorzaakt door een ander plugin of thema? Hoera, je hebt een bug gevonden! Tijd om het te melden.

3. Dien een gedetailleerd, beknopt ticket in.

Hoe specifieker je ticket is, hoe makkelijker het zal zijn om de bug de baas te worden. Log in op Trac, open een nieuw Jetpack Trac ticket, en zorg dat je alle relevante details invult: een korte samenvatting, een duidelijke beschrijving, en of het een defect/bug of een verzoek om verbetering is. Als het door iemand anders gemeld is, bijvoorbeeld op het Jetpack Support Forum, voeg dan een link bij.

(Je hoeft je geen zorgen te maken over het invullen van de trefwoorden of het aangeven van de eigenaar, prioriteit of ernst — we worden bij elk ticket ingelicht en wij zullen dat toevoegen.)

Hier volgt een voorbeeld van hoe een handige samenvatting eruit ziet:

Samenvatting van het probleem: De Jetpack Afbeelding widget geeft de geselecteerde afbeelding niet weer.

Uit te voeren stappen:

Activeer de Extra Zijbalk Widgets module

Voeg de Jetpack Afbeelding widget toe aan de zijbalk en vul alle velden in, inclusief de afbeelding URL

Sla de Widget op en bekijk je website

Verwacht gedrag of resultaat: De zijbalk dient de geselecteerde afbeelding weer te geven

Werkelijk gedrag of resultaat: Een foutmelding verschijnt: “Afbeelding kon niet gevonden worden.”

Link naar Voorbeeld (indien van toepassing): http://example.com/image-widget/

Screenshots: screenshot van foutmelding komt hier

Cross-Browser Testen, AKA “Vergeet Internet Explorer 8 niet”

Als je denkt een bug gevonden te hebben en je hebt alle bovengenoemde stappen uitgevoerd, is het de moeite waard om te controleren of het probleem zich in andere browsers herhaalt. Je kunt download links naar de meest recentie versies van alle belangrijke browsers vinden op Browse Happy.

Je moet ook controleren of de potentiële bug beperkt is tot één brower. Dit is met name belangrijk voor bugs die mogelijk betrekking hebben op Javascript of jQuery, aangezien sommige browsers eerder dit soort problemen ondervinden dan andere.

Alles Patchen! Patches Creëren en Indienen

Bug Zappen

Als je een bug repareert, bewerk dan de bestanden in het directory waar je de code van gecontroleerd hebt. Als je klaar bent om je reparaties in te dienen, maak je een bug ticket aan op Trac, en gebruik deze commando’s om te zien welke onderdelen van je werkende kopie anders zijn dan de broncode in de Jetpack repository:

(Let op: Je moet misschien wijzigen naar een sub-directory (zoalss trunk) om deze commando’s uit te voeren.)

Om een lijst te krijgen van alle bestanden die je gewijzigd hebt, gebruik je het status commando:
```
 svn status
```
Om de wijzigingen te tonen die je gemaakt hebt in een regel per regel patch formaat (wat ook gebruikt zal worden bij het exporteren van patches), gebruik je het diff commando om een unified diff uit te voeren van alle wijzigingen die je aangebracht hebt aan de broncode:
```
 svn diff
```
Om de verschillen in een enkel bestand weer te geven, gebruik je het diff commando (of voeg je multipele bestand paths toe om de verschillen tussen een set pagina’s te laten zien):
```
 svn diff path/to/file
```

Patches Exporteren

Om de wijzigingen die je hebt aangebracht met anderen te delen, exporteer je ze als a .diff of .patch bestand (beide tekstbestanden zonder opmaak van hetzelfde formaat — beide extensies zijn goed). Als je je wijzigingen eenmaal geëxporteerd hebt, voeg je het bestand toe als een patch aan een Trac rapport. Zorg dat je je patches genereert vanaf de root van Jetpack, en liever niet van een sub-directory.

Gebruik de diff commando met > om het bestemmingsbestand aan te geven. Dit slaat de diff output voor alle gewijzigde bestanden in je werkende kopie op.
```
 svn diff > my-patch-file.diff
```
Als je wijzigingen in je werkende kopie hebt die je niet wilt invoegen, geef dan het/de specifieke bestand(en) aan waarvan je wilt dat de diff ze weergeeft:
```
svn diff wp-admin/comment.php wp-includes/comment.php > comments-patch-r3234.diff
```
Om een a .diff of .patch bestand te implementeren in een werkende kopie gebruik je het ‘patch’ commando:
```
patch -p0 < /path/to/patch.diff
```
Om je werkende kopie opnieuw in te stellen naar de code die je gecontroleerd hebt (om wijzigen die je hebt aangebracht weg te gooien):
```
svn revert . -R
```
Je kunt ook een revert uitvoeren voor alleen een enkel bestand:
```
svn revert path/to/file
```

Ontwikkeling Beste Werkmethode voor Iedereen

Voor de beste werkmethode, raadpleeg de informatie in de WordPress.org codex. Daar tref je meer informatie aan over PHP, HTML, CSS en JavaScript codering standaards.