3. iterace - Schůzka se zadavatelem ohledně technických dotazů 2¶

Informace o schůzce¶

• Datum: 1.4.2025
• Čas: 10:00 - 11:00
• Forma: online přes Teams

Účastníci:¶

• Bc. Jakub Pavlíček, jpvlck@students.zcu.cz
• Bc. Štěpán Faragula, farag844@students.zcu.cz

Poznámky ze schůzky¶

1. Jak máme uložit data do tabulky project? Je startDate datum prvního commitu?
   • Ano, startDate je datum prvního commitu.
   • Ne každé ALM má svůj vlastní koncept pro startdate, máme vzít jakékoliv první datum čehokoliv (první commit / první změna v projektu čehokoliv)
     • startDate máme uložit na konci dolování až po tom, co budeme znát všechny work_item a configuration
     • Na konci vybereme položku s nejnižší hodnotou
2. V tabulce work_unit je atribut progress nastavený na NOT NULL, jakou hodnotu zde máme nastavit pro GitHub pumpu?
   • Máme nastavit 0, tak jak děláme teď
3. Máme dodržovat strukturu dat v ukázkových datech? Např. že URL GitHub projektu končí koncovkou .git či název project_instance obsahuje i datum.
   • Je to jedno, ale u Git pumpy to dává smysl, u GitHub pumpy to může být jinak
     • Dříve bylo nutné zadat .git kvůli knihovně JGit, protože to procházelo Git pumpou, když se repository muselo stáhnout na lokál
   • Datum u project_instance = datum těžení (nemusíme vyplňovat, sloužilo pro debug, můžeme ignorovat)
4. Můžeme v tabulce project_instance do atributu description dát text z About na GitHubu? Tento text je uložen v atributu description tabulky project, takže bychom ho ukládali i zde (tj. project_instance.description by byl stejný jako project.description).
   • Může být v obojím
   • Otázka, jestli dávat podle délky (nejdelší popis je správný), nebo appendovat -> víc detailnější
     • Na description nebude žádná analýza viset, jde spíš o orientační záznam a lepší vědět co nejvíce informací (appendování)
   • project_instance může mít každá jiný název, u těch se vezme nejdelší možné jméno (dobrá heuristika, fungovalo dříve)
5. V tabulce role jsou uloženy role (v případě GitHub repozitáře), které se nepoužívají, např. documenter, tester apod., máme je tedy také vždy vytvářet? Můžeme v GitHub pumpě mapovat roli Contributor na SPADe Developer?
   • Ano, je to tam z důvodu, když se chtějí lidi po těžení přemapovat
     • Člověk reálně ví, jaké role zastává a měli bysme umožnit přemapování dat, když už budou v databázi a budou se nad nimi dělat analýzy
   • I u ostatních enumů bysme měli vytvářet všechny
     • Dává smysl u stavů, resolutions
     • Priority nejspíše ne
   • Contributor a developer dává smysl
6. Máme počítat s tím, že Git pumpa se bude spouštět také na lokálním repozitáři, tj. bez zadaného URL?
   • Není pro to rozumný usecase, i kdyby chtěl uživatel těžit na lokále, tak repozitář spíš zvěřejní online a vytěží
     • Důvod: na lokále jsou necommitované změny a ty nás nezajímají
7. U Git pumpy, do jaké tabulky máme ukládat změny souborů (tj. smazán, přidán, upraven)? Co všechno by měla Git pumpa umět? Naše zatím umí dolovat: Identity, Person, Commit, Tag, Branch, Project, ProjectInstance a ToolInstance.
   • work_item_change -> atribut name
   • U čistě gitové pumpy není nic jiného co by se dalo těžit, takhle stačí
   • Configuration person relation se dá najít přes parsování řádků na commit message
     • Lze se spoléhat na formát, kde je na konci commitu je "Reviewed by: ...", můžeme splitnout dvojtečkou a vzít člověka
8. V GitHub pumpě, jak máme těžit tabulky iteration, phase, milestone? U iteration a phase jsou v ukázkových datech stejná data, proč? V milestone není nic, proč? Když GitHub milestone nemá žádný issues, máme milestone i tak těžit?
   • Data u phase a milestone jsou stejné kvůli testům
   • U těchto dvou položek je lepší je dávat do iterace, protože to více odpovídá skutečnému kontextu.
     • Vše dáme do iterace, zbytečné dávat data do obou
   • Milestones neřešíme vůbec
     • Velmi zřídka se dá najít koncept v ALM který by jim odpovídal
     • Spíše odpovídá popisu na Wiki a to je moc složitý koncept těžení
     • Uživatel si dodefinuje sám
   • Když github nemá issues, i tak to máme těžit, je to zajímavá informace
9. Když ukládáme časy do tabulek, máme vždy používat časová pásma těch akcí, nebo naše? Tj. issue.createdAt() = "Mon Jun 01 19:10:43 CEST 2020" -> “2020-06-01T19:10:43Z" s Timezone, nebo "2020-06-01T17:10:43Z" bez Timezone (tj. -2 hodiny).
   • Bez timezone a vše máme převést na UTC
   • Lidé mohou commitovat z různých timezone, takže je potřeba standarzidovat
10. Jaký význam má relace mezi work_item a configuration?
    • id w_i = id configuration
      • Relace 1:1
    • configuration je jeden z typů work itemu (speciální typ work_item)
      • configuration je stejné rozšíření wor_itemu stejně jako je work_unit rozšíření work_itemu
      • configuration obená = změna ticketů/artefaktů
      • commited = worklog (kdy se vytvořil záznam, kdy se strávil ten čas, to může být i zpětně)
    • v PDF je hierarchická struktura mezi configuration

Autor: Štěpán Faragula
Datum: 1.4.2025
Stav: hotový