Oplæg til ding Code Guidelines
Core Team har udarbejdet et sæt regler kaldet Code Guidelines, der beskriver best practice, når man ønsker at bidrage og udvikle kode til DING projektet.
Formålet er at sikre:
- En stærk og stabil core, der er sikret vedligeholdelse og konsistens
- De bedst mulige betingelser for at dele moduler mellem DING sites
- De bedst mulige betingelser for at de enkelte DING sites kan tilpasse og konfigurere sitet
Dokumentet Code Guidelines Draft 1.0 er for nuværende publiceret som et Google dokument, og Core Team vil hermed invitere TING Community til at kommentere på indholdet. Vi vil så i Core Team gennemgå kommentarerne og tilrette dokumentet, inden den endelige udgave publiceres på ting.dk.
>> Læs og kommentér her: Code Guidelines Draft 1.0
Sådan bidrager man til DING projektet
Core Team har endvidere beskrevet den procedure, der skal følges, når man vil bidrage til ding.core. Disse procedurer skal følges, når udviklere - hvad enten der er tale om biblioteksansatte, tekniske leverandører eller frivillige udviklere - vil foretage ændringer i koden.
>> Læs beskrivelsen på Ting.dk: "Sådan bidrager du til DING projektet"
Hvis du har spørgsmål til ovenstående eller vil vide mere er du meget velkommen til at kontakte Core Team. Du kan finde kontaktinfo her: Kontakt Core Team
Med venlig hilsen
Core Team
Kasper Garnæs, Reload! A/S
Jesper Kristensen, Aarhus Kommunes Biblioteker, ITK
Recent members
 |
Havelund | |
 |
Emilia | |
 |
jyd | |
 |
sgl | |
|
|
Michael Trøstrup | |
|
|
RunePhilosof | |
|
|
StineWeymann | |
|
|
jesperjb | |
|
|
Gitte Barlach | admin |
 |
zorp |
- 1 of 9
- ››
Most active users
| Bruger | Points | |
|---|---|---|
 |
Niels Schmidt | 954 |
|
|
Gitte Barlach | 445 |
 |
sofr | 235 |
 |
kasperg | 192 |
 |
dskn | 185 |
Group admins
|
|
Gitte Barlach | admin |
Kommentarer
Solidt udgangspunkt
Min umiddelbare reaktion efter gennemlæsning er, at det virker til at være velovejede og solide guidelines for kode, som både er til at efterleve og som burde gøre livet nemmere for alle involverede.
Med fare for at afspore jeres oprindelige ønske om feedback på code guidelines, så er jeg nysgerrig efter jeres bud på, hvordan vi håndterer arkitekturdelen? Blandt andet på frontend-delen har vi lidt under en akut mangel på planlagt arkitektur.
Bittersødt
Jeg synes det er godt vi får nogen guidelines, men en del af kravene stiller store krav til ekstra arbejde i form af meget detaljeret dokumentation, og jeg tror ikke det vil være en fordel for fremdriften i Ding. Hvis det skal koste 50% ekstra at gøre den kode man måtte have lavet klar til at komme med, tror jeg at man i mange tilfælde vil vælge at springe den del over.
Og så synes jeg det ville være en stor fejl at gøre “et repo pr. modul” til en fast regel. I Ding2 har vi passeret de 50 repositories, og det er en kæmpe byrde at skulle holde styr på for den enkelte udvikler, når selv den simpleste ændring påvirker mindst tre Git-repositories, som alle skal opdateres inden man går i gang, committes til samtidig, branches, tagges, laves pull requests til osv.
Ekstra arbejde og kompleksiteter
Vedr. dokumentation
Nu kan der jo være forskel på hvordan kravene læses, men jeg har netop lavet dokumetnation til ding_redia_feeds. Det tænker jeg umiddelbart er på det niveau vi ønsker af Ding udvidelser. Det har taget ca. 1 time at skrive dette. Jeg gætter på at det udgår <10% af den tid er brugt på projektet. Det mener jeg ikke er urimeligt set i forhold til den værdi det giver fællesskabet som helhed. Hvis der ikke er overskud til dette i et projekt, er der mnåske mere generelt behov for at overveje deltagelsen i Ding fællesskabet.
Hvis du læser kravene som noget andet og større, så sig endelig til, så vi kan få specificeret hvad der menes.
Vedr. "et repo pr. modul"
Jeg vil meget gerne tage en diskussion vedr. denne regel og de erfaringer, udviklerne har med den.
Årsagen til at Ding 2 er struktureret ud fra det princip er baseret på situationen i Ding 1, hvor én lille lokal ændring kan medføre at et bibliotek er nødt til at forke meget store dele af kodebasen. Fx. er ding repositoriet meget omfattende. Samtidig har vi generelt også set mange forks. Med "et repo per modul" er målet at forks for det enkelte bibliotek er mindre omfattende og derfor lettere at vedligeholde.
Personligt mener jeg at modulvalget i Ding (bl.a. Panels og Features) og de hooks de stiller til rådighed gør det muligt at lave lokale ændringer uden overhovedet at forke.
Derudover tror jeg at mere veldokumentere workflows for håndtering af forkede moduler gøre en stor forskel.
Hvis vi står i en situatioen, hvor den nuværende arkitektur skaber større problemer for de udviklere der skal arbejde med dem som du argumentere for, set i forhold til formålet, synes jeg vi skal tage det op til genovervejelse.