jakzal / PHPackaton2014

Hackaton dla PHPersów!

PHPackaton2014

Ogłaszamy konkurs PHPackaton 2014, organizowanego w ramach inicjatywy .

Event page

• Organizatorzy
• Cel
• Projekty
• Tematyka projektów
• Jakość
• Zespoły
• Terminy
• Zgłaszanie zespołów i projektów
• Ocenianie
  • Ocena społeczności
  • Zespół ekspercki
• Jawność
• Komunikacja
• Nagrody

#Organizatorzy#

Organizatorami konkursu jest inicjatywa PHPersPL reprezentowana przez

• Mariusz Gil
• Kacper Gunia
• Leszek Krupiński
• Norbert Orzechowicz
• Karol Sójko
• Kuba Zalas
• przedstawiciel PHPers Łódź (propozycja: ...)

W/w stanowią Zespół Ekspercki, o którym kawałek niżej.

(Zespół Ekspercki jest w trakcie formowania, ale jego skład nie wpływa na przebieg konkursu więc spokojnie).

Michał 'pecado' Łukaszewski pełni rolę Communication Officer'a (aka Single Point of Contact):

• odpowiada na pytania,
• pilnuje wysyłania powiadomień,
• stara się nadążyć za chaosem w skrzynce pocztowej,
• ogarnia bieżącą dokumentację konkursu.

#Cel#

• Integracja środowiska
• Dzielenie się wiedzą poprzez praktyczne jej wykorzystanie
• Popularyzacja technologii
• Popularyzacja dobrych praktyk programistycznych

#Projekty#

• projekt powinien być napisany w
  • PHP 5.4 lub 5.5
  • lub Hack (HHVM)
  • lub C - jeśli moduł
• projekt powinien być udostępniony jako Free Software, na licencji GPL, MIT lub WTFPL.
• repozytoria projektu powinny być publiczne (preferujemy GitHub lub Bitbucket)
• projekt powinien zawierać dokumentację na Wiki (tym samym ew. readme.md mogą na to wiki wskazywać, nie ma co powielać)
  • ponieważ projekty zostaną w sieci sugerujemy dokumentację angielską, ale najważniejsze, żeby była aktualna, wyczerpująca i precyzyjna.
  • będzie dobrze widziane załączenie literatury z jakiej korzystaliście - na etapie idei, projektowania, produkcji. To forma dzielenia się wiedzą: bardzo wskazana czynność :)

Zachęcamy do prowadzenia projektów w metodologii Scrum. Jeśli jednak któryś zespół uprze się na metodykę procesową lub produktową - nie ma problemu, byleby dowiózł swój projekt na czas. Prosimy tylko zaznaczyć w metadanych projektu, którą z nich wybraliście. Zarówno GitHub jak i Bitbucket dostarczają darmowego Issue Trackera i przestrzeń na Wiki projektu. Reszta to kwestia organizacji.

Oczywiście można oprzeć się o istniejące projekty, biblioteki, frameworki. Ważne, aby dało się wyodrębnić i ocenić wartość Waszej pracy.

#Tematyka projektów#

Proponujemy następujące kategorie

• narzędzia dla społeczności PHPersPL
  • np. porządne Jeopardy
  • albo inna zabawa, której będzie można używać na spotkaniach
• gry i zabawy natury ogólnej: coś co chciałeś napisać, ale nigdy nie miałeś motywacji.
• biblioteka, której zawsze potrzebowałeś, nawet jeśli o tym nie wiedziałeś
• zbawiam świat

Ponieważ zasadniczo robicie to non-profit (choć tak długo jak źródła będą otwarte i wolne nie mamy problemu z projektami stricte komercyjnymi) rozważcie projekty na przykład dla

• organizacji non-profit
• organizacje pożytku publicznego

Pomyślcie o czymś pożytecznym.

#Jakość#

Przywiązujemy ogromną wagę do jakości kodu i dobrych praktyk. Dlatego Wasz projekt musi być jak najbardziej zgodny z zaleceniami znanymi jako:

• CleanCode
• SOLID
• PSR-0, PSR-1, PSR-2, PSR-3, PSR-4 gdzie PSR-2 jest wymaganym minimum.

Zespół ekspercki postara się, aby oceniana była tylko aplikacja, nie wybrany framework. Dlatego sugerujemy próbę zmierzenia się z Clean Architecture :)

#Zespoły#

Przewidujemy, że w konkursie weźmie udział co najmniej jeden zespół z każdego ośrodka, w którym zawiązała się inicjatywa PHPersPL.

Każdy zespół powinien składać się z 3-5 osób. Nie mniej niż 3 i nie więcej niż 5. Literalnie. Niscy również liczą się jako jedna osoba.

Zakładamy, że udział wezmą następujące zespoły:

• reprezentanci aktualnych ośrodków PHPersPL
  • Warszawa
  • Wrocław
  • Trójmiasto
  • Śląsk
• 2 sloty pozostają do dyspozycji grup z Krakowa i Łodzi, które są w trakcie formowania.

Wszyscy mamy znajomych w innych miastach, ale elementem zabawy jest "rywalizacja" pomiędzy ośrodkami w jakich skupieni są PHPersi. Deal with it ;)

Zespół powinien mieć stały skład w trakcie trwania projektu. Oczywiście nie oznacza to, że - biorąc pod uwagę sezon urlopowy - w każdym sprincie będą aktywne te same osoby. Tak samo działa to w "realu", nie abstrahujemy od rzeczywistości.

Nie ma przeciwskazań, aby zespół korzystał z konsultacji w zakresie technologii, konfiguracji narzędzi, prowadzenia projektu. Prosimy tylko o odnotowanie takiego wsparcia, wraz z czasem jego trwania, w dokumentacji na Wiki projektu.

Nie ma problemu, aby konsultacji udzielił członek Zespołu eksperckiego, o ile będzie wprost wymieniony w dokumentacji Sprintu/projektu. Wiedza ma płynąć, a nie być narzędziem terroru. Niemniej jawność jej przepływu będzie formą fair-play.

W klasycznych hackatonach każdemu zespołowi/tematyce przypisany jest mentor. Mamy jednak świadomość, że w okresie wakacyjnym może być co najmniej trudne zorganizowanie takiej osoby/osób. Dlatego czynimy tu odstępstwo, które w zamyśle ma uelastycznić organizację i ją ułatwić.

#Terminy#

• Przyjmowanie zgłoszeń rozpocznie się 20.06.2014
• Zespół wraz z projektem przedstawia się do 10.07.2014, włącznie
• Wiemy, że Łódź może nie zdążyć i mieć niewielki poślizg. Postarajcie się jednak, aby był jak najmniejszy :)
• do 15.07.2014 przedstawiona jest lista zatwierdzonych projektów (spełniających warunki zgłoszenia)
• projekty można prowadzić do 14.09.2014, włącznie
  • każdy push po tej dacie będzie traktowany jako złamanie zasad i oznacza dyskwalifikację
  • ankiety dla społeczności i Zespołu Eksperckiego zostaną uruchomione 15.09.2014
• Podsumowanie wyników i oficjalne ogłoszenie zwycięzców będzie miało miejsce na PHPConPL, 27.09.2014, Szczyrk.

#Zgłaszanie zespołów i projektów#

• W zgłoszeniu zawarty jest
• nazwa kodowa zespołu :)
• pochodzenia (ośrodek PHPers)
• skład zespołu (imię, nazwisko, miasto)
• nazwa projektu i jego opis w 200 znakach (spacje się liczą)
• link do repo
• opcjonalnie link do CI

Zgłoszeniem może być link do README.md w repo zespołu (projektu), które będzie zawierało w/w informacje.

Zgłoszenia wystawiamy w formie Issue do tego repo, z prefixem "[Zgłoszenie]".

#Ocenianie#

• każdy projekt będzie oceniany przez:
  • społeczność, której ocena stanowi 60% oceny końcowej
  • Zespół Ekspercki, którego ocena stanowi 40% oceny końcowej

##Ocena społeczności##

Ponieważ społeczność jest nie do opanowania więc ocenia jak chce, choć fajnie by było gdyby oceniała mądrze.

Postaramy się jednak dostarczyć narzędzie, które umożliwi ocenę prostą albo rozbitą na bardziej szczegółowe kryteria. Się zobaczy.

##Zespół ekspercki##

Każdy projekt musi być oceniony przez min. 3 osoby z Zespołu Eksperckiego. Niekoniecznie wszystkie, niekoniecznie te same dla każdego projektu. W gestii członków Zespołu Eksperckiego pozostaje zorganizowanie się i ewentualne podzielenie projektami do oceny.

Oceny członków ZE będą uśrednione arytmetycznie i taka uśredniona ocena stanowi ocenę Zespołu Eksperckiego dla zespołu.

Zespół ekspercki wystawia 5 ocen, każda daje maksymalnie 20% oceny końcowej zespołu

• 20%: jakość kodu: w ruch pójdzie analiza statyczna ze wszystkim co mamy do dyspozycji
  • każdy projekt musi mieć testy.
  • nie ma znaczenia czy BDD czy TDD
  • nie ma wymagania 100% pokrycia kodu
  • jest wymaganie mądrego pokrycia kodu/funkcjonalności
• 20%: łatwość instalacji: pełną ocenę dostaje projekt, który działa po
  • osadzeniu na maszynie (zip i/lub clone i/lub composer - wedle uznania, byleby działało!): 50%/10%
  • wpisaniu lokalnych danych (db, ścieżki) do configa: 50%/10%
• 20%: jakość dokumentacji
  • opis projektu - co to, po co to, dlaczego świat będzie lepszy gdy użyje Twojego projektu
  • opis konfiguracji
  • instrukcje - użytkownika, administratora, kogo tam przewidujecie jako aktorów.
  • dokumentacja nie musi mieć wartości literackiej, ale powinna być napisana poprawnie wg reguł języka jaki zastosujesz (polski, angielski) i opisywać to co muszę wiedzieć.
• 20%: prowadzenie projektu - realizacja sprintów.
• 20%: wykorzystanie narzędzi CI
  • preferujemy otwarte rozwiązania, ale jak ktoś się uprze na Jenkinsa to do niego też mamy dostęp ;)
  • niemniej jakby dało się wykorzystać takie narzędzia jak shippable i inne dostępne publicznie CI - byłoby świetnie.
  • Przy wykorzystaniu CI obowiązuje ta sama zasada co przy instalacji: po wciśnięciu guzika dostaję produkt przetestowany i gotowy do instalacji - w wybranej formie.

Oczywiście mamy świadomość, że jest rok 2014 i sporo się dzieje na warstwie Front Endu. Zachęcamy do wykorzystania tych możliwości. Prosimy jednak pamiętać, że główna wartość aplikacji powinna leżeć po stronie Back Endu.

Zespół Ekspercki ma prawo do powołania "konsultantów": będą to osoby powszechnie znane i uznawane za biegłe np. w JS, CSS, Scrum, itp. Pomogą one ocenić jakość poszczególnych fragmentów aplikacji lub sposobu prowadzenia projektu. Może to wpłynąć na ocenę jednego z w/w obszarów.

##Jawność##

• każda ocena jest jawna i podpisana
• służyć temu będzie konieczność zalogowania się (może przez FB/G+/Tw/GitHub/Bitbucket, może inaczej) aby oceny dokonać.
• nie będziemy się szczególnie napinać na blokady, mające na celu zapewnienie 1głos-1osoba, bo i tak znajdziecie na to sposób
• wierzymy, że nie będzie siary i podpisanie się pod swoją oceną oznacza poważnego człowieka, który wie na czym polega zabawa społecznościowa.

##Komunikacja##

Wszystkie pytania dotyczące konkursu zadajemy w formie Issue do tego repo.

Na bazie tych pytań oraz udzielonych odpowiedzi będzie budowane FAQ :)

##Nagrody##

Prawdopodobnie będą. Zorganizowanie ich zajmie nam jakiś czas, więc informacja będzie uzupełniana.

Liczymy jednak, że połkniecie haczyk "for fun", a ewentualne gratyfikacje nie przesądzą o Waszym akcesie do zabawy.