Closed potiuk closed 4 years ago
@potiuk Hej, Na wszystkie issue odpowiedzieliśmy. Dużo z nich nie ma związku z nami a duża częśc powinna być przekierowana do https://github.com/opentrace-community/opentrace-cloud-functions
Odpowiem poraz drugi na to samo. Pana posty zakrawają o spam.
Pozdrawiam Issue do zamknięcia. Wszystko zostało wyjaśnione.
Nie chodzi mi odpowiedź tylko o wdrożenie zmian. Jednak nalegam na otwarcie.
Czy to jest właśnie ta otwartość i transparentność w temacie ?
Nalegam na re-open zamkniętych issue. Issue zamyka się po ich:
Wtedy issue wraz z komentarzem można zamknąć.
Na razie to wygląda jak wynajęcie armii rosyjskich trolli do zamykania issue zamiast ich czytania i naprawiania. To scenariousz jeszcze gorszy niż wcześniejszy.
@potiuk proszę zaalarmuj o tym Panoptykon - art wyjdzie jutro - mogą go jeszcze uzupełnić o powyższą nietransparentność.
@potiuk jesteś w stanie dać na małpkę tu wszystkich programistów pracujących w tym projekcie aby wiedzieli że należy zacząć od czytania zamkniętych issue? Niestety nie wiem jak uzyskać tą listę tu na GitHubie. Dostaną wtedy e-mail i przeczytają.
@Tarvald rzygać mi się chce suchymi zapewnieniami oraz taką właśnie manipulacją jaką wskazał w tym wątku @potiuk.
@SeraMoon @potiuk Otrzymaliście wyczerpujące wyjaśnienia na każdy z tematów.
Pozdrawiam
Problemy nie zo
@SeraMoon @potiuk Otrzymaliście wyczerpujące wyjaśnienia na każdy z tematów.
Pozdrawiam
Deklaracje != poprawienie problemów. Issue nie powinny być zamykane bez ich poprawienia. Jeszczed nigdy czegoś takiego nie widziałem w żadnym projekcie.
@SeraMoon @potiuk Otrzymaliście wyczerpujące wyjaśnienia na każdy z tematów.
Pozdrawiam
Nie otrzymaliśmy i nalegamy na re-otwarcie tych wątków. 🤦 Brak Committee uniemożliwia odwołanie się od decyzji. #143
@potiuk potwierdzam, ja też nie widziałam czegoś takiego w żadnym projekcie. Nieaktualne speki widziałam, ale nie zamykanie issue przed usunięciem problemu, którego dotyczą.
Dla nietechnicznych: i programistów początkujących: issue (zgłoszenie) trzyma się w stanie otwartym (open / opened / re-open, new) do czasu kiedy nie zostanie załatany błąd i sprawdzone rozwiązanie. Są potrzebne więc 3 etapy:
Zamknąć można zgłoszenie jeszcze w przypadku kiedy jest nieprawidłowe. Jednak wtedy należy udowodnić jego nieprawidłowość komentarzem.
Nie cierpię JS5. Wolę programować w ES2015.
"Closed" i jednocześnie "0 of 7 tasks complete". Super.
Nie spotkałem się jeszcze z zamykaniem issue przed rozwiązaniem.
Uważam, że niektóre issue można było zamknąć na zasadzie, że nie jest to issue z którym można coś zrobić, naprawić (ratingi) lub dotyczy czegoś, co w końcu z tego co rozumiem nie powstanie (QR kody). Tylko to należałoby tam podać jasny powód dlaczego to jest "not an issue" lub "won't fix".
Pozostałe zgodnie z podstawowymi zasadami należy trzymać otwarte dopóki nie zostaną finalnie rozwiązane.
Co do przerzucenia odpowiedzialności na bibliotekę - to by było OK gdyby ta część była opcjonalna. Czyli np. macie swój soft i niektórzy używają go razem z zewnętrzną biblioteką lub innym softem i narzekają, że to nie działa lub nie jest bezpieczne. Tutaj jest inaczej - importujecie tamto rozwiązanie (opentrace), więc odpowiadacie za luki spowodowane jego użyciem. To nie może być won't fix - powinniście albo to naprawić albo nie używać.
To takie moje uwagi jako programisty zajmującego się nieco innymi rzeczami i do tej pory tylko obserwującego dyskusję.
Nie spotkałem się jeszcze z zamykaniem issue przed rozwiązaniem.
Ja się z tym spotkałem w projekcie Signal. Wszystkie issue powiązane z dostosowaniem aplikacji do polityki F-Droida były od razu zamykane i blokowane. Było to po prostu niezgodne z kierunkiem rozwoju projektu i z ich potrzebami. (to było kilka lat temu, nwm jak jest teraz)
Co za małpki pracują w tym projekcie to ja nawet nie wiem typowa państwówka robiona na odwal się xD
Ja się z tym spotkałem w projekcie Signal. Wszystkie issue powiązane z dostosowaniem aplikacji do polityki F-Droida były od razu zamykane i blokowane. Było to po prostu niezgodne z kierunkiem rozwoju projektu i z ich potrzebami. (to było kilka lat temu, nwm jak jest teraz)
Jeszcze rozumiem, że feature requesty można w pewnych sytuacjach tak zamykać bo kierunek totalnie niezgodny z wizją itp., ale nie issue (problemy z prywatnością i bezpieczeństwem).
Jeśli "transparentność" i "otwartość" mają być realizowane właśnie w taki sposób jak pokazuje Pan Artur Slomowski @Tarvald, to życzę powodzenia.
A jak jeszcze macie kogoś z MC od PM-owania i dzieją sie takie rzeczy... to bardzo ciekawie by było.
@piotr-zuralski Tak jak pisałem wcześniej w wielu miejscach (facebook, linkedin, github).
Zachęcamy do zakładania nowych wątków zgodnych z #147
Komentarze do #147 będą mile widziane w osobnych wątkach. Wątek główny pokrywa za dużą tematyke, żeby można prowadzić w nim dyskusje.
Na GH nadal są prowadzone prace porządkowe.
Prosimy o wyrozumiałość i pomoc w postaci Pull Request'ów. Każdy może zaproponować poprawkę do każdego z 4 repozytoriów.
@Tarvald właśnie przejrzałem część issues, dobrze, że zmieniliście zdanie 🙂 👍
Is your feature request related to a problem? Please describe.
Zasadą jest że "issue" na githubie zamyka się, kiedy dana funkcjonalność zostanie zrealizowana a nie, kiedy jest zadeklarowana. Niestety twórcy aplikacji pozamykali sporo issue jedynie deklarując rozwiązania dotyczące prywatności, bez implementacji i bez wdrożenia rozwiązania.
Uważam to za przedwczesne, zwłaszcza że wyjaśnienia w niektórych issue są niepełne, więc aby pomóc twórcom aplikacji stworzyłem zbiorcze issue w którym umieściłem te rozwiązania, które zostały zadeklarowane jako "zrobimy", ale też te, które należy wyjaśnić, uzupełnić dokumentację etc.:
Bardzo bym prosił o nie zamykanie tego issue, jako że pomoże on Twórcom aplikacji śledzenie co jeszcze zostało do zrobienia - głównie w kwestii prywatności.
Describe the solution you'd like Kod, dokumentacja, wyniiki audytu i wszystkie pozostałe artefakty powinny być publicznie dostępne w tym repozytorium
Describe alternatives you've considered Ponowne otwarcie faktycznie nie wdrożonych issue - ewidentnie nie jest to na rękę osobom tworzącym aplikację.