Praktisk information til ding2tal udviklere
Udvikling af Ding2tal
Al udvikling af Ding2tal og hermed udvikling til Ding 2 core foregår efter de aftalte retningslinjer for Ding hovedsporet, http://ting.dk/wiki/saadan-bidrager-man-til-ding-hovedsporet og efter code guidelines for Ding 2.
Da vi har en del udvikling foran os er det vigtigt, at alle involverede samarbejder på samme vis. Dette for at undgå dobbeltarbejde og for at sikre fremgang.
Ding2tal
Projektrummet for ding2tal findes her: http://ting.dk/groups/ding2tal.
Arbejdet koordineres af Projektleder Gitte Barlach, gba@aarhus.dk, ITK, Aarhus Kommunes Biblioteker. Så er der spørgsmål kan de rettes til hende. Tøv ikke.
Udviklingsarbejdet
ITK, Aarhus Kommunes Biblioteker, foretager den grundlæggende opsætning og udvikler basetheme /front-end arkitektur til Ding 2
Til dette formål benytter vi https://github.com/ding2tal og før omtalte retningslinjer om bidrag til hoved-sporet.
Alt arbejde som foretages i ding2tal projektet skal tilbage til hovedsporet og derfor igennem code review af core team.
Har du behov for at blive tilknyttet ding2tal projektet på github, send en mail til Gitte Barlach, gba@aarhus.dk , alternativt til Rasmus Frey, rfrey@aarhus.dk eller skype: rasmus-artz
Ding 2 repositories
Hovedsporet for Ding 2 ligger på github her: https://github.com/ding2
Udvikling i ding2tal projektet foregår her: https://github.com/ding2tal alle repositories forkes fra ding2.
Cherry picks
Andre har ligeledes forket fra ding2 men ikke lavet pull request retur til hovedsporet. Der ligger derfor flere rettelser/tilføjelser i andre forks som med fordel kan cherry pickes over i ding2tal udviklingssporet og så merges ind i hovedsporet herfra.
Det er derfor vigtigt danne sig et overblik over hvilke rettelser som er i andre spor her kan man bla. benytte git's network graph Enkelt commits kan cherry pickes til udvikling branchen i ding2tal projektet.
En simpel forklaring af et cherry pick kan f.eks. findes her: http://mike.bailey.net.au/2008/08/cherry-picking-git-commits/
Retningslinjer
- Tro aldrig, du skal vide (så spørg i fælleschatten hvis ikke du er 100%).
- Udvikling foregår aldrig i master branch men efter følgende regler:
- Vi brancher ud fra master og merger tilbage til master når en udviklings branch er klar til pull request.
- Udvikling skal foregå i egen branch så pull request tilbage til core kan styres og holdes ren.
- En branch navngives efter opgaven som løses.
- Når udvikling er færdig i en branch og klar til pull request notificeres Rasmus Frey som så merger til development samt master og laver pull request.
- Når der er lavet pull request på en branch skal den betragtes som værende låst og videre udvikling skal foregå i en ny branch med udgangspunkt i master.
- Pull requests tilbage til core laves fra de enkelte branches så det kan holdes overskueligt for Core team.
- Development branch er vores øjebliksbillede hvor alt samles via merges, development er også den branch som trækkes på test serveren ding2tal.ting.dk.
- Sørg altid for at koordinere med resten af udviklingsteamet.
- Husk mindre commits og beskrivende commit beskeder (alt skal tilbage til core)
- Husk README fil(er)
Pull requests
Pull requests foretages af Jesper Kristensen, disse kan laves direkte på Github. Ligger et pull request ikke på github sker der ikke noget. En besked i Skype chatten er ikke nok.
Oprydning/rettelser i eksisterende ding2-kode
Pragmatisme og idealisme skal gå hånd i hånd:
- hvis noget grundlæggende ikke virker, må det fixes. Giv Gitte besked *inden* der sker væsentlige over-skridelser af den estimerede tid
- hvis noget *burde* være anderledes, men det tager ekstra tid, laver du det ikke, men opretter en ticket i https://libraryding.lighthouseapp.com/projects/81497-ding2/overview
- hvis der * skal * ske en oprydning pga. af performance eller fordi det er afgørende vigtigt i forhold til di-stributionen, og det tager ekstra tid, så giv Gitte besked inden du går i gang.
Opgavestyring
Vi bruger Trello som værktøj til at styre alle udviklinshopgaver i projektet. Alle i udviklerteamet har adgang.
https://trello.com/
- Når man tager en opgave, assigner man den til sig selv.
- Opgaver specificeres i del-opgaver, og hver del-opgave afkrydses, når den er færdig.
- Når opgaven som helhed er færdig, flyttes den til "Done"
- Projekgruppen sætter den overordnede due-date
- Status, konklusioner m.v. på opgaven foregår på pågældende kort.
- Hjælp til opgave-løsning foregår via chatten
Fælleschat
Der er oprettet en skype fælleschat, ”ding2tal dev”, hvor det er vigtigt at kommunikere med de andre invol-verede så alle er orienteret om, hvad der foregår ude i krogende og så ingen sidder og laver de samme ting. Endnu mere vigtigt kan der stilles spørgsmål hvis man har brug for hjælp.Er du ikke inviteret til fælleschatten så kontakt Gitte.Når man tager en opgave, assigner, man den til sig selv.
Praktisk information til ding2tal udviklere
# Udvikling af Ding2tal
Al udvikling af Ding2tal og hermed udvikling til Ding 2 core foregår efter de aftalte retningslinjer for Ding hovedsporet, http://ting.dk/wiki/saadan-bidrager-man-til-ding-hovedsporet
Da vi har en del udvikling foran os er det vigtigt, at alle involverede samarbejder på samme vis. Dette for at undgå dobbeltarbejde og for at sikre fremgang.
## Ding2tal
Projektrummet for ding2tal findes her: http://ting.dk/groups/ding2tal.
Arbejdet koordineres af Projektleder Gitte Barlach, gba@aarhus.dk, ITK, Aarhus Kommunes Biblioteker. Så er der spørgsmål kan de rettes til hende. Tøv ikke.
## Udviklingsarbejdet
ITK, Aarhus Kommunes Biblioteker, foretager den grundlæggende opsætning og udvikler basetheme /front-end arkitektur til Ding 2
Til dette formål benytter vi https://github.com/ding2tal og før omtalte retningslinjer om bidrag til hoved-sporet.
Alt arbejde som foretages i ding2tal projektet skal tilbage til hovedsporet og derfor igennem code review af core team.
**Har du behov for at blive tilknyttet ding2tal projektet på github, send en mail til Gitte Barlach, gba@aarhus.dk , alternativt til Rasmus Frey, rfrey@aarhus.dk eller skype: rasmus-artz**
### Ding 2 repositories
Hovedsporet for Ding 2 ligger på github her: https://github.com/ding2
Udvikling i ding2tal projektet foregår her:https://github.com/ding2tal alle repositories forkes fra ding2.
### Cherry picks
Andre har ligeledes forket fra ding2 men ikke lavet pull request retur til hovedsporet. Der ligger derfor flere rettelser/tilføjelser i andre forks som med fordel kan cherry pickes over i ding2tal udviklingssporet og så merges ind i hovedsporet herfra.
Det er derfor vigtigt at benytte git's network graph når der udvikles på et ding modul så der kan skabes et overblik over andre forks og enkelt commits kan cherry pickes til udvikling branchen i ding2tal projektet.
En simpel forklaring af et cherry pick kan f.eks. findes her: http://mike.bailey.net.au/2008/08/cherry-picking-git-commits/
### Retningslinjer
* Tro aldrig, du skal vide (så spørg i fælleschatten hvis ikke du er 100%).
* Udvikling foregår **aldrig** i *master branch*.
* Brug development branch.
* Eller opret en passende branch.
* Husk at hvad du laver skal tilbage i hovedsporet (core).
* Sørg altid for at koordinere med resten af udviklingsteamet.
* Husk mindre commits og beskrivende commit beskeder (alt skal tilbage til core)
* Husk README fil(er)
### Oprydning/rettelser i eksisterende ding2-kode
Pragmatisme og idealisme skal gå hånd i hånd:
* hvis noget grundlæggende ikke virker, må det fixes. Giv Gitte besked *inden* der sker væsentlige over-skridelser af den estimerede tid
* hvis noget *burde* være anderledes, men det tager ekstra tid, laver du det ikke, men opretter en ticket i https://libraryding.lighthouseapp.com/projects/81497-ding2/overview
* hvis der * skal * ske en oprydning pga. af performance eller fordi det er afgørende vigtigt i forhold til di-stributionen, og det tager ekstra tid, så giv Gitte besked inden du går i gang.
## Fælleschat
Der er oprettet en skype fælleschat, ”ding2tal dev”, hvor det er vigtigt at kommunikere med de andre invol-verede så alle er orienteret om, hvad der foregår ude i krogende og så ingen sidder og laver de samme ting. Endnu mere vigtigt kan der stilles spørgsmål hvis man har brug for hjælp.
Er du ikke inviteret til fælleschatten så kontakt Gitte.
vPraktisk information til ding2tal udviklere
# Udvikling af Ding2tal
Al udvikling af Ding2tal og hermed udvikling til Ding 2 core foregår efter de aftalte retningslinjer for Ding hovedsporet, http://ting.dk/wiki/saadan-bidrager-man-til-ding-hovedsporet
Da vi har en del udvikling foran os er det vigtigt, at alle involverede samarbejder på samme vis. Dette for at undgå dobbeltarbejde og for at sikre fremgang.
## Ding2tal
Projektrummet for ding2tal findes her: http://ting.dk/groups/ding2tal.
Arbejdet koordineres af Projektleder Gitte Barlach, gba@aarhus.dk, ITK, Aarhus Kommunes Biblioteker. Så er der spørgsmål kan de rettes til hende. Tøv ikke.
## Udviklingsarbejdet
ITK, Aarhus Kommunes Biblioteker, foretager den grundlæggende opsætning og udvikler basetheme /front-end arkitektur til Ding 2
Til dette formål benytter vi https://github.com/ding2tal og før omtalte retningslinjer om bidrag til hoved-sporet.
Alt arbejde som foretages i ding2tal projektet skal tilbage til hovedsporet og derfor igennem code review af core team.
**Har du behov for at blive tilknyttet ding2tal projektet på github, send en mail til Gitte Barlach, gba@aarhus.dk , alternativt til Rasmus Frey, rfrey@aarhus.dk eller skype: rasmus-artz**
### Ding 2 repositories
Hovedsporet for Ding 2 ligger på github her: https://github.com/ding2
Udvikling i ding2tal projektet foregår her:https://github.com/ding2tal alle repositories forkes fra ding2.
### Cherry picks
Andre har ligeledes forket fra ding2 men ikke lavet pull request retur til hovedsporet. Der ligger derfor flere rettelser/tilføjelser i andre forks som med fordel kan cherry pickes over i ding2tal udviklingssporet og så merges ind i hovedsporet herfra.
Det er derfor vigtigt at benytte git's network graph når der udvikles på et ding modul så der kan skabes et overblik over andre forks og enkelt commits kan cherry pickes til udvikling branchen i ding2tal projektet.
En simpel forklaring af et cherry pick kan f.eks. findes her: http://mike.bailey.net.au/2008/08/cherry-picking-git-commits/
### Retningslinjer
* Tro aldrig, du skal vide (så spørg i fælleschatten hvis ikke du er 100%).
* Udvikling foregår **aldrig** i *master branch*.
* Brug development branch.
* Eller opret en passende branch.
* Husk at hvad du laver skal tilbage i hovedsporet (core).
* Sørg altid for at koordinere med resten af udviklingsteamet.
* Husk mindre commits og beskrivende commit beskeder (alt skal tilbage til core)
* Husk README fil(er)
### Oprydning/rettelser i eksisterende ding2-kode
Pragmatisme og idealisme skal gå hånd i hånd:
* hvis noget grundlæggende ikke virker, må det fixes. Giv Gitte besked *inden* der sker væsentlige over-skridelser af den estimerede tid
* hvis noget *burde* være anderledes, men det tager ekstra tid, laver du det ikke, men opretter en ticket i https://libraryding.lighthouseapp.com/projects/81497-ding2/overview
* hvis der * skal * ske en oprydning pga. af performance eller fordi det er afgørende vigtigt i forhold til di-stributionen, og det tager ekstra tid, så giv Gitte besked inden du går i gang.
## Fælleschat
Der er oprettet en skype fælleschat, ”ding2tal dev”, hvor det er vigtigt at kommunikere med de andre invol-verede så alle er orienteret om, hvad der foregår ude i krogende og så ingen sidder og laver de samme ting. Endnu mere vigtigt kan der stilles spørgsmål hvis man har brug for hjælp.
Er du ikke inviteret til fælleschatten så kontakt Gitte.
Grupper:
Kommentarer
github network graph
TIP: Hvis i gør jer afhængige af denne graf, så husk på at den ikke er live opdateret. Seneste opdatering kan ses i højre hjørne over grafen.
Ville rette lidt meeen
Jeg ville rette lidt i teksten men har ikke rettighed til at redigere wikisiden..
Network graph er ikke noget vi gør os afhængig af det er blot et blandt flere værktøjer som kan benyttes til at skabe overblik over hvad der er blevet implementeret i andre forks uden der er lavet pull request tilbage til core.
Gode kommentarer ved branches
Ift. bidrag til Ding.Core er retningslinierne ift. branches rigtig gode!
Husk at det er vigtigt at vedligholde ens egen branch i forhold til udgangspunktet. Så bliver det også lettere for Rasmus at merge.