ASWI - Pokročilé softwarové inženýrství » ASWI 2025 » Dolování dat z ALM nástrojů do SPADe databáze (Pícha) - SKIBIDI OHIO RIZZLERS

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ý