search

VNG-Realisatie / api-beheer

Repository met beschrijving van het beheer van (ZGW) API specificaties
2 stars 0 forks source link

Github beheer #68

Open ehotting opened 5 years ago

ehotting commented 5 years ago

Mag ik dit hier dumpen?

https://github.com/orgs/VNG-Realisatie/projects/2

Ooit een paar taken aangemaakt die projectoverstijgend zijn, nooit opgepakt. Valt niet specifiek onder "API beheer" maar moet wel iets mee gebeuren.

TCIMEddy commented 5 years ago

Goed punt van Eelco. Graag prio en visie

melsk-r commented 5 years ago

@ehotting Eelco, kan je de taken nog wat toelichten?

michielverhoef commented 5 years ago

Waarschuwing: onderstaande zijn allemaal aannames!

Ik denk dat 3rd party apps dingen als plugins voor Slack, Trello etc. zijn. Het fijne weet ik er niet van maar het zou kunnen dat iemand geen toegang heeft tot een repository maar via een Slack kanaal ineens wel dingen kan zien die hij/zij niet mag zien. Of iets in die geest. Een andere plugin kan bv zijn de integratie met een IDE (Eclipse, Visual Studio etc.).

De link met API beheer is (denk ik) meer dat de beheerders van de standaarden ook verantwoordelijk zijn voor (de integriteit en inhoud van) de repositories en toegang daartoe. Dat leidt tot het autorisatie protocol. Denk aan 2FA maar ook wie krijgt wel/geen schrijfrechten? Is er naast een beheerder ook (minstens) een reserve beheerder van de repositories?

Ballotage: misschien de beslissing wat wel en wat niet in een bepaalde repository thuis hoort? Je zou het een soort in/out-of scope kunnen noemen. Bijvoorbeeld de code van de referentieimplementatie bij een standaard. Staat die in een eigen, aparte repository of binnen de repos van de standaard?

Een andere vorm van ballotage: hoe gaan we om met de besluitvorming rondom aanvullingen/wijzigingen op een standaard die in beheer is? Er is immers geen PO meer zoals bij de ontwikkeling van de standaard.

Maar of deze aannames kloppen mag @ehotting zeggen :-D

ehotting commented 5 years ago

Voor alles geldt, niet per sé een taak voor API beheer, maar er moet wel een beheerder van GitHub komen lijkt me. En wat regels. Team van API-beheer is in de toekomst (naar ik aanneem) de grootste gebruiker van GitHub, ik denk dat jullie het best de tool kunnen beheren.

  • Over wat voor third party apps heb je het eigenlijk?

Apps die toegang hebben tot repos in de GitHub organisatie van VNG-Realisatie. https://github.com/organizations/VNG-Realisatie/settings/oauth_application_policy Welke apps krijgen toegang, wat zijn de voorwaarden? Wat kunnen ze? Een policy zou mooi zijn.

  • Waar zouden deze apps rechten op moeten krijgen?

Dat hebben ze al. Teams, Unito, Trello, Office 365 etc. Kunnen er meer worden, wie bepaalt? etc.

  • Waar zit hier de link met API Beheer?

Iemand moet het beheren. :) Bij gemeenten worden generieke tools vaak beheerd door de grootste belanghebbende.

  • Waarvoor moet het autorisatieprotocol gelden? Bedoel je per GitHub repository?
  • Waar denk je dan aan?

Per repo idd. Wanneer word je admin, owner, contributor, welke groepen zijn er, etc. Beetje uniform houden, anders wordt het chaos.

  • Wat bedoel je met de conventies?
  • Noem eens wat voorbeelden m.b.t. vorm, stijl en ballotage?

Bijv. naamgeving van de repositories. Hoe herken je repos die bij elkaar horen? Hebben standaarden altijd een herkenbare, vergelijkbare naam? Alles in kleineletters of CamelCase? Met dashes of underscores? Welke licenties gebruiken we in welke gevallen?

Ballotage: Wanneer accepteer je een repo onder de organisatie VNG-Realisatie en wanneer niet? Welke status hebben deze repos? Wat betekent het dat een repo onder organisatie VNG-Realisatie gepubliceerd wordt?

melsk-r commented 5 years ago

Ok, dat geeft al wat meer duidelijkheid. Ik ga nadenken over een visie.