Project

General

Profile

Actions

Proces for at bidrage til DDB CMS

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/issues/new, der beskriver fejlen. Beskrivelsen skal kunne forstås af udviklere såvel som af 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 hovedsporet. Herefter gennemføres en test, inden en ny release af DDB CMS / ding2
  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 hovedsporet.
  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 eller leverandører giver sig i kast med at udvikle nye moduler til DDB CMS vil 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 core / DDB CMS skal følgende procedure føgles:

  1. Lav en ticket i http://platform.dandigbib.org/projects/ddb-cms/issues/new, der beskriver det/de ny(e) modul(er). Beskrivelsen skal kunne forstås af udviklere såvel som af biblioteksansatte, som senere skal teste modulet/modulerne.
  2. Send en mail til core-team på dingcore@ting.dk med link til repositoriet på github.com.
  3. core-team laver et fork, foretager et review af koden og laver evt. et pull request tilbage til dit repository med ændringer og kommentar.
  4. Efter evt. kommentarer og kodeændringer er blevet accepter og diskuteret, vil core-team lave et fork over i hovedsporet, 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 forbeholder 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 hovedsporet, 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 i DDB CMS/ding2 core. Dette gælder specielt ændringer, der lægger 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.

Updated by Gitte Barlach about 4 years ago · 2 revisions