Projektdiskussion:Utvecklingsstöd 2020/Förslag på riktlinje för underhållsansvar för utvecklade verktyg och tjänster

I brist på bättre plats att fånga denna tanke

Vi diskuterade hur man, utöver den tilltänkta listan, kan tydliggöra när en tjänst inte längre är underhållen.

För webbtjänster funderade vi på om man kan lägga till någon standardiserad liten banner (som kan uppmana någon att adoptera tjänsten).

För kodrepon är det nog lämpligast att arkivera dessa, de är då fortfarande tillgängliga kan forkas men man kan inte lätt bidra till huvudrepot. Notera att det finns repon som inte täcks av denna rutin som det inte är lämpligt att arkivera (helt interna verktyg som används) samt andra som kan vara lämpliga att arkivera (one-off kod för gamal batchuppladdnign)

Jag funderar på om det inte bör finnas en del som behandlar hur/när/om vi tar över underhållet från någon annan. Typ ett verktyg vi själva använder väldigt mycket och där FOSS-utvecklaren inte längre underhåller det eller där det finns behov av stöd för att klara underhållet, till exempel skulle det kunna bli fallet med Program & Event Dashboard eller Phabricator i framtiden. Projektet FOSS för föreningen syftar ju i dagsläget på ny funktionalitet genom punktinsatser.

Det blir ju även mer relevant om vi får en större global roll runt verktyg kopplade till innehållspartnerskap (typ verktyg för massuppladdningar/-redigeringar, statistik etc.)

I introt står det att det sker. Jag tänkte alltså hur det sker. Vad har vi för riklinje runt det?

Jag tycker också att det kan vara värt att fundera på begreppet "ta över" då det kan uppfattas exkluderande. Vad föreningen antagligen vill göra är att "vårda" verktyget och säkerställa dess funktionalitet tills att det finns flera utvecklare som kan hjälpa till.

• Införa möjlighet att långtidsbetala för domännamn för att förhindra övertagande från reklamsidor.
• Skapa en landningssida för pensionerade domäner vi behåller genom långtidsbetalning där de omdirigerar till oss.
• Uppdatera Lista över domäner med pensionerade/övergivna (när det blir aktuellt) så det framgår att vi har haft dom men inte längre ansvarar för innehåll där.

Mycket bra tankar. Även om den första är bra för att minska risken, så behöver ändå någon process följas eftersom att det då kommer vara ännu längre mellan gångerna det behöver göras.

Jag funderar om inte processen hur ni kommer fram till en viss underhållsnivå skulle kunna beskrivas lite fylligare? D.v.s. vad ni gjorde när ni fyllde i kolumn I i inventeringsdokumentet av verktygen.

Det slog mig att det skulle vara bra att prata om prototyper i dokumentet. Främst för att klargöra att 1) det är ok med prototyper, 2) prototyper alltid har har högst underhållsstatus 2, 3) det är inte en prototyp längre om du börjar integrerar den i arbetsflöden.

En tanke med detta dokumentet vara att tydliggöra kostnaden av att bygga saker quick and dirty då underhåll blir svårt och tillhörande kostnader lätt blir större än den som skulle uppstått om man la mer tid under initial utveckling. Men en prototyp ska i sin natur vara quick and dirty då den aldrig är tänkt att användas för annat än att illustrera idén/metoden.

Har funderat lite på det här och jag tror att det vettigaste lösningen är att lägga till en rubrik specialfall under Hur länge underhåller vi tjänster eller möjligen mellan denna och Hur vi hanterar end-of-life.

Under denna kan vi uttryckligen beskriva följande specialfall som samtliga faller under underhållsnivå 0

• Prototyper (typ Tastydata)
• Aldrig slutförda/lanserade tjänster (typ 3d2Commons)
• Tjänster under utveckling (typ WIkispeech)