Szukam PHP-owców i chętnych do skończenia issues 4programmers (Coyote)

10

Szukam PHP-owców oraz wszystkich chętnych do skończenia/dokończenia issues na GitHubie silnika Coyote (czyli naszego forum). Tutaj post, w którym wpadłem na ten pomysł.

Czemu taka inicjatywa?

Zdenerwowało mnie, że ciągle tylko dodaje się nowe wątki "do zrobienia" na naszym forum (vide kategoria Coyote) czy nowe issues na GitHubie, a nie ma ludzi, którzy by to robili. :/ @Adam Boduch robi, co może, ale jedna osoba... Tu można zobaczyć wykres aktywności na GitHubie: https://github.com/adam-boduch/coyote/graphs/contributors

Czy ty (@Silv) też bierzesz udział?

Nie. Główny powód to taki, że nie znam się na PHP (szkoda). Ale w przyszłości – kto wie... Jeśli chodzi o inne technologie (patrz: sekcja niżej), to robię obecnie bardzo ważną rzecz, którą zaplanowałem w zasadzie jeszcze przed rejestracją na tym forum (ponad 4,5 roku temu), więc niestety nie mam czasu.

Dlaczego głównie szukasz PHP-owców? Według GitHuba w Coyote wykorzystywane są także, między innymi, HTML, JavaScript, CSS i Ruby.

Według GitHuba 72,4% kodu jest to kod PHP (nie wnikam, jak to jest liczone. Przyjmijmy, że po prostu większość to PHP).

Czy trzeba znać się bardzo na PHP, czy wystarczy trochę?

Myślę, że trzeba znać się średnio. Wątpię, czy ktoś z podstawami PHP będzie w stanie w miarę sprawnie ogarnąć ten projekt – choć oczywiście nie wykluczam, można próbować.

Nie znam PHP. Jakie inne technologie/języki/rzeczy można znać, żeby pomóc?

Jak napisałem wyżej – według GitHuba w Coyote wykorzystywane są także – między innymi – HTML, JavaScript, CSS i Ruby. Jeśli zna się te technologie, można spróbować coś skończyć. Przejrzyj issues, żeby być pewnym, czy aktualnie coś jest do skończenia w tych technologiach, czy nie. Oczywiście zawsze może coś dojść, dlatego możesz też np. dodać repozytorium Coyote na GitHubie do obserwowanych (jeśli masz tam konto).

Jeśli chcę pomóc, to od czego powinienem zacząć?

1. Jeśli masz konto na GitHubie oraz chcesz pomóc w pisaniu nowego / ulepszaniu istniejącego kodu:

1.1. Myślę, że dobrze będzie, jeśli zacznie się od zforkowania Coyote na GitHubie.
1.2. Następnie dobrze będzie postawić Coyote u siebie lokalnie (w celach testowania własnych zmian). Tutaj instrukcje, jak to zrobić: https://github.com/adam-boduch/coyote#instalacja
1.3. Następnie dobrze będzie wybrać sobie zadanie/zadania do skończenia z istniejących issues.
1.4. Następnie można wprowadzać zmiany, commitować i pushować.
1.5. Następnie należy zrobić pull request do wersji pierwotnej.

Poza powyższym flow, można też:

  • sprawdzać istniejące pull requests, czy wszystko w porządku i nie trzeba nic dodać (a jeśli trzeba, tworzyć nowe issues);
  • robić wszystko z punktów nr 2 i 3 poniżej.

2. Jeśli masz konto na GitHubie, ale niekoniecznie chodzi Ci o pomoc przy pisaniu kodu:

  • można tworzyć nowe issues, jeśli ktoś zauważy coś na stronie, co wymagałoby poprawy, lub co można usprawnić;
  • można dodawać komentarze do istniejących issues, by lepiej i szybciej je skończyć;
  • robić wszystko z punktu nr 3 poniżej.

3. Jeśli nie masz konta na GitHubie:

  • można tworzyć nowe wątki na forum w tej kategorii, jeśli ktoś zauważy coś na stronie, co wymagałoby poprawy, lub co można usprawnić;
  • można dodawać komentarze do istniejących wątków na forum w tej kategorii (tzn. tych, które opisują sprawy "do zrobienia"), by lepiej i szybciej skończyć te sprawy.
  • można promować ten wątek i samemu szukać chętnych do pomocy w skończeniu issues.

Czy masz jakąś issues, która według Ciebie jest dobrym pomysłem do zrobienia?

Tak. Tutaj wątek na forum, tutaj issue na GitHubie. Oczywiście jest to moja subiektywna opinia. Jeśli ktoś uzna coś innego za ważniejsze – niech to robi.

Nie wszystko zrozumiałem / mam jeszcze pytania / uwagi...

Jeśli masz jakiekolwiek pytania lub uwagi odnośnie tej inicjatywy, pisz w tym wątku – albo posty, albo komentarze. Możesz też pisać bezpośrednio do mnie, ale uprzedzam, że mogę nie mieć możliwości odpowiedzieć szybko.


Do użytkowników biorących ze mną udział w projekcie CoyoteNET: ta inicjatywa to nie jest wymówka, a przynajmniej w założeniu nie jest, od brania udziału w CoyoteNET. Tak, przerwałem CoyoteNET, ponieważ uczę się teraz Angulara – było to planem wcześniejszym i ważniejszym niż CoyoteNET; poza tym, jak napisałem wyżej, mam inną rzecz do zrobienia, co było planem wcześniejszym nawet niż moja rejestracja tutaj – a więc zarówno wcześniejszym niż nauka Angulara, jak i wcześniejszym niż CoyoteNET.


UPDATE: Jeśli ktoś chciałby pomóc, dobrze też będzie, jak napisze w tym wątku, żeby można było jakoś skoordynować nas, jeśli będzie więcej osób niż 0. :)


UPDATE2:

Nawet jeśli minie trochę czasu od publikacji tego tematu (tydzień/miesiąc/rok/więcej), to nie miejcie oporów przed pomocą. :) Główna idea będzie aktualna, dopóki będzie to forum oraz dopóki będą issues do zrobienia.

Ponadto jeżeli pojawią się jakieś ważne zmiany w sprawach/linkach poruszonych w tym poście, to postaram się go edytować.


UPDATE3:

Czy jest jakiś cel poza ogólnie rozumianą pomocą, tj. bardziej konkretny, jaki mamy/chcemy osiągnąć?

Tak, odciążenie @Adam Boduch. Poza tym nie widzę innego. Jednak jeśli komuś może pomóc, to osobiście bym marzył, by okres między pojawieniem się nowego zdania/issue a jego ukończeniem był jak najkrótszy.

Granicą tego jest oczywiście 0 issues i każda nowa jest od razu robiona. To oczywiście stan idealny, więc się go na pewno nie osiągnie :), ale jeżeli naraz istniałoby np. około 10 issues (czyli poniżej 1/8 tego, co jest teraz), to byłoby w moim odczuciu całkiem w porządku.


UPDATE4: Nowa osoba zaczyna coś robić: @MasterOf postawił dziś Coyote na publicznym serwerze o IP http://35.232.241.159:8880/. Tutaj wpis na jego mikroblogu: https://api.4programmers.net/Mikroblogi/View/52360#entry-52360

2

-->Wymówka alert<--

Nie używam dockera, robię na windowsie, nie nadaję się :D

1

Docker działa na Windows 10 Pro bez problemu - przynajmniej w tym ograniczonym zakresie który potrzebowałem (odpalenie skryptów bashowych z wyświetleniem wyniku w konsoli cmd.exe).

Jeśli chodzi o Coyote to nie wiem jak działa, ale Vagrant sam zakłada wirtualkę i sam ją kasuje w razie potrzeby.
W zasadzie Vagrant to taki "docker compose + GUI". W sensie można mieć GUI na wirtualce w razie potrzeby (Linux GUI, IDE, przeglądarka). Ułatwia pracę z nieznanym środowiskiem bo nie trzeba konfigurować mostków do VMki.

2

Inicjatywa szlachetna w swej intencji, ale zapytajmy @Adam Boducha co on o takim wsparciu sądzi, i czy czuje potrzebę jego otrzymania. Na pewno każdy z nas Bracia/Siostry w kodzie miał w życiu sytuację, kiedy ktoś inny wpierdzielał się commitami w kod, który pisaliście mocno go zaburzając - zatem wpuszczanie nowych osób do projektu, który Adam zna na wylot i utrzymuje już od bodaj 17 lat może okazać się średnim pomysłem.

1
MasterBLB napisał(a):

Na pewno każdy z nas Bracia/Siostry w kodzie miał w życiu sytuację, kiedy ktoś inny wpierdzielał się commitami w kod, który pisaliście mocno go zaburzając - zatem wpuszczanie nowych osób do projektu, który Adam zna na wylot i utrzymuje już od bodaj 17 lat może okazać się średnim pomysłem.

Z drugiej strony może to właśnie dobry moment, żeby wdrożyć więcej ludzi w Coyote, żeby Adam nie był zdany na siebie z pchaniem go do przodu? Jak spojrzeć na listę osób, które mają jakiekolwiek kontrybucje w masterze, to druga po Adamie osoba wprowadziła 1000 razy mniej zmian i 150 razy mniej commitów.

Jak na razie wszelkie propozycje usprawnień utykają mniej więcej na pomysł dobry, ale nie ma kto go zrealizować, a czeka kolejka bugów do fixowania.

5
MasterBLB napisał(a):

Inicjatywa szlachetna w swej intencji, ale zapytajmy @Adam Boducha co on o takim wsparciu sądzi, i czy czuje potrzebę jego otrzymania. Na pewno każdy z nas Bracia/Siostry w kodzie miał w życiu sytuację, kiedy ktoś inny wpierdzielał się commitami w kod, który pisaliście mocno go zaburzając - zatem wpuszczanie nowych osób do projektu, który Adam zna na wylot i utrzymuje już od bodaj 17 lat może okazać się średnim pomysłem.

Jasne, zachęcam do dodawania pull requestów na githubie :)

2

Seria drobnych pytań.

  1. Czy jest jakaś osoba, która wprowadzane zmiany dodatkowo testuje?
  2. Czy zmiany są na zasadzie samowolki? W sensie, jest jakieś issue, czy opis proponowanego rozwiązania powinien być pierw umieszczony w issue, potem dopiero stworzony i wystawiony jako PR?
  3. Co z widokami? Byle by spełniało to założenia (np żeby była lista zgłoszeń postów u modów) czy raczej też to trzeba przedstawić gdzieś jakoś wcześniej przed implementacją do akceptu?

Do pkt 2 taki prosty przykład:
https://github.com/adam-boduch/coyote/issues/456 (obrazek wychodzi poza ekran na mobile). W gruncie rzeczy obrazek nie wychodzi poza ekran tylko na mobile, ale także na desktopach. Wystarczy wrzucić jakiś w rozdzielczości 5k. Najprostsze rozwiązanie to ustawić w stylach maksymalną szerokość na 100%, ale czy ktoś ma takie rozwiązanie pierw klepnąć? Tu przykład jest trywialny, ale przy jakichś większych modułach może się okazać, że ktoś włoży naprawdę dużo pracy w coś, co potem może zostać odrzucone.

Jeżeli takie rzeczy są jednak gdzieś opisane to chętnie się z tym zapoznam ;)

0

Ad 1. Tak.
Ad 2. Przeglądasz listę zadań które mają status "bug" albo "feature" i możesz wykonać to zadanie. Tworzysz po prostu forka projektu i następnie, gdy praca jest ukończona, dodajesz pull request. Jeżeli masz jakieś pytania, sugestie, to oczywiście przed rozpoczęciem pracy, można dodać komentarz w danym issue.

1 użytkowników online, w tym zalogowanych: 0, gości: 1