RV 62/2020 Doporučení k užívání technických systémů strany

[Jan.Bednarik]

Na základě podnětu R#34037 zahajují jednání k Doporučení k užívání technických systémů strany.

Návrh usnesení A:

V souvislosti s usnesením RV 48/2020 doporučuje Republikový výbor členům a orgánům strany využívat následující oficiální stranické systémy k níže uvedeným účelům:

• Evidence kontaktů a schůzek: Pro plnění povinnosti všech představitelů strany zveřejňovat informace o svých lobbistických kontaktech široké veřejnosti dle § 4 PřL.
• Matomo: Pro monitoring návštěvnosti webových stránek jako náhrada služby Google Analytics v souvislosti s usnesením CF 28/2017.
• Redmine: Pro řízení projektů a sledování plnění programu, provoz podatelen v souvislosti s § 25 OŘ, vykazování času a komunikace s dodavateli v souvislosti s § 7 odst. 3 PPU, § 8 odst. 4 PPU a § 18 odst. 1 PPU.
• Wiki: Pro zveřejňování základních údajů o týmu v souvislosti s § 2 OŘ-ZaTyS (pokud tým nemá jinou webovou prezentaci), tvorbu a sdílení návodů a vedení sbírky vnitřních předpisů.
• Fórum: Pro korespondenční jednání týmů v souvislosti s OŘ-ZaTyS a Jednacím řádem celostátního fóra. Dále pro vzdálenou textovou komunikaci týmů se zaručenou stranickou identitou účastníků a trvalou archivací příspěvků (včetně zápisů), procedurální hlasování, hlasování orgánů, které mají hlasovat veřejně, sběr podpory členských podnětů a nezávazné ankety. Není vhodné pro tajná a rozhodující hlasování.
• Helios: Pro rozhodující tajná korespondenční hlasování.
• Maják: Jako redakční systém pro veškeré webové prezentace.
• CodiMD: Pro společnou tvorbu textových dokumentů, například zápisů ze schůzí, které není potřeba dlouhodobě archivovat.
• Mrak: Pro dlouhodobou archivaci dokumentů. Dále pro vedení kalendářů (Calendar), hlasování o termínech schůzek (Polls) či organizaci práce týmů (Deck/Tasks).
• LimeSurvey: Pro ankety a dotazníky většího rozsahu, zejména je-li žádoucí zajistit anonymitu respondentů nebo omezit možnost hlasovat vícekrát.
• Maily: Stranické emailové aliasy je doporučeno používat pro komunikaci s vnějšími subjekty. Vzhledem k tomu, že u emailu obecně není možné zaručit identitu odesilatele, nedoporučuje se je používat pro závaznou vnitřní komunikaci.
• Mumble: Pro vzdálenou hlasovou komunikaci týmů.
• Jitsi: Pro vzdálenou hlasovou komunikaci týmů či jednotlivců s možností přenosu obrazu a sdílení obrazovky.
• Zulip: Pro vzdálenou textovou komunikaci se zaručenou stranickou identitou účastníků. Zejména pro komunikaci týmů (např. orgánů a klubů) v reálném čase a jako doplněk oficiální komunikace v jednáních či podatelnách. Není vhodný pro komunikaci, která má být trvale a dostupně archivována (v tomto směru je lepší využít Fórum).
• PiTube: Pro přenos videa ze schůzí a dalších akcí širokému publiku.

Republikový výbor nedoporučuje využívat následující oficiální stranické systémy, jelikož je v jednání přerušení jejich provozu (a archivace stávajícího obsahu):

• Piratepad: Jako nástroj pro společnou tvorbu jednodušších textů je vhodné využívat CodiMD.

Termíny:

• doba pro navrhování do 26.12. 10:00
• doba na rozmyšlenou do 27.12. 10:00
• rozhodující hlasování 27.12. 10:00 až 30.12. 22:00

[Andrej.Ramaseuski]

Nejsem si jisty spravnym znenim popisu ke CodiMD. Souhlasim z tim, ze aktualne je nejvodnejsim dokumentem pro kolaborativni eeditaci, ale nesouhlasim z tim, ze zapisy ze schuzi neni potreba dlouhodobe archivovat. Rozumim tomu, ze smyslem napsaneho je spis to, ze neni vhodna dlohodoba archivace dokumentu v CodiMD, ale dle toho jak je to napsany to neni zrejmy.

[David.Novak]

Díky za návrh usnesení.

Prosím, kdyby se někdo z TO mohl vyjádřit k tomuto:

1) Na wiki stránce je u Mraku, Zulipu, PiTube stav "testuje se". Systémy, co nejsou otestované, bych zatím nedoporučoval. Nebo podmínečně.

2) Mumble a Jitsi slouží oboje pro hlasovou komunikaci, proč se udržují oba dva? Lze rozlišit jejich případy užití? (Osobně jsem Mumble zatím nevyužil, Jitsi mi přijde OK.)

[Andrej.Ramaseuski]

Díky za návrh usnesení.

Prosím, kdyby se někdo z TO mohl vyjádřit k tomuto:

1) Na wiki stránce je u Mraku, Zulipu, PiTube stav "testuje se". Systémy, co nejsou otestované, bych zatím nedoporučoval. Nebo podmínečně.

2) Mumble a Jitsi slouží oboje pro hlasovou komunikaci, proč se udržují oba dva? Lze rozlišit jejich případy užití? (Osobně jsem Mumble zatím nevyužil, Jitsi mi přijde OK.)

1) zmena stavy na wiki je v pravomoci monokratickeho organu a muze byt zmenene ze dne na den. doporuceni ze strany RV muze teb proces podstatne zrychlit
2. mumble nekdy je mene narocny na datove prenosy a take na klientske zarizeni.

[Vojtech.Pikal]

Díky moc za návrh.

Chtěl bych jen podotknout, že když vidím wiki jako doporučený systém pro tvorbu návodů a zejména pro sbírku předpisů, tak se trochu bojím následného výkladu "wiki je jen doporučená sbírka předpisů, mi máme svůj řád jinde"; je nějaká spolupráce s orgány, které mají vedení různých evidenců na starost na toto nějak navázat?

A druhá poznámka - vidím doporučenou sbírku předpisů, na wiki je asi i sbírka programových dokumentů; kde by ty měli doporučeně končit?

A třetí poznámka, už spíše k zamyšlení. Obecně trpím dlouhodobě tím, že není evidence rozhodnutí orgánů a ty jsou pak těžko dohledatelné. Přemýšlí se nad nějakým doporučením/řešením k tomuto?

[Andrej.Ramaseuski]

A druhá poznámka - vidím doporučenou sbírku předpisů, na wiki je asi i sbírka programových dokumentů; kde by ty měli doporučeně končit?

Myslim si, ze vzhledem k tomu, ze programove dokumenty jsou primarne urcene k prezentaci verejnosti, a, abychom to nemeli ve dvou mistech, je naprosto logicky, ze primarne by se meli zverejnovat na hlavnim stranickem webu. Wiki v dnesni dobe bych videl spis pro interni potreby a historii.

A třetí poznámka, už spíše k zamyšlení. Obecně trpím dlouhodobě tím, že není evidence rozhodnutí orgánů a ty jsou pak těžko dohledatelné. Přemýšlí se nad nějakým doporučením/řešením k tomuto?

Teoreticky by mohli byt na wiki. Alternativni varianty jsou mrak nebo gitlab. Pricemz, preferoval bych spis gitlab, protoze na mraku lide se casto pouzivaji uchylnou praxi vytvaret dokumenty v ofisnich formatech, coz za prve zpozadnuje obsah a semantiku ve prospech formatovani a vzhledu, a za druhe prakticky neumoznuje sledovani zmen. Coz je na wiki celkem v pohode, ale v gitlabu je jeste lepsi. Navic, gitlab, at je to repozitar, nebo wiki, ktera muze byt soucasti kazdeho projektu, nativne podporuje markdown, coz je dalsi vyhoda v porovnani s wiki a jeji vlastnim formatovacim jazykem. Vim ze byli pokusy udelat sbirku v githubu, a skoda ze projekt tak nejak zemrel, ale s vlastnim gitlabem muzeme udelat druhy pokus

[Vojtech.Pikal]

(Sbírka byl primárně přehled předpisů.)
U programových dokumentů imho potřebujeme taky mít k dispozici historri změn. Wím, že současný web to má, nevím jak "budoucí web"?

[Jan.Bednarik]

Hlasování zahájeno zde.

[Jan.Bednarik]

Hlasování bylo ukončeno, byla vybrána možnost A, usnesení bylo přijato.