Sabotażysta w repozytorium serwisu

Dodałem do githuba tego serwisu kilka issues, których implementacja byłaby na plus dla projektu Coyote:

• https://github.com/pradoslaw/coyote/issues/787 (zamknięty bez rozwiązania)
• https://github.com/pradoslaw/coyote/issues/788 (otwarty)
• https://github.com/pradoslaw/coyote/issues/789 (otwarty)
• https://github.com/pradoslaw/coyote/issues/790 (zamknięty bez rozwiązania)
• https://github.com/pradoslaw/coyote/issues/791 (otwarty)

Jak widać, część z nich została zamknięta jako wykonana:

Ale tak naprawdę te issues nie zostały wykonane.

Przykro mi to stwierdzić. Niestety to jest sabotaż rozwoju tego serwisu.
Uprzedzenia do użytkownika nie usprawiedliwiają olewania zgłoszonych przez niego problemów i sugestii.

Nawet jeśli główny programista zamknął te issues nie z powodu uprzedzeń do użytkownika, tylko np. nie miał chęci na ich realizację, to powinien je zostawić otwarte, żeby jego ewentualny następca, albo niezależny kontrybutor się tym kiedyś zajął.

@pradoslaw napisał niedawno w komentarzu na mikroblogu:

Nie jestem w stanie czytać wszystkiego, a już na pewno wchodzenie w dyskusje z osobami, które cały czas widzą jedynie problemy, a nie dają pomysłów na rozwiązania też nie jest w mojej naturze.

Dodałem problemy i sugestie rozwiązania w systemie do tego przeznaczonym. Tak, żeby nie umknęło.
I sabotażysta dopilnował, żeby jednak to umknęło.

@pradoslaw: skoro nie czytasz wszystkiego, to może naprawdę wiele rzeczy do Ciebie nie trafia do rozważenia, właśnie przez Twoją prawą rękę?
Osobę, która filtruje dla Ciebie informacje o tym, co się dzieje w serwisie, a także w repozytorium? Zaglądasz czasem do repozytorium Coyote?

Gdybyś wcześniej trochę czytał i odpowiednio reagował, to teraz ludzie oznaczaliby Cię znacznie rzadziej i byś miał mniej do czytania.
Postanowiliście gdzieś po drodze nie reagować na zgłoszenia, więc ilość problemów wzrasta zamiast spadać.

Spine napisał(a):

Ale tak naprawdę te issues nie zostały wykonane.

Przykro mi to stwierdzić. Niestety to jest sabotaż rozwoju tego serwisu.

Może autor jest (ex)googlersem? Tam to standardowa praktyka a mierni tam chyba nie robią, c' nie?

Dodałem Możliwość uploadu plików .py jako załaczników https://github.com/pradoslaw/coyote/issues/792.
Dodałem Dodanie treści komentarza do powiadomienia mailowego o nowym komentarzu https://github.com/pradoslaw/coyote/issues/793.

Riddle napisał(a):

Dodałem Możliwość uploadu plików .py jako załaczników https://github.com/pradoslaw/coyote/issues/792.

Mój issue nie dotyczył dodawania pojedynczych rozszerzeń do whitelisty, tylko zastąpienie whitelisty blacklistą.

https://github.com/pradoslaw/coyote/issues/787

Proponuję zmianę whitelisty na blacklistę, jeśli w ogóle chcemy nie dopuszczać jakiegoś rozszerzenia, np. *.exe.

Dodasz *.py i co jeśli ktoś będzie chciał dodać źródło *.pas? Albo *.java? Albo *.cs?

Riddle napisał(a):

Dodałem Dodanie treści komentarza do powiadomienia mailowego o nowym komentarzu https://github.com/pradoslaw/coyote/issues/793.

Nie musiałeś nic dodawać, wystarczyłoby gdybyś otworzył, to co zamknąłeś:
https://github.com/pradoslaw/coyote/issues/790

Jeszcze jedno...

Riddle napisał(a):

Dodałem Możliwość uploadu plików .py jako załaczników https://github.com/pradoslaw/coyote/issues/792.

Jeśli nie trollujesz...
Jeśli rzeczywiście interpretujesz opisy tasków ( https://github.com/pradoslaw/coyote/issues/787 ) w taki sposób...
To lepiej czytaj te opisy dokładniej, od początku do końca.
Bo inaczej realizujesz zupełnie inne zadanie, niż planowano.

W sumie to ja nie wiem co ma na celu zamykanie issue stworzonego przez kogoś innego, ale tworzenie dokładnie takiego samego tylko założonego przez siebie?

Jest w tym jakaś logika?

Pewnie nabijanie statystyk na swoją korzyść, nic innego mi nie przychodzi do głowy. Albo po prostu robienie tylko "swoich" bo taka jest konwencja czy coś

@anonimowy: Ale to jest projekt open source...
Każdy może być kontrybutorem. Bez sensu jest dublowanie każdego issue, który napisał ktoś inny.

To lepiej czytaj te opisy dokładniej, od początku do końca.
Bo inaczej realizujesz zupełnie inne zadanie, niż planowano.

Tak jeszcze dodam jedną rzecz - prezentujesz bardzo roszczeniową i niefajną postawę @Spine. Co znaczy "zadanie jakie planowano"? Kto planował?

Moim zdaniem (jeśli jestem w błędzie/coś źle rozumiem to mnie proszę naprostuj) sytuacja wygląda tak, że to jest/był Twój pomysł zmiany sposobu przesyłania plików. Zrobiłeś w tej sprawie zgłoszenie i tyle. Ale to, że Ty (albo ktokolwiek inny) sobie czegoś zażyczył, nie oznacza, że to ma być wdrożone, a tym bardziej nie posuwałbym się do mówienia o czymś, że zostało zaplanowane.

I żeby była jasność - co do sensu proponowanej zmiany to ją w pełni popieram. O wiele lepszą opcją jest puszczenie wszystkiego z określonymi wyjątkami, niż jedynie plików, które są dozwolone. Także nie wiem i nie rozumiem, dlaczego to tak działa, pewnie jakieś naleciałości z ostatnich 20 lat, których odkręcenie by wymagało w członek dużo pracy. Tak czy siak - to może być ewentualnie powód odrzucenia danego zgłoszenia, albo wrzucenia go gdzieś daaaaaleko na koniec listy TODO. Tylko podkreślam - nie mam zastrzeżeń do samego pomysłu zmiany sposobu działania wysyłki załączników, jedynie nie podoba mi się Twoje podejście: @Spine zarządził, @Riddle ma od razu to zrobić, bo zlecenie od @Spine wpłynęło i "zostało zaplanowane".

@cerrato: Włodarze serwisu są współodpowiedzialni za roszczeniową postawę użytkowników.

Im dłużej użytkownik czeka na rozpatrzenie zgłoszonej poprawki, która jak najbardziej zasługuje na wykonanie, tym bardziej sceptyczny staje się użytkownik.

A jak już ktoś wreszcie zareagował na zgłoszoną poprawkę, to złośliwie ją przerobił, żeby to nie było rozwiązanie zasugerowane przez użytkownika.

Włodarze postanowili karać UX wszystkich użytkowników tylko dlatego, że mają uprzedzenia do użytkownika zgłaszającego poprawkę. To nieprofesjonalne zachowanie.

cerrato napisał(a):

To lepiej czytaj te opisy dokładniej, od początku do końca.
Bo inaczej realizujesz zupełnie inne zadanie, niż planowano.

Tak jeszcze dodam jedną rzecz - prezentujesz bardzo roszczeniową i niefajną postawę @Spine. Co znaczy "zadanie jakie planowano"? Kto planował?

Tutaj mam na myśli komunikację @Riddle z @pradoslaw, czy innym Dizajnerem. Jeśli @Riddle w taki wybiórczy sposób traktuje zadania, które od nich dostaje... W taki sposób jak mój issue, to coś jest nie w porządku.

Włodarze postanowili karać UX wszystkich użytkowników tylko dlatego, że mają uprzedzenia do użytkownika zgłaszającego poprawkę. To nieprofesjonalne zachowanie.

To jest Twoja opinia. Może masz rację, ale równie dobrze jest szansa, że tak samo by zostało potraktowane zgłoszenie, jakbym np. ja je wstawił.

Także mamy tutaj trzy rzeczy do przegadania/omówienia/zastanowienia się:

1. czy Twoja postawa jest OK. Może masz rację, że ona wynika z wcześniejszych doświadczeń. Ogólnie mam mocne (graniczące z pewnością) przekonanie, że obie strony są niefajnie nastawione: z jednej strony użytkownicy czują się olani, z drugiej "zarząd" czuje się przytłoczony negatywnymi reakcjami i falą krytyki. Mam wrażenie, że czasem było tak, że cokolwiek by zrobili, to tak dla zasady pewna grupka userów by pisała, że to jest do bani. Może przydałby się taki reset - zaczęcie od nowa, bez tych animozji, założenie dobrej woli z obu stron i próba dogadania się. Co o tym sądzicie?
2. Czy Twoje zgłoszenie było zasadne
3. Czy taki sposób rozpatrywania/reagowania na zgłoszenia jest OK

@pradoslaw może warto doprecyzować/określić zasady dotyczące wkładu społeczności w rozwój kodu serwisu?

Obecnie wydaje się, że brakuje podstawowych informacji:

• czy licencja MIT dla Coyote jest aktualna po zmianie właściciela
• jak wygląda cykl życia zgłoszeń typu "issues" -> rodzi to wątpliwości jak w tym wątku (zamknięte issue bez jakiegokolwiek komentarza na GH).
• jak wyglądają zasady kontrybuowania do tego konkretnego projektu open source
• jeśli pull requesty mają spełniać jakieś wymogi, to brakuje opisania tychże wymogów

Brak zasad prowadzi do niepotrzebnych dyskusji. Mogą być proste, ale jasne, np. "mnie, jako @pradosalwa, nie interesują zgłoszenia społeczności, wszystkie decyzje podejmuje wyznaczony Nadszyszkodwnik, koniec i kropka". Jeśli jednak głos społeczności jest brany pod uwagę, to co stoi na przeszkodzie opisania tychże zasad na GH?

@cerrato: to niech góra wyjdzie i powie jak to ma wyglądać. Ludzie się tu produkują na darmo a potem tematy giną w odmętach albo są zamykane na GH. Zakładam że wszyscy jesteśmy dorosłymi ludźmi i trzeba to załatwić po dorosłemu

Klaun napisał(a):

W sumie to ja nie wiem co ma na celu zamykanie issue stworzonego przez kogoś innego, ale tworzenie dokładnie takiego samego tylko założonego przez siebie?

Jest w tym jakaś logika?

Oczywiście że jest