Projekt

Obecné

Profil

Akce
Historie

Wiki » Průběh 3 iterace »

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:

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
  1. 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
  2. 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
  3. 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
  4. Proč je v tabulce "tag": externalID – někdy "tag SHA" a někdy "commit SHA"?
    • Annotated = tag
    • Unannotated = commit
  5. 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
    • 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
  6. 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)
  7. Můžeme pak udělat pseudonymizaci 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 pseudonymizaci?
    • 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 pseudonymizace)
  8. 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
  9. 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 18 hodin(y) · 5 revizí