Iterace 3 zadavatel dotazy » Historie » Revize 4
Revize 3 (Štěpán Faragula, 2025-04-02 18:33) → Revize 4/5 (Štěpán Faragula, 2025-04-25 19:28)
h1. 3. iterace - Schůzka se zadavatelem ohledně technických dotazů ---- h3. Informace o schůzce * *Datum: 27.3.2025* * *Čas: 13:30 - 14:00* * *Forma: prezenčně u zadavatele* h3. Účastníci: * Bc. Jakub Pavlíček, jpvlck@students.zcu.cz * Bc. František Urban, furban@students.zcu.cz * Bc. Štěpán Faragula, farag844@students.zcu.cz h3. Poznámky ze schůzky Zadavateli jsme předvedli náš pokrok v iteraci. * *Dokument architektury* - vypadá ok, zadavatel to projde podrobně později * *React GUI* - ok * *Popis tabulek SPADe* - ok * *Kód* - rozhraní je ok, zadavatel navrhl, že můžeme mít i oddělené rozhraní pro bugtrackery a repository Dále jsme se zeptali na dotazy # Musíme nutně v Git provider pumpách využívat čistou Git pumpu? Některé knihovny Git providerů totiž umí všechno, co umí i Git pumpa. ** Není nutné, dnešní API jsou propracovanější než dříve # Do konce TSP1 máme mít hotovou Jira, Git a GitHub pumpu. Myslí se tou Git pumpou i to, že jí půjde spustit samostatně, nebo se předpokládá, že od ní budou dědit Git providers pumpy (např. GitHub, GitLab)? ** Bylo by to dobré, protože pak můžeme dolovat i repository, co nejsou na GitHub a jsou jenom lokálně na Git ** Git pumpa by měla jít spustit samostatně, i když z ní nedostaneme všechna data ** Git můžeme klidně použít u pumpování GitLab, je to dobrý nápad # Co je to tabulka "work_unit" - popř. když je v relaci s "commit", tak to znamená, že commit message je uložena v tabulce "work_unit"? ** Tickety/issues v bugtrackeru ** Nějaká část jejich atributů je děděná z work itemu, kde jsou uložené specifické atributy POUZE pro tickety ** Plnohodnotný item -> musíme udělat join pro "work_item" ** Nevadí, když všechny atributy nevyplníme # Proč je v tabulce "tag": externalID – někdy "tag SHA" a někdy "commit SHA"? ** Annotated = tag ** Unannotated = commit # Jaký význam má tabulka "configuration_person_relation" a co znamenají její atributy? V data.sql nejsou ukázková data, hádáme, že se zde rozlišuje autor a committer commiter ** configuration_person_relation = podpisy commitů *** Na GitHub reviewed by, modified by atd. *** Jde vidět, že i jiný člověk dělal změny v commitu a ne jenom jeho autor *** Např. autor commitu v jednom branch, při merge do jiný branch se udělá commit pod někým jiným ** configuration = JSet, sada několika změn "work_item_change" ** work_item_change = změna jednoho itemu přes několik atributů "field_change" ** field_change = změna 1 konkrétního atributu v ALM itemu # Když tabulka "person" znázorňuje osoby podílející se na projektu, jak je máme získávat? Identity získáme z ALM nástrojů, ale jak získat "person"? Máme z "identity" vzít unikátní atributy (tj. celá jména osob) a z toho vytvořit "person"? ** Dřívější zkušenosti s dolováním: *** Nejprve se vytahali všichni team members a dala se jim role tak jak je mají na ALM (developer, maintainer) *** Postupně se pak přidávali lidi, co se objevovali v commitech a issues, kteří nebyli jako členové týmu *** Identity se slučovali až když bylo jisté, že jde o stejnou osobu ** Můžeme nejdřív udělat přiřazení 1:1, až si budeme jistí, že se opakuje víc osob, tak podle heuristiky sloučit do jedné *** Stejný email a jiný username -> můžeme spojit *** Stejný username a jiný email -> podívat se, jestli se shoduje část emailu před zavináčem ** Je lepší mít mapování 1 identita 1 osoba, než přiřadit špatně ** Někdy lidi dávají do políčka pro celé jméno username *** Osvědčilo se, že delší celé jméno, než nickname je skutečné jméno (většinou fungovalo) # Můžeme pak udělat pseudonimizaci tak, že data nejdříve uložíme plaintext do databáze a až pak na ně pošleme anonymizace? Že uložíme čistá data a pak uděláme UPDATE na tyto data pro pseudonimizaci? ** Ano, případně to i bude součástí budoucích vylepšení (nahraje se do databáze, vypadne server, neproběhne preprocessing a data jsou uložená bez pseudonimizace) # Tabulka "role", když GitHub má role jen pro oragnizace a tyto role jsou: ADMIN a MEMBER, stačí ty role takto anebo se tím myslí přístupová práva, jako ADMIN, WRITE, READ, NONE? Na získání práv uživatele nemáme dostatečná práva – potřebovali bychom ADMIN roli v daným repu. ** Stačí ADMIN a MEMBER # Tabulka "people_group", myslí se tím "team" na GitHubu? ** Může být, v Redmine takový koncept ani není ** Není podstatné pro těžení Nakonec jsme se se zadavatelem domluvili, že *prodloužíme iteraci o jeden týden*, abychom mohli pořádně zapracovat na pumpách a uzavřeli tak milník LCA. Zadavatel s touto změnou souhlasil. ---- Autor: Štěpán Faragula Datum: 27.3.2025 Stav: hotový