Ændringsønsker

Har du ideer til nyudvikling eller tilpasninger af eksisterende funktionalitet i KU's eksterne web og CMS TYPO3?​ Du er velkommen til at komme med forslag, der kommer slutbrugere og/eller webredaktører til gode.

Når du sender et ændringsønske ind via vores formular, kommer ønsket automatisk ind på vores Trello-board, hvor alle forslag og ideer er samlet.

Vi gennemgår løbende alle forslagene og ideerne på Trello-boardet, og prioriterer dem ud fra behov og ressourcer.

Du vælger selv, om du vil skrive dit forslag på dansk eller engelsk.

Send ønsker og idéer ind for TYPO3

FAQ om fejl og ønsker

1) Tjek om ønsket allerede findes på Trello-boardet “Ændringsønsker til ku.dk TYPO3 CMS”.

  • Hvis du har tilføjelser eller kommentarer til et eksisterende ønske, send en mail til web@adm.ku.dk.

2) Dokumentér tydeligt, hvad ønsket handler om, med eksempelsider, screenshots og links.

3) Beskriv meget gerne forslag til mulige løsninger. 

Jo mere konkret du er, jo nemmere bliver det for os at prioritere ønsket.

Hvad er en fejl?

En fejl er, når systemet ikke fungerer, som det skal. Det kan for eksempel være en funktion, der ikke reagerer korrekt eller giver et forkert resultat.

Hvad er et ønske?

Et ønske er, hvis systemet er uhensigtsmæssigt, mangelfuldt eller besværligt, men teknisk fungerer, som det er designet til.

Oplever du, der er fejl i systemet, skal du sende en mail til web@adm.ku.dk

Den hurtigste og bedste måde, fejl kan rettes, er med konkrete beskrivelser af hvad, hvor og hvornår - og meget gerne med links/screenshots af processen. Det gør det hurtigere at fejlsøge problemet og finde frem til en løsning.

Når du har meldt en fejl ind til til web@adm.ku.dk, bliver den vurderet af den postkasseansvarlige i KOM Web og Visuel Identitet. Afhængigt af typen og alvoren af fejlen bliver den enten:

  • sendt direkte til en udvikler og tilføjet til dennes opgaver,
  • prioriteret op imod andre fejl, hvor en gruppe i CMS-projektet vurderer, hvornår den skal løses.

Når du melder et ønske ind via ovenstående formular, kommer det ind på Trello-boardet ‘Ændringsønsker til ku.dk TYPO3 CMS’.

Her gennemgår og behandler en gruppe i CMS-projektet ønskerne for at vurdere og estimere omfanget af løsningen.

Der er stadig fuld gang i CMS-projektet med udvikling og migrering fra det gamle system (Obvius). Derfor kan der gå noget tid, før nye ønsker tages ind.

Alle TYPO3-redaktører får adgang til Trello-boardet ‘Ændringsønsker til ku.dk TYPO3 CMS’. I boardet bliver alle ønsker og ideer behandlet og fordelt i følgende kolonner:

Indbakke

Ønsker, som er nye og mangler at blive gennemgået og estimeret af en gruppe i CMS-projektet.

Afventer

Ønsker, som kræver yderligere afklaring, før de kan gøres klar til udvikling. De kan være placeret her af forskellige grunde, for eksempel:

  • ‘Research solution’: Der skal afklares en løsning, der passer ind i resten af TYPO3-installationen.
  • 'Development costs': Eksterne udviklere skal estimere omfanget og kompleksiteten af opgaven.
  • ‘Web administration’: Ønsket kræver en beslutning i forhold til web governance.
  • ‘Core TYPO3’: Ønsket handler om TYPO3’s grundopsætning (core) eller extensions, og det kræver en løsning derfra.

To do

Ønsker, som er prioriteret og klar til udvikling. De er vurderet efter en RICE-score* og har fået angivet det primære ressourcetræk. 

*RICE-score er en prioriteringsmetode, hvor hvert ønske vurderes ud fra: 

  • Reach – hvor mange brugere det vil påvirke.
  • Impact – hvor stor en forskel det vil gøre.
  • Confidence – hvor sikker vurderingen er.
  • Effort (Estimate) – hvor mange ressourcer løsningen kræver. 

En høj RICE-score betyder, at løsningen bliver vurderet til at have stor effekt i forhold til indsatsen – altså en god business case.

In progress 

Ønsker, som er under udvikling i det igangværende eller et kommende sprint. Ønskerne er udvalgt ud fra prioritering og de tilgængelige ressourcer i sprintet.

Done

Ønsker, som er færdigudviklede og implementeret i produktionen.

Ikke planlagt i nær fremtid

Ønsker, som for nu ikke er planlagt til udvikling. Det er enten fordi, løsningen:

  • Modstrider eksisterende funktionalitet eller dokumenterede brugerbehov
  • Vil kræve uforholdsmæssige store udviklingsressourcer.