Sådan bidrager man til DDB CMS/ding2

Når udviklere - hvad enten der er tale om biblioteksansatte, tekniske leverandører eller frivillige udviklere - vil foretage ændringer, skal nedenstående procedurer følges.

Udvidelser og fejlrettelser til eksisterende moduler

  1. Lav en fork af det repository fra http://github.com/ding2/ som skal modificeres til din organisations eller din kundes profil
  2. Ret fejlen i det forkede repository
  3. Lav en ticket i http://platform.dandigbib.org/projects/ddb-cms der beskriver fejlen. Beskrivelsen skal kunne forstås af udviklere så vel som biblioteksansatte som senere skal verificere rettelsen.
  4. Lav et pull request mod det originale repository
  5. Et eller flere medlemmer af Core-team vil gennemgå ændringen og komme med kommentarer under pull requestet i henhold til Code guidelines. Andre udviklere er velkomne til at bidrage med kommentarer. Disse vil også blive taget i betragtning.
  6. Hvis koden accepteres, vil Core-team merge koden ind i DDB CMS. Herefter gennemføres en test, inden en ny release af hovedsporet.
  7. Hvis koden ikke accepteres vil Core-team kommentere på koden, og udviklere kan foretage de nødvendige ændringer. Herefter foretages et nyt review, og hvis koden accepteres, vil Core-team merge koden ind i DDB CMS/ding2.
  8. Hvis du har brug for at ændringen træder i kraft med det samme i dit lokale projekt, kan du opdatere projektets ding.make fil og hive ændringen ind som en patch - se fx. En anden mulighed er at hive ændringerne fra pull requestet ind som en patch - se fx. https://github.com/dingproject/ting/pull/29.diff. Du kan også referere til det forkede repository i stedet for. I så fald skal du være opmærksom på, at projektet selv er ansvarlig for at holde projektets fork opdateret, så I får efterfølgende opdateringer og fejlrettelser med.

Udvidelser i form af nye selvstændige moduler

Hvis biblioteker, projekter eller leverandører giver sig i kast med at udvikle nye moduler til Core-team gerne bidrage med råd og vejledning så modulerne fra start af integrerer på bedst mulig måde.

Hvis et modul skal indgå som en del af DDB CMS/ding2 skal følgende procedure føgles:

  1. Send en mail til Core-team på dingcore@ting.dk med link til repositoriet på github.com.
  2. Core-team laver et fork, foretager et review af koden og laver evt. et pull request tilbage til dit repository med ændringer og kommentar.
  3. Efter evt. kommentarer og kodeændringer er blevet accepter og diskuteret, vil Core-team lave et fork over i DDB CMS, hvor efter dette vil blive det nye repository for udvidelsen

Hvis Core-team bliver opmærksomme på ændringer eller udvidelser foretaget af et lokalt bibliotek forebeholder vi os ret til at hive kode fra biblioteket ind under hovedsporet.

Håndtering af lokale ændringer

Det er ikke alle ændringer eller forslag om bidrag til DDB CMS/ding2, der vil blive accepteret.

Dette gælder eksempelvis ændringer, der er bundet så tæt op imod ét bestemt DDB CMS site, at de ikke kan benyttes til andre DDB CMS web-sites. Dette gælder specielt ændringer, der ligger sig tæt op af udformningen af temaet til sitet. Dette kan eksempelvis være i form af sidestruktur, grafik og farver. En sådan ændring eller udvidelse bør forblive i det lokale projekt, det er udviklet til.

Hvis du gerne vil bibeholde en ændring, som ikke er blevet accepteret af Core-team, kan du opdatere projektets ding.make fil og referere til det forkede repository i stedet for. I så fald skal du være opmærksom på, at projektet selv er ansvarlig for at holde projektets fork opdateret, så I får efterfølgende opdateringer og fejlrettelser med.

Uenigheder

Core-team beslutter suverænt, hvilke ændringer af teknisk karakter, der vil blive accepteret og hvilke der forbliver lokale ændringer. 

Hvis en ændring har forretningsmæssig karakter, og der opstår uenigheder omkring en given ændring, vil Core-team tage dette op med DDB, som har den endelige beslutningskraft.