PRIORYTETY grupy "Madagaskar" na 2 półrocze 2015 - etap 1 z 2 (DYSKUSJA)

W związku z sugestiami (w poprzednim) wątku reorganizacji projektu uruchamiam akcję analogiczną do tej z końca 2014 roku - zaproponujemy, przedyskutujemy a na końcu przegłosujemy najnowsze priorytety w projekcie "Madagaskar".

W tym wątku jeszcze nie głosujemy (to będziemy robić w kolejnym etapie). Kto ma ochotę niech zgłasza swoje pomysły na reorganizację projektu, nowe kierunki działania i wszystko to co wyda mu się ważne dla funkcjonowania "Madagaskaru".

Można też ustosunkowywać się do propozycji innych (prowadzić dozwolony lobbing), np. otwarcie popierać czy sprzeciwiać się (+argumentować) propozycjom innych uczestników.

Miłej "zabawy"  (czekam na propozycje) !

To może ja pierwszy :p.

Moje propozycje nowych priorytetów w "Madagaskarze".

1. Obsadzić  ROLE w projekcie OCHOTNIKAMI - przy czym podkreślam że to nie moja tylko Wasza propozycja , którą zgłosiliście w poprzednim wątku. Osoby które podejmą się wybranych ról, tym samym odciążą mnie z części a może nawet większości operacji utrzymujących organizm "Madagaskaru". O tym jakie byłyby to role , dogadamy potem w kolejnym dedykowanym wątku na forum (ale wtedy jeżeli ta propozycja zostanie przez Was przegłosowana). Przykłady takich ról (żebyście wiedzieli co mam na myśli) to np - a) koordynator mailowego ruchu egzaminacyjnego b) koordynator gałęzi produkcyjnej warsztatów c) koordynator gałęzi deweloperskiej itd.
   
2. Znowu zmienić format NOWYCH (produkowanych) warsztatów - tu już chcę pojechać kompletnie po bandzie - chciałbym aby od warsztatu 17 laborki już w ogóle NIE uczyły programowania poprzez opracowania , ale tylko i wyłącznie egzekwowały wiedzę z programowania poprzez egzaminy. Tym samym warsztaty 17+ będą składały się z a) kompletnej aplikacji treningowej b) max 3 stronicowego (tym samym zwięzłego) dokumentu opisującego czym charakteryzuje się aplikacja treningowa c) specyfikacji aplikacji na zaliczenie wraz ze szczegółowymi wymaganiami co do kodu d) egzaminatora który będzie czekał na kolejne podejścia do egzaminu :p ... tym samym "Madagaskar" w gałęzi szkoleniowej przestanie od warsztatu 17 uczyć studenta wiedzy a będzie tylko i wyłącznie ujednolicać standard programowania wśród uczestników (poprzez egzaminy.) To oznacza że przebieg produkcji laborek będzie się składał tylko z etapów za które zawsze braliście się chętnie: tzn. 1.dogadania zakresu wiedzy na kolejny warsztat 2. wyszukanie przykładowego zestawu linków z opracowaniami dot. wiedzy z warsztatu 3.oprogramowanie aplikacji treningowej i egzaminacyjnej 4.kontrola jakości kodu aplikacji treningowej 5.sporządzenie specyfikacji egzaminu ... szast prast, warsztat gotowy :p . Tu oczywiście znowu nie chcę z Wami teraz już dyskutować jak wyglądać będzie taki warsztat, ale jak zagłosujecie na moją propozycję (na głosowaniu za około tydzień) to detale nowego formatu laborki dogadamy w dedykowanym wątku na forum.
   
3. Skonfigurować środowisko deweloperskie do programowania zespołowego - to jest pierwsze, krytyczne zadanie do wykonania w naszej nowej gałęzi deweloperskiej które stoi nam w tej chwili w miejscu. Najprawdopodobniej celuję to w GitLaba. Jeżeli to nam się uda to nie tylko będziemy mieli drogę otwartą do robienia pierwszych, eksperymentalnych, zespołowych aplikacji. "Zabawniejsze" jest to, że będziemy mogli używać tego środowiska również do produkcji warsztatów tzn. kontrolę jakości kodu aplikacji szkoleniowej będziemy mogli przeprowadzać "bo bożemu", czyli narzędziem "code review" GitLaba. ... to jest coś co by mega podniosło "Madagaskar" na wyższy poziom (oraz podniosłoby reputację projektu)
   
4. Całkowicie upublicznić warsztaty w internecie - aktualnie mamy około 20 os. oczekujących na wejście do projektu (ponieważ mamy zapełnione wszystkie 100 slotów zespołu uczącego się laborek "Madagaskaru"). Umówmy się - warsztaty "Madagaskaru" nie są żadnym tajnym "rocket science" żeby je ukrywać w internecie. Jak w sposób niekontrolowany wyciekną do netu i się rozpropagują to też nie poniosę z tego tytułu strat (tym bardziej że super popularność naszych laborek w internecie raczej nam nie grozi ;p ). Po prostu - każdy kto przeczyta o projekcie będzie miał dostępny link do wszystkich materiałów. Każdy natomiast , kto będzie chciał mieć udziały w projekcie (czyli powalczyć o punkty w "rejestratorze" akcjami rozwojowymi) poprosi o konto na forum, do "rejestratora" i zacznie działać. Tym samy projekt będzie się składał z 1. max 100 os. zespołu studentów laborek (aktualnie nazywający się mylnie "zespołem programistów") w któym będzie obowiązywał aktualny reżim terminów zaliczania laborek 2. zespołu z kontem na forum i "rejestratorze" osób które postanowiły choć trochę "działać" w projekcie , oraz 3. tzw. "guestów" w projekcie mających dostęp do dokumentacji projektu ale nie mających ochoty rozwijać go oraz ew. uczących się z laborek na własną rękę (bez możliwości zaliczania egzaminów). Tym którzy mają obiekcje czy aż tak upubliczniać zasoby "Madagaskaru" odpowiadam argumentem , że bardziej obawiam się że hermetyczność projektu nas "zabije".
   

To by było na tyle z moich propozycji, czekam na Wasze

Moim zdaniem należałoby zacząć tworzyć aplikację do obsługi projektu w asp.net mvc. Przeniesienie do aplikacji zarządzania kursami. Hostowanie pomniejszych plików na serwerze lub podpięcie api google drive. Filmy z kursów przesyłane bezpośrednio przez stronę na YT za pomocą api. Przesyłanie kodu zaliczeniowego bezpośrednio przez stronę i delegowanie automatyczne bądź ręczne do odpowiedniej  osoby. Takie luźne propozycje aby sprecyzować cały zakres trzeba by było przysiąść i dokładnie ustalić co jest potrzebne.

Co do kursów i egzaminowania to myślę że pojedyncze warsztaty są za długie i zbyt rozwlekłe co wydłuża czas po jakim są one wypuszczane przez co projekt stoi w miejscu. Jeżeli chodzi o programy zaliczeniowe to wygodniejszym rozwiązaniem byłoby podawanie części kodu uczestnikom który mają dokończyć (zaimplementować brakujące rzeczy). Do tak przygotowanego kodu można by było wcześniej napisać testy jednostkowe co ułatwiłoby sprawdzanie poprawności działania kodu a egzaminator musiałby przyjrzeć kod tylko pod kątem estetyki kodu ewentualnie pod kątem optymalności danej implementacji.

Samodzielna budowa aplikacji na potrzeby projektu wymaga zbyt dużo czasu i wiedzy na ten temat. Lepiej skorzystać z gotowych rozwiązań. Oto moje propozycje:

1. Założyć stronę internetową projektu opartą na WordPress lub Joomla! i dostosować je do własnych potrzeb. Umieszczane były,by tam warsztaty, linki do materiałów, książek itd... Można by również umieszczać tam informacje/wiadomości z funkcją powiadamiania na email. Zastąpiło by to dotychczasowy mailing grupowy. Stroną mogła by zająć się jedna lub dwie osoby, które by to obsługiwały. Oprócz tego za pomocą wtyczek można by zautomatyzować proces egzaminowania warsztatów np. Wysyłanie kodu źródłowego do egzaminatora.

2. Nie ma co rezygnować z produkcji warsztatów. W końcu wiele ludzi ze względu na nie dołączyło do projektu. Moja propozycja rozwiązania to owszem tworzyć warsztaty w dokumtach PDF przez osoby, które mają wiedzę na ten temat, a potem szukać wśród uczestników, którzy mają zaliczony warsztat, ochotników będący wstanie przełożyć treść warsztatu z postaci tekstowej do postaci wideo.

3. Kwestie upublicznia warsztatów uważam za zbyt szybką. Jest ich mało. Uczestników mamy dość sporo, ale na razie należy zabrać się za ich produkcję tym bardziej, że jak mają one być wstawiane na youtube to muszą być robione w postaci wideo.

4. Ze środowiskiem deweloperskim też uważam, że na razie należy się wstrzymać. Nie tworzymy jako grupa żadnych projektów i bawienie się w Gity to strata czasu. Może za jakiś czas kiedy część ludzi będzie miało wiedzę i chęci żeby coś programować.

5. Obsadzenie uczestników rolami. Tutaj się w pełni zgadzam.

koszmarek napisał:To może ja pierwszy :p.

Moje propozycje nowych priorytetów w "Madagaskarze".

1. Znowu zmienić format NOWYCH (produkowanych) warsztatów - tu już chcę pojechać kompletnie po bandzie - chciałbym aby od warsztatu 17 laborki już w ogóle NIE uczyły programowania poprzez opracowania , ale tylko i wyłącznie egzekwowały wiedzę z programowania poprzez egzaminy. Tym samym warsztaty 17+ będą składały się z a) kompletnej aplikacji treningowej b) max 3 stronicowego (tym samym zwięzłego) dokumentu opisującego czym charakteryzuje się aplikacja treningowa c) specyfikacji aplikacji na zaliczenie wraz ze szczegółowymi wymaganiami co do kodu d) egzaminatora który będzie czekał na kolejne podejścia do egzaminu :p ... tym samym "Madagaskar" w gałęzi szkoleniowej przestanie od warsztatu 17 uczyć studenta wiedzy a będzie tylko i wyłącznie ujednolicać standard programowania wśród uczestników (poprzez egzaminy.) To oznacza że przebieg produkcji laborek będzie się składał tylko z etapów za które zawsze braliście się chętnie: tzn. 1.dogadania zakresu wiedzy na kolejny warsztat 2. wyszukanie przykładowego zestawu linków z opracowaniami dot. wiedzy z warsztatu 3.oprogramowanie aplikacji treningowej i egzaminacyjnej 4.kontrola jakości kodu aplikacji treningowej 5.sporządzenie specyfikacji egzaminu ... szast prast, warsztat gotowy :p . Tu oczywiście znowu nie chcę z Wami teraz już dyskutować jak wyglądać będzie taki warsztat, ale jak zagłosujecie na moją propozycję (na głosowaniu za około tydzień) to detale nowego formatu laborki dogadamy w dedykowanym wątku na forum.
   

Ten punkt przykuł moja uwage i niestety się z nim nie zgadzam. W sytuacji gdy Madagaskar bedzie glownie opieral sie na egzaminowaniu uczestnikow, a nie na nauce to po prostu stanie sie czyms totalnie nieatrakcyjnym dla ludzi chcacych sie nauczyc programowania. Malo kto zainteresuje sie projektem, ktory tylko egzaminuje, predzej wybierze sie projekt, ktory przy okazji bedzie uczyl (obecna forma). Odnosnie tego mam inna propozycje, ale to ponizej.
Z pozostałymi punktami jak najbardziej się zgadzam, byłyby to dobre zmiany.

h4br napisał:Moim zdaniem należałoby zacząć tworzyć aplikację do obsługi projektu w asp.net mvc. Przeniesienie do aplikacji zarządzania kursami. Hostowanie pomniejszych plików na serwerze lub podpięcie api google drive. Filmy z kursów przesyłane bezpośrednio przez stronę na YT za pomocą api. Przesyłanie kodu zaliczeniowego bezpośrednio przez stronę i delegowanie automatyczne bądź ręczne do odpowiedniej  osoby. Takie luźne propozycje aby sprecyzować cały zakres trzeba by było przysiąść i dokładnie ustalić co jest potrzebne.

Pomysł bardzo dobry. Pytanie: kto to miałby napisac? Napewno nie wieksza grupa osób będąca uczestnikami tego projektu, bo po prostu nie będa potrafili się zorganizować. A nawet, jeśli znajdzie się 1 lub 2 osoby chętne do stworzenia takiego serwisu to dlaczego miałyby to napisać? To już nie jest godzina na tydzień, a 2 godziny dziennie przez dluższy okres czasu.

h4br napisał:
Co do kursów i egzaminowania to myślę że pojedyncze warsztaty są za długie i zbyt rozwlekłe co wydłuża czas po jakim są one wypuszczane przez co projekt stoi w miejscu. Jeżeli chodzi o programy zaliczeniowe to wygodniejszym rozwiązaniem byłoby podawanie części kodu uczestnikom który mają dokończyć (zaimplementować brakujące rzeczy). Do tak przygotowanego kodu można by było wcześniej napisać testy jednostkowe co ułatwiłoby sprawdzanie poprawności działania kodu a egzaminator musiałby przyjrzeć kod tylko pod kątem estetyki kodu ewentualnie pod kątem optymalności danej implementacji.

Forma egzaminowania ciekawa, podobna to tego co ma codeschool. Tak mysle, ze w pierwszych warsztatach mozna byloby cos takiego prostego miec zaimplementowane, a im temat bedzie coraz bardziej sie rozszerzac to po prostu zaczac opierac sie na wstrzykiwaniu zaleznosci. Latwo bedzie mozna napisac testy do takiego kodu, a egzaminator bedzie musial tylko sprawdzic czy kod jest poprawnie napisany (wedlug pewnych standardow czysteog kodu).

michupl22 napisał:Samodzielna budowa aplikacji na potrzeby projektu wymaga zbyt dużo czasu i wiedzy na ten temat. Lepiej skorzystać z gotowych rozwiązań. Oto moje propozycje:

1. Założyć stronę internetową projektu opartą na WordPress lub Joomla! i dostosować je do własnych potrzeb. Umieszczane były,by tam warsztaty, linki do materiałów, książek itd... Można by również umieszczać tam informacje/wiadomości z funkcją powiadamiania na email. Zastąpiło by to dotychczasowy mailing grupowy. Stroną mogła by zająć się jedna lub dwie osoby, które by to obsługiwały. Oprócz tego za pomocą wtyczek można by zautomatyzować proces egzaminowania warsztatów np. Wysyłanie kodu źródłowego do egzaminatora.

2. Nie ma co rezygnować z produkcji warsztatów. W końcu wiele ludzi ze względu na nie dołączyło do projektu. Moja propozycja rozwiązania to owszem tworzyć warsztaty w dokumtach PDF przez osoby, które mają wiedzę na ten temat, a potem szukać wśród uczestników, którzy mają zaliczony warsztat, ochotników będący wstanie przełożyć treść warsztatu z postaci tekstowej do postaci wideo.

3. Kwestie upublicznia warsztatów uważam za zbyt szybką. Jest ich mało. Uczestników mamy dość sporo, ale na razie należy zabrać się za ich produkcję tym bardziej, że jak mają one być wstawiane na youtube to muszą być robione w postaci wideo.

4. Ze środowiskiem deweloperskim też uważam, że na razie należy się wstrzymać. Nie tworzymy jako grupa żadnych projektów i bawienie się w Gity to strata czasu. Może za jakiś czas kiedy część ludzi będzie miało wiedzę i chęci żeby coś programować.

5. Obsadzenie uczestników rolami. Tutaj się w pełni zgadzam.

1. Pomysl dobry, na start moze byc dobra wizytowka projektu. Rozwiazanie dosc tanie i szybkie, lecz tez niezbyt profesjonalne. Tak czy inaczje na start dobra rzecz, a pozniej mozna przechodzic na cos konkretniejszego.
2. Racja, lecz to jest cos co trzeba drastyczniej zmienic, ale to ponizej.
3. A mi sie wydaje, ze to jest bardzo dobry pomysl. Jesli projekt zostanie zle odebrany to bedzie informacja o tym, ze trzeba cos poprawic, a teraz nikt tego nie wie.
4. Umiejetnosc korzystania z tego typu narzedzi jest jedna z umiejetnosci, ktorych wymaga sie od programisty poza znajomoscia jezyka. Wydaje mi sie, ze jaknajbardziej jest juz czas, aby zaczac ludzi zapoznawac z takimi narzedziami.




A teraz moja propozycja:

1. Upublicznienie całego projektu:
   
   Udostepnienie wszystkich warsztatow dla kazdego. Utworzenie calego kursu C# calkowicie za darmo z pelnym dostepem dla kazdego. Zainteresowanie w ten sposob ludzi projektem, pokazanie, ze materialy sa naprawde bardzo dobrze przygotowane, a nastepnie rozpoczac prace nad szkoleniem bardziej zaawansowanym, lecz juz z ograniczonym dostepem (na przyklad platnym).
   
   
2. Podział uczestników na 2 grupy:
   
   Podzielenie uczestnikow na dwie wyraznie rozniace sie grupy. W pierwszej grupie bylyby osoby, ktore beda tworzyc warsztaty i uczyc innych. W drugiej wszyscy inni, ktorzy po prostu chca sie nauczyc jezyka
   Kwestia dla mnie kluczowa, wiec wyjasnie ja szerzej.
   
   Madagaskar aktualnie jest projektem, który stara się na sile zacierac roznice miedzy ludzmi. Osoby zdajace warsztaty, rowniez je tworza, co jest chyba bledem koncepcyjnym.
   Chcialbym, aby projekt bylby atrakcyjny rowniez dla osob, ktore posiadaja juz wymagane umiejetnosci. Strata czesto kilku godzin (obejrzenie warsztatu, zapoznanie sie z wymaganiami, napisanie aplikacji i caly proces zdawania), aby zaliczyc jeden warsztat z materialu, ktory doskonale sie zna jest moim zdaniem czyms co odpycha ludzi takich jak ja od tego projektu. Tutaj jest duzy problem. Jesli ten projekt chce stawiac na jakosc to musi wydzielic osoby, ktore maja wieksza wiedze z danego materialu i je inaczej traktowac. Lepiej jak taka osoba, napisze egzamin do warsztatu, niz traci czas na zdawanie czegos co nic do jej zycia nie wnosi.
   
   

h4br napisał:Co do kursów i egzaminowania to myślę że pojedyncze warsztaty są za długie i zbyt rozwlekłe co wydłuża czas po jakim są one wypuszczane przez co projekt stoi w miejscu. Jeżeli chodzi o programy zaliczeniowe to wygodniejszym rozwiązaniem byłoby podawanie części kodu uczestnikom który mają dokończyć (zaimplementować brakujące rzeczy).

Myślę o czymś takim. Mamy w tej chwili gotowy kod 1 ver. systemu odprawy pasażerów na lotnisku. Pierwotnie miałbyć dedykowany tylko pod warsztat 17. Od niedawna jednak skłaniam się ku temu, aby Tworzenie tej (nadal dość prostej) aplikacji rozbić na aż 3 warsztaty, czyli W17: utworzenie na konsoli klasy pasażer oraz wypchanie i zaprezentowanie kolekcji kilkoma pasażerami (obiektami tej klasy). W18: dodanie do tego kodu zagadnienia konstruktorów oraz właściwości oraz zrobienie analogiczną akcję na konsoli dla 2 nowych klas/obiektów - samolotów oraz lotniska. W19: zrobienie (na istniejącej organizacji klas/obiektów) finalnej aplikacji okienkowej prostej odprawy pasażerów. Teraz żeby było weselej w każdym z tych 3 laborek tworzenie aplikacji byłoby rozbite na etapy (o formacie analogicznym do "ćwiczeń" z warsztatów w6-w11) tworzenia tej aplikacji. Czyli to jest coś co mam nadzieje choć częściowo pokrywa się z propozycją uczestnika h4br (drobniejsza granulacja faz szkolenia w warsztacie). Jestem ciekaw, co o tym myślicie.

Fores napisał:W sytuacji gdy Madagaskar bedzie glownie opieral sie na egzaminowaniu uczestnikow, a nie na nauce to po prostu stanie sie czyms totalnie nieatrakcyjnym dla ludzi chcacych sie nauczyc programowania. Malo kto zainteresuje sie projektem, ktory tylko egzaminuje, predzej wybierze sie projekt, ktory przy okazji bedzie uczyl (obecna forma)

To ja (przed głosowaniem) spróbuję jeszcze polobbować mój pomysł (tylko specyfikacji egzaminu + egzaminowanie a zdobywanie wiedzy tylko samodzielnie). Oczywiście możemy zachować aktualną formę (tworzenia materiałów szkoleniowych "Madagaskaru"), ale liczcie się proszę z tym, że mogą się nie znaleźć (podobni do mnie) desperaci którzy będą płodzić opracowania szkoleniowe (konspekty + screeny). KellyCMI w poprzednim wątku pokazał Wam mojego posta w którym zapytałem uczestników kto chce opracować kolejny Unit z konspektem dot. podstaw OOP ( https://madagaskar.forumpolish.com/t128-w-trakciewarsztat-17-etap-08-finalne-opracowanie-warsztatu-szkoleniowego#1422 ). Absolutnie nie mam Wam za złe , że (delikatnie mówiąc :p) nie było lasu rąk chętnych :p. Zrozumiałem że mało kto z nas chce się bawić w jakąkolwiek robotę redaktorską. Chętnie się rzucamy do prac w "Madagaksarze" związanych z tym co tygryski lubią najbardziej czyli właśnie z kodowaniem (np. łatwo u nas znaleźć ochotników do oprogramowania aplikacji treningowej czy wiele osób udziela się w kontroli jakości kodu napisanej aplikacji itd. .. i dobrze!). Jak już ktoś musi mieć teorię w "Madagaskarze", to przecież można mu w warsztacie w17 dać linka do zestawu gotowych opracowań dot. tematu warsztatu (akcja wykonana na jednym z pierwszych etapów produkcji w17: https://docs.google.com/spreadsheets/d/1PaF7PCdWzOrxM8BudefURV-S5siymGoAmXMqkZJNvp0/edit?usp=sharing ). Tu masz kilkanaście gotowych opracowań dot. wstępu dot. tylko tworzenia prostej klasy i obiektu, czyli kilkanaście punktów widzenia (kilkunastu autorów) na to samo, atomowe zagadnienie. To lepsze od czegokolwiek co wypłodzimy sami. Zresztą po co mamy tworzyć "sto pierwsze" :p opracowanie na necie ? Ja Wam mówię idźmy po najprostszej linii (aby zbudować mocną grupę deweloperów) czyli standaryzacja grupy poprzez tylko sporządzenie listy wymagań + egzekucję (egzamin).

Jak na razie dzięki za owocną dyskusję ale czekam teraz na c.d. oraz nowe propozycje oczywiście

Fores napisał:
[list=1]
[*]Upublicznienie całęgo projektu:

Udostepnienie wszystkich warsztatow dla kazdego. Utworzenie calego kursu C# calkowicie za darmo z pelnym dostepem dla kazdego. Zainteresowanie w ten sposob ludzi projektem, pokazanie, ze materialy sa naprawde bardzo dobrze przygotowane, a nastepnie rozpoczac prace nad szkoleniem bardziej zaawansowanym, lecz juz z ograniczonym dostepem (na przyklad platnym).

Uważam, że to byłoby najlepsze dla projektu.
Do Madagaskaru przystąpiłem za drugim podejściem, ponieważ za pierwszym razem wydało mi się to być zamknięte (i zaklęte) towarzystwo i nie wiedziałem czy sobie poradzę i czy się nie spalę w nauce C#. Moje obawy okazały się nieuzasadnione. Wydaje mi się, że upublicznienie kursu na stronie internetowej pozwoli na wyłonienie większej grupki prawdziwych zapaleńców, gotowych do rozwijania projektu.

Witam
I ja wrzucę coś od siebie:
Według mnie najlepszą opcją byłaby hybryda pomysłów Koszmarka i Foresa (które też są częściowo zlepka pomysłów innych uczestników dysputy )
I tak:

• Podział projektu na działy zarządzane przez ochotników - ok
  

• Upublicznienie warsztatów + w dalszej części szkolenie płatne (pomysł Foresa) - ok
  

• Co do dalszej wersji warsztatów zgadzam się z Koszmarkiem - ale jak zareagują uczestnicy, którzy (patrz wyżej) zapłacą za dostęp do warsztatów a nie będą ich mieli w formie dotychczasowej? Tutaj jest problem żeby zjeść ciastko i mieć ciastko )
  

• Pytanie do Koszmarka: dlaczego lista 100 osobowa? A może ją zlikwidować? Tylko trzeba się wtedy zastanowić nad sposobem "dyscyplinowania" uczestników. Obecnie jak przejdzie czas na zdanie egz wylatujesz z listy i wchodzisz ew na koniec kolejki - jak będzie ogólny dostęp, to w jaki sposób wymusić czas oczekiwania?
  

• Podział uczestników na dwie grupy: jak najbardziej
  

• Punkty w rejestratorze: programiści piszący apki np. treningowe powinni dostawać punkty z wagą np. 1,8 w stosunku do innych uczestników. Jednym słowem - wprowadzić punkty ważone w zależności od działań/działalności
  

• "Rozwlekanie" aplikacji na kilka warsztatów - wg mnie ok
  

• Do Fores: również jestem za tym aby uczestnicy mający już pewne doświadczenie w programowaniu nie musieli zdawać kolejnych warsztatów - pytanie tylko jak zweryfikować nowych programistów, którzy chcą przyłączyć się do projektu? Od razu mają pisać apki treningowe? Może, niech zaliczą możliwy najwyższy:) warsztat i ok...
  

To na razie tyle
Pozdrawiam

EDIT

Oczywiście jestem zwolennikiem GIT-a

tomtom1 napisał:Witam
Co do dalszej wersji warsztatów zgadzam się z Koszmarkiem - ale jak zareagują uczestnicy, którzy (patrz wyżej) zapłacą za dostęp do warsztatów a nie będą ich mieli w formie dotychczasowej?

I choćby dlatego absolutnie nie jestem zainteresowany pobieraniem jakichkolwiek opłat od uczestników. Jeżeli zacznę pobierać choćby złotówkę od użytkowników to ze 100 uczestników zrobi nam się max 10. Kolejne kwestie jakie musiałbym rozwiązać to legalności pobierania opłat (co by się wiązało pewnie z założeniem firmy + haraczami dla RP które byłyby nieopłacalne na tym etapie projektu)
... opłaty - na razie NIE dziękuję :p

tomtom1 napisał:Pytanie do Koszmarka: dlaczego lista 100 osobowa? A może ją zlikwidować? Tylko trzeba się wtedy zastanowić nad sposobem "dyscyplinowania" uczestników.

Główną przyczyną max 100 ilości grupy jest indywidualne egzaminowanie uczestników.
Nie chcę "dojeżdżać" egzaminatorów sprawdzaniem zbyt wielu uczestników. Póki nie mamy zaimplementowanego automatu do sprawdzania poprawności kodu egzaminacyjnego (taki automat jest technicznie możliwy i stosowany w wielu serwisach szkoleniowych) to nie widzę sposobu na zwiększenie grupy studentów. Zresztą, wydaje mi się, że na razie taka liczba jest optymalna.

tomtom1 napisał:Punkty w rejestratorze: programiści piszący apki np. treningowe powinni dostawać punkty z wagą np. 1,8 w stosunku do innych uczestników. Jednym słowem - wprowadzić punkty ważone w zależności od działań/działalności

Nie chciałbym wchodzić w takie zabawy, bo wpadnę wtedy w pułapkę akademickiej dyskusji z uczestnikami np. czyja praca jest ważniejsza i b. wartościowa - programisty czy np. redaktora j. polskiego treści warsztatu ? Ten drugi wydaje się na pozór mniej wartościowy ale po jakimś czasie się okazuje że taka osoba chroniła by nas przed katastrofą wizerunkową , np. komentarzy na internecie "koszmarku naucz się najpierw po polsku a potem dopiero ucz innych programowania" :p Tym samym wszystkie "zawody" w internecie traktuję ze współczynnikiem 1, a zasadę przyznawania punktów w rejestratorze mam taką że 1 pkt jest ekwiwalentem pracy jaką by wykonał profesjonalista w dziedzinie w jakiej ta praca została wykonana. Czyli jak oprogramujesz jakiś moduł np. w 5h to może się okazać , że otrzymasz za to tylko 1 pkt :p ... wiem , nie jest to doskonała zasada (zależna od celności wyceny admina "rejestratora").

tomtom1 napisał:Do Fores: również jestem za tym aby uczestnicy mający już pewne doświadczenie w programowaniu nie musieli zdawać kolejnych warsztatów - pytanie tylko jak zweryfikować nowych programistów, którzy chcą przyłączyć się do projektu? Od razu mają pisać apki treningowe? Może, niech zaliczą możliwy najwyższy:) warsztat i ok...

Wiem że pytanie do Foresa ale ja też spróbuję odpowiedzieć - wg mnie miałoby to być rozw. całkowicie niezależne od warsztatów "Madagaskaru" - po prostu 1 lub więcej "code reviewerów" , którzy będą decydować czy rewizja (zmiana w kodzie) uczestnika ma wejść do wyznaczonej gałęzi dewelopmentu aplikacji. Jeżeli zmiana uczestnika nie będzie zaakceptowana to "code reviewer" (np. przy pomocy narzędzi z GitLaba) pisze autorowi zmiany w kodzie co ma w tym kodzie poprawić, aby jego zmiana została w końcu zaakceptowana ("code review" to proces wspierany systemem uprawnień - tzn. deweloper nie będzie miał tak po prostu możliwości wypychania aplikacji swoim nowym kodem bez uprzedniej kontroli tego kodu przez autoryzowaną osobę.). Po wielu takich iteracjach pomiędzy programistami a "code reviewerami" , współpraca uczestników tworzących oprogramowanie będzie się docierać a standard kody towrzonej aplikacji będzie się ujednolicać.

I tak:

• Zostałem przekonany co do braku opłat za szkolenia (przynajmniej na razie )
  

• Zostałem przekonany co do "weryfikacji" programistów z doświadczeniem
  

• Nie jestem przekonany co stałej liczby uczestników (rozumiem dlaczego tak jest ale IMHO trzeba pomyśleć jak tą liczbę zwiększyć)
  

• Punktacja w rejestratorze - z całym szacunkiem, jeżeli będę znakomitym "reklamiarzem" to z czasem może okazać się, że mam większą wagę głosów w ankietach aniżeli programista piszący apki dla projektu... To był tylko przykład - (nie hejtujcie mnie...)
  

Pozdrawiam

tomtom1 napisał:Punktacja w rejestratorze - z całym szacunkiem, jeżeli będę znakomitym "reklamiarzem" to z czasem może okazać się, że mam większą wagę głosów w ankietach aniżeli programista piszący apki dla projektu... To był tylko przykład - (nie hejtujcie mnie...)

Więc spróbuj być największym reklamiarzem w projekcie , gdy już przekonasz się że jednak to nie takie proste jak się wydaje (na własnej skórze przekonasz się jak łatwo stracić zainteresowanie internauty), to wtedy docenisz tych uczestników którzy zwerbowali sporo narybku do "Madagaskaru" i sam dojdziesz do wniosku że ich wartość pracy jest porównywalna z pracą programistów tworzących aplikacje.

Jak najbardziej celna i słuszna uwaga. Niestety nie jestem przekonany (wiem, że robię sobie wrogów...) a i marketing jest na drugim końcu mojej orbity... Oczywiście nie zmienia to faktu, że tacy fachowcy (reklama) są bardzo potrzebni (i często niedoceniani) w projekcie/firmie.
Poczekajmy na kolejne pomysły/propozycje. Może mi też coś wpadnie do głowy...
Pozdrawiam
Koszmarku, w ten weekend będziesz odpalał ankietę z propozycjami ulepszeń/poprawy/zmiany projektu?

To może ja krótko wspomnę, że nadal jestem chętny do wsparcia zespołu, tak jak pisałem w poprzednim temacie, w którym koszmarek chciał się wykręcić z tematu.

Co do przyszłości laborek dobrym pomysłem jest zebranie materiałów w jednym miejscu, bo materiałów w sieci jest po prostu cała masa, my musielibyśmy tylko podać kilka źródeł, których przeczytanie ze zrozumieniem da bazę do zaliczenia. Następnie opracowanie aplikacji treningowej, która będzie zawierała implementację zagadnień z opracowań. Wtedy pozostanie ostatni krok, czyli egzaminowanie i tutaj uważam, że warto zlecić dalsze przebudowanie aplikacji treningowej. Np. tak jak w warsztacie 11-12 trzeba przebudować appkę z metod zwracających void na zwracające wartości. Aplikacja taka może się rozwijać przez przynajmniej kilka warsztatów, tylko by trzeba było ogarnąć dostępy do kodu dopiero po zaliczeniu poprzedniego egzaminu.

Co do 100 osób w projekcie:
tutaj musimy określić jaki jest nasz cel.
Jeżeli celem jest szkolenie osób dla samego szkolenia, to faktycznie można otworzyć listę, tylko trzeba będzie powiększać też systematycznie listę egzaminatorów i automatyzować proces.
Jeżeli celem jest wyszkolenie zespołu, który jest w stanie coś napisać co ma prawo ujrzeć świat to 100 osób jest nawet za dużym gronem.
Poza samym celem projektu z bazą 17 szkoleń wydanych przez ~3 lata nie poszalejemy. Zwłaszcza, że większość z nas nie garnie się do tworzenia nowych warsztatów.
Dlatego osobiście poszedłbym w szybkie wyszkolenie zespołu - może być nawet 100 osobowego - najwyżej się podzielimy na kilka podzespołów.

Niezależnie od tego czy otwieramy się na świat czy zostajemy w małym gronie warto opracować standardy pisania kodu w zespole Madagaskar, które będą widoczne dla wszystkich i egzekwowane wraz z przechodzeniem kolejnych warsztatów.
Jest to zadanie z którym wiązać się będą długie rozmowy, w wielu kwestiach pewnie i spory które będą rozstrzygane ankietą, ale jest to potrzebne od pierwszych linii kodu, tak aby nie nabrać złych nawyków.

tomtom1 napisał:Koszmarku, w ten weekend będziesz odpalał ankietę z propozycjami ulepszeń/poprawy/zmiany projektu?

Tak właśnie ! Odpalę ją w sobotę wieczorem. Myślę o zmodyfikowanym systemie ważonych głosów. Czyli nie 1 do 1 z rejestrtatora, ale + 1 pkt wagi głosu w ankiecie, za każde kolejne 50 pkt w "rejestratorze" uczestnika. Tym samym chcę trocę zwiększyć znaczenie w ankiecie nowych uczestników, czyli <50 pkt w "rejestratorze" = 1 pkt w ankiecie, <100 pkt w "rejestratorze" = 2 pkt w ankiecie, >=100 pkt w "rejestratorze" = 3 pkt w ankiecie ... tym samym lider "rejestratora" będzie miał tylko 3 razy ważniejszy głos od nowych uczestników a nie np. 100 do 1  ... ale myślę jeszcze nad systemem głosowania aby nie było hardcoru w różnice wag głosów, ale jednak żeby Ci zasłużeni w rozwoju projektu mieli większy wpływ na decyzje.

Proponuję ważyć głosy na podstawie procentowego udziału w całości zaokrąglone w górę.
I tak np.:
tharkun miałby10 głosów
Zefirek miałby10 6 głosów
Seboos miałby10 2 głosy
Demar77 i wszyscy którzy mają mniej niż 1% (aż do 0% włącznie) udziałów w wkładzie mieliby 1 głos.

Takim systemem pierwsze 10 osób ma 62 głosy,
pierwsze 22 osoby mają 88 głosów.
Jakby wszyscy (132 osoby) z rejestratora zagłosowali to będziemy mieli 198 głosów.

Taki system wg mnie pogodził by wartość zasłużonych z wartością nowych osób, które nie zdążyły się wykazać.

Rozumiem ... pomyślimy.

Obsadzić role w projekcie ochotnikami to dobry pomysł. Odciążyło by to Koszmarka a jeśli na przykład byłaby wystarczająca liczba koordynatorów zaliczania warsztatów oraz egzaminatorów to można by pomyśleć o utworzeniu kilku "Grup Szkoleniowych Madagaskaru". Wtedy można by było znieść limit 100 osób. Zamiast tego byłoby kilka grup o mniejszej liczbie uczestników.

Warsztaty szkoleniowe trzeba produkować. Jest to niewątpliwy atut tego projektu. Można jednak trochę zmienić ich formę. Zamiast samych filmów wmieszać w to pdf-y. Powinno to zmniejszyć ilość filmów i przyśpieszyć produkcję. Osobom, które są już obeznane z tematem warsztatu powinno ułatwić szybsze zaliczenie. Zmniejszenie zakresu też powinno wyjść warsztatom na dobre.

Cześć

1. Wydaje mi się, że propozycja jeszcze nie padła, więc może po prostu zrównoleglić tworzenie warsztatów?

2. Uważam, że warsztaty wideo są dużą zaletą Madagaskaru, ale przydały by się równolegle tutoriale lub prezentacje tekstowe duplikujące treść. Może udało by się jakoś zautomatyzować tworzenie obu wersji na podstawie jakiegoś wyjściowego formatu?

3. Co do odciążenia koszmarka, jak najbardziej popieram. Jednak jest pytanie, czy jest wśród nas odpowiednio dużo osób, które nadają się do zarządzania większymi grupami.

Pozdrawiam
Zabaweb

tomtom1 napisał:
Do Fores: również jestem za tym aby uczestnicy mający już pewne doświadczenie w programowaniu nie musieli zdawać kolejnych warsztatów - pytanie tylko jak zweryfikować nowych programistów, którzy chcą przyłączyć się do projektu? Od razu mają pisać apki treningowe? Może, niech zaliczą możliwy najwyższy:) warsztat i ok...

To nie jest łatwa sprawa. Programista programiscie nie rowny i nie zawsze uda sie poprawnie ocenic umiejetnosci danej osoby. Na przyklad ostatnio do mojego zespolu trafila osoba z 10 letnim doswiadczeniem w C# - wyleciala po 2 tygodniach za totalny brak wiedzy (widac, ze od 10 latu nic sie nie rozwijal). Zaznacze tylko, ze nie mamy wielkich wymagan (ja na przyklad mam tylko 2 lata doswiadczenia). Pisze to po to, poniewaz chcialbym, aby ludzie z Madagaskaru nie byli tego typu programistami, dlatego tez trzeba przeorganizowac ten projekt.
A na start mysle, ze mozna ocenic umiejetnosci po zdaniu ostatniego warsztatu, a pozniej sama grupa tych osob 'uprzywilejowanych' wyloni slabe ogniwa, ktore jednak nie maja wystarczajacej wiedzy.

zabaweb napisał:Wydaje mi się, że propozycja jeszcze nie padła, więc może po prostu zrównoleglić tworzenie warsztatów?

Może i tak (nie mówię "nie"), ale wg mnie:

• trzeba by było sprawić wtedy aby każdy warsztat był niezależnym odcinkiem "serialu". Może to być trudne do wykonania z uwagi na to, że padają w tym wątku propozycje, aby 1 aplikację rozwijać przez kilka warsztatów. Wydaje się więc niemożliwe aby produkowany był jednocześnie (np. w 3 równoległych torach) warsztat 17, 18, 19 skoro z dużym prawdopodobieństwem będą prezentować 3 etapy tworzenia tej samej aplikacji - systemu odprawiania pasażerów na lotnisku. (główna trudność to zachowanie spójności kodu źródłowego we wszystkich 3 laborkach, produkowanych równolegle da się, ale tu by trzeba było się oprzeć właśnie na GitLabie).
  
• nie jest łatwo pozbierać mocną grupę na poszczególne etapy produkcji choćby jednego (kolejnego) warsztatu ... więc przy około 100 os grupie uczestników tym bardziej nie liczyłbym na to , że będzie się udawało angażować ekipę do produkcji choćby 2 laborek jednocześnie. Wydaje mi się że pierwszym wyzwaniem było by ruszyć z kopyta z choćby jedną gałęzią produkcji laborek.
  

koszmarek napisał:Może i tak (nie mówię "nie"), ale wg mnie:
trzeba by było sprawić wtedy aby każdy warsztat był niezależnym odcinkiem "serialu". Może to być trudne do wykonania z uwagi na to, że padają w tym wątku propozycje, aby 1 aplikację rozwijać przez kilka warsztatów. Wydaje się więc niemożliwe aby produkowany był jednocześnie (np. w 3 równoległych torach) warsztat 17, 18, 19 skoro z dużym prawdopodobieństwem będą prezentować 3 etapy tworzenia tej samej aplikacji - systemu odprawiania pasażerów na lotnisku. (główna trudność to zachowanie spójności kodu źródłowego we wszystkich 3 laborkach, produkowanych równolegle da się, ale tu by trzeba było się oprzeć właśnie na GitLabie).

A może zamiast rozbijania ćwiczenia na kilka wykładów, większy program, pisany równolegle, byłby podsumowaniem dotychczasowych osiągnięć i pewną pracą przejściową? Oczywiście, to było by możliwe dopiero po wdrożeniu systemów do oceniania "małych programów". Podczas pisania takiego większego programu można by wdrażać idee, których sensu nie widać w małej skali.

Pozdrawiam
Zabaweb

zabaweb napisał:A może zamiast rozbijania ćwiczenia na kilka wykładów, większy program, pisany równolegle, byłby podsumowaniem dotychczasowych osiągnięć i pewną pracą przejściową? Oczywiście, to było by możliwe dopiero po wdrożeniu systemów do oceniania "małych programów". Podczas pisania takiego większego programu można by wdrażać idee, których sensu nie widać w małej skali.

Brzmi bardzo ciekawie, tylko czy ma damy rady wymyśleć , wdrożyć i ogarnąć proces produkcji na taki właśnie kombajn krótkich i długich aplikacji. Może i tak.

Witam ponownie  

Uważam, że na początku powinniśmy się skupić na
a) kształcie projektu
b) obsadą "ról"
to wszystko oczywiście z myślą o:
c) kształcie i formacie dalszych laborek

I co do C musimy mieć ukształtowane A i B...

To tyle z mojej strony (podane oczywiście w uproszczeniu)
I nadal deklaruję pomoc (w miarę możliwości i umiejętności)
Pozdrawiam
Tomtom

Odgrażałem się , że odpalę ankietę wczoraj ale nie udało się, sorry.
Daję słowo harcerza ;p , że ankietę odpalę w środę wieczorem (przed Bożym Ciałem).
Aby uzbierać jak największą liczbę głosów to ankieta potrwa aż około 10 dni do połowy czerwca i od połowy/końca czerwca zacznę wdrażać pierwsze punkty które przegłosujemy (m.in. przekazywać wybrane zadania chętnym uczestnikom)
pozdr.

Witam,

drobny komentarz do dyskusji.

1. ROLE w projekcie...
Podział ról to świetny pomysł. Kwestią do uzgodnienia będzie precyzyjny podział zadań. Można powołać w przyszłości również funkcję promotora projektu, który będzie zajmował się zadaniami promocji projektu w sieci, działaniami marketingowymi itp.

2. Format laborek i produkcja warsztatów...
Część tego tematu odnosi się do poprzedniego punktu, bo oczywiście dzieląc zadania, usprawni to rozwój i działania projektu. Wobec tego, format obecnych warsztatów można przenieść na kolejne laborki.

3. Konfiguracja środowiska deweloperskiego...
Temat wyzwanie, krok milowy projektu, ale warty poświęcenia.

4. Upublicznienie warsztatów zależeć będzie tylko od Koordynatora Madagaskaru. Działanie to stanowić będzie kolejny etap promocji projektu.

5. Aplikacja do obsługi projektu.
Usprawnienie późniejszej pracy nad projektem. Stworzenie takiej aplikacji pochłonie sporo czasu, ale zaprocentuje czasem i większym porządkiem przy założeniu zwiększającej się liczby uczestników.

6. Struktura grupy ma obecnie właściwy podział.

Pozdrawiam!