Vraagje! Bij het samenwerkingsplatform van het Federatief Datastelsel: federatief.datastelsel.nl werken we met Gitlab, momenteel zijn we behoorlijk veel zaken aan het inregelen in git, maar is het voor mij een eerste keer werken hiermee. Is er iemand betrokken geweest bij de inrichting van gitlab/github die specifiek bezig was met gebruik van versionering en labels bij diverse pagina’s? In Git zijn er genoeg opties en er zullen vast al veel projecten voor gegaan zijn die dit hebben uitgezocht en waar wij van kunnen leren en waar standaard processen/methodes voor zijn. Kortom, wie kan een best practice delen over versionering van content (op basis van nieuwe inzichten of feedback) in git die wij kunnen toepassen?
Ha Lisa! Welkom op ons forum.
Ik snap je vraag nog niet helemaal. Het toevoegen van labels / versionering van content kan op een hele hoop manieren, afhankelijk van hoe jullie website gebouwd is.
Voor WIP (work in progress) zou je het concept van een Merge Request kunnen gebruiken. Meer hierover vind je bijvoorbeeld hier: Merge requests | GitLab.
Misschien is het ook een idee om met je vraag naar onze samenwerkdag te komen: Opensourcewerken. Daar kan je eventueel helpen met je vraag, maar lopen ook andere Git-kenners rond
1 like
Dank je wel! Ik begrijp dat versionering vaak gebeurt op basis van software wijzigingen, maar ik bedoelde versionering op de content die we zelf aanbrengen. Dus ik zoek vooral naar andere overheidsprojecten die met gitlab werken om eens van zienswijzes te wisselen. Ken jij er een paar? Ik ga kijken of ik kan aanhaken, donderdagen zijn vaak lastig maar hopelijk volgende keer!
1 like
Ik heb niet direct goede voorbeelden. Maar weet dat het inderdaad een prima oplossing kan zijn. @jgroenen ken jij nog voorbeelden?
Hi @lisa.vanderheijden @tomootes Ik heb toevallig deze week de eerste versie van een Nederlandse vertaling van de Standaard voor Publieke Code (Leidraad voor open source werken in publieke organisaties, Community Translations of the Standard for Public Code) naar de printer gestuurd. Voor de proefversie heb ik een release tag gemaakt, en voor de versie die ik het ingestuurd nog eentje (zie Release Standaard voor Publieke Code versie 0.8.0-nl-0.1.1 · codefornl/community-translations-standard · GitHub) In het traject naar die release toe, heb ik bijvoorbeeld met @MauriceHendriks samengewerkt aan/in een pull request branch met zijn suggesties en toen die klaar was, is die gemerged met de main branch (Suggesties ter verbetering by MauriceHendriks · Pull Request #3 · codefornl/community-translations-standard · GitHub).
Github zelf versioneert natuurlijk iedere commit, dus je kan altijd door de versiegeschiedenis heen lopen (wat is op welk moment door wie gewijzigd) en door de “blame” (in een bestand, per regel: wie heeft de laatste wijziging aan die regel gemaakt, bijv. Blaming community-translations-standard/nl/GOVERNANCE.md at main · codefornl/community-translations-standard · GitHub).
Als het gaat om het loskoppelen van inhoud en code, dan heb ik bijvoorbeeld een setup waarin ik een kennisbank (Obsidian, maar dat is op zich niet super relevant) bijhoud in de ene repository, en die kennisbank teksten gebruik in een andere repository om een website op te bouwen. Daar kan ik wel wat van laten zien (maar staat momenteel dicht).
Een voorbeeld waarin BZK momenteel werkt aan beleid op Github is de repo: GitHub - MinBZK/Algoritmekader: Het ministerie van BZK gaat aan de slag met een Algoritmekader. Het doel daarvan is om overheden op praktische wijze te ondersteunen, zodat zij op een wettige en ethisch verantwoorde wijze algoritmes en AI-systemen gebruiken.
Voor het samenwerken aan publieke code (dat kan zowel beleid zijn of software broncode), is de standaardvoorpubliekecode.org en de community daaromheen sowieso een aardig begin voor dit soort gesprekken.
1 like
Dank! Dit helpt, mag ik je wellicht keer gewoon bilateraal wat vragen stellen?