Jak radzić sobie z dużymi zadaniami?

[qaziok]

Problem

Wyszło w komentarzach pod #13, że nie do końca mamy plan jak radzić sobie z dużymi zadaniami i jednocześnie sensownie zbierać ich dokumentację i progres. Do sprawy można podejść na wiele różnych sposobów, dlatego fajnie by było jakby każdy mniej więcej wyraził swoje zdanie i jak to widzi.

Rozwiązania

Pojawiły się wstępnie dwa rozwiązania:

• Issues in issues - rozwiązanie które zaproponował @jankejc, które oparł na tym przykładzie. Bardzo dynamiczne i łatwo edytowalne z możliwością łatwego linkowania innych issues czy pull requestów. Do tego możliwość zrobienia dynamicznych checkboxów. W takim przypadku takie zadanie musi być odłączone od projektu (albo duże zadania dostałyby swoją własną kolumnę) i pozbawione wszelkich milestonów (co trochę zabija pilnowanie terminów, bo raczej duże zadania też mają deadline).

• Issues in wiki - rozwiązanie z którego inicjatywą wyszedłem ja, jako przechowywanie dużych zadań w postaci strony na wiki. Rozwiązanie z kontrolą wersji, przechowywane niezależnie od zadań wraz z całą pozostałą dokumentacją. Problemem pojawia się zmienność strony, gdyż przy każdej zmianie potrzeby jest commit, więc dynamiczne checkboxy odpadają (co prawda można je zmienić przez markdown). Zadania też można oznaczać jedynie w postaci linków [nazwa czy #NUMER](../issues/NUMER).

Obie metody można na pewno ze sobą połączyć np. dokumentacja w wiki, a progress zadań w issue, ale to element do przedyskutowania na forum.

Bonus

Nie jestem pewien czy to do końca spełnia potrzeby wyżej wymienionych rozwiązań, ale wpadł mi do głowy pomysł z użyciem milestones - zyskujemy wtedy deadline na zadanie i ma to w sobie elegancki podgląd na wszystkie włączone issues. Problemem może stać się dokumentacja, bo jednak miejsca jest tam niewiele, ale od czego jest wtedy wiki.

Pozdrawiam gorąco
@qaziok
2:05

[jankejc]

Tak podjęty issue budzi moje uznanie. Dobrze wyciągnąłeś najważniejsze aspekty z mojego punktu widzenia. To miłe. Ogólnie zgadzam się, że każde podejście ma swoje plusy i minusy, i czego byśmy nie wybrali to musimy liczyć się z pewnym ręcznym rozwiązywaniem pewnych kwestii.
Jeśli chodzi o duże problemy to faktycznie nie da się ich za bardzo upchnąć w milestony. Tutaj pewnie trzeba by jakoś stworzyć terminy ręcznie i ich pilnować. Jeśli jednak chodzi dokładnie o #13 to akurat tu by się zgadzało podejście bezterminowe, albo choćby "luźno-terminowe". Podchodzę do tego zagadnienia tak, że teraz głównie skupiamy się na AI, ale jako, że jestem bardziej od apki, to swoje gdzieś tam w tle mogę już zacząć, ale bez większej presji z możliwością pomocy wam w całym etapie AI.
Tutaj też wchodzi temat harmonogramu, który trzeba by było jakoś ustalić i potem zatwierdzić u opiekuna.

Po dłuższym researchu (dostęp do branchy w wiki, branche w wiki, ogólny sposób na push lokalną wiki, pull request dla lokalnej wiki) dochodzę do wniosku, że ta druga opcja byłaby dla mnie do zaakceptowania, ale dość uciążliwa... Chyba, że normalnie możemy działać na wiki w mainie? Wtedy w md można edytować faktycznie te listy i tak dalej, i tylko linkować je do issues. To byłbym w stanie luźno zaakceptować. Wtedy doku (choćby funkcjonalności) pisze się bezterminowo, a jak trzeba będzie coś przyspieszyć to doda się koknretne issue (z danego page'a wiki) do milestonów i tyle.