Iterace 3 zadavatel dotazy » Historie » Revize 2
Revize 1 (Štěpán Faragula, 2025-03-27 13:54) → Revize 2/3 (Štěpán Faragula, 2025-03-27 21:44)
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 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 Redmina 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ý