Akce
3. iterace - Schůzka se zadavatelem ohledně technických dotazů¶
Informace o schůzce¶
- Datum: 27.3.2025
- Čas: 13:30 - 14:00
- Forma: prezenčně u zadavatele
Úč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
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
- 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
- configuration_person_relation = podpisy commitů
- 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)
- Dřívější zkušenosti s dolováním:
- 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ý
Aktualizováno uživatelem Štěpán Faragula před asi 19 hodin(y) · 3 revizí