chystáme sa po vzore 18f v USA a GDS v Singapure vyskúšať “mikroobstarávanie”. Máme celkom dobre definovanú funkcionalitu, ktorú treba dodať. Máme celkom jasné podmienky akceptácie, kód je
a bude open source. Máme na toto maximálny budget 2000 eur, ktorý na túto funkcionalitu zasponzoruje Nadácia zastavme korupciu.
O čo ide: Chceme z projektu ITMS2014+ dostať dáta k nám do ekosystému. Cieľom je obstarať “pull-request”, ktorý bude spĺňať podmienky popísané v zadaní.
Prečo toto robíme?
Túto funkcionalitu NZK potrebuje.
My v Slovensko.Digital, chceme zhŕňať dáta v ekosystéme a ponúkať nad nimi ďalšie možnosti využitia (napríklad analytiku).
Chceme ukázať, že rozvoj informačných systémov, ktoré sú opensource sa dá robiť aj inak ako megalomanskými priamymi rokovačkami alebo obstarávaniami, kde sa reálne nikto iný zapojiť nevie.
Chceme dať možnosť zapojiť sa komunite aj na komerčnej báze, nie len dobrovoľnícky.
Dávame na diskusiu draft návrhu zadania/mikroobstarávania:
Takze experimentem v komercnim/3tim sektoru (ktery se nemusi ridit zadnou legislativou okolo VO apod) chcete ukazat jak to ma delat verejny sektor (ktery se musi ridit legislativou)? To mi prijde jako kdyz si chcu doma postavit maly dron a ten postup pak aplikovat na stavbu letadla pro dalkove lety. Nebo co chcete dokazat timto experimentem?
Legislativa sa da tiez zmenit. V USA a v Singapure toto urobit ocividne vedia. Viem si predstavit toto robit cez ramcovky ako napriklad tu. Netvrdime, ze takto sa maju obstaravat obrovske systemy. Obrovske IT systemy su podla mna problem sam o sebe.
Napriklad, ze opensource ma zmysel a ake to otvara moznosti. Moze byt ci malo?
Inac vec bude ked sa z neho budu odvodzovat nejake priame zavery pre “makroobstaravania”. Ale asi je kazdemu jasne (vratane experimentatorov) ze iste “vyvojove kroky” sa nedaju len tak preskocit. Vynimkou bola Velka francuzska burzoazna revolucia, ale tam zase padali hlavy. Doslova, nie v zmysle ze ludia prichadzali o posty.
P0706 (súčet) je na rovnakej úrovni ako dielčie ukazovatele. Tým pádom je nutné, aby človek vedel, ktorý konkrétny ukazovateľ môže zarátať, aby nedošlo k chybnému výsledku. To môže znamenať preštudovanie každého projektu alebo výzvy pred hromadným spracovaním dát.
Neviem, či sa to týka len merateľných ukazovateľov, alebo aj iných dát.
…len upresnim ze to nie je motodicky problem ITMS2014+, ale metodicky problem zadefinovania ciselnika meratelnych ukazovatelov a intervencnej logiky na urovni gestora predmetneho ciselnika a potom aj jednotlivych RO/SO pri definovani relevantnych ukazovatelov v ramci vyziev…
API len spristupnuje data…ci obsahovo ukazovatele korektne suvisia a suhlasia to uz API neriesi…
…ale je fajn ze sa takto poukaze na niektore bludy…
V nadvaznosti na dopyty k logike API vo fore ITMS2014+ OpenData a aj tuto aktivitu, sa ponukam ako domenovy konzultant predmetneho API pre zadavatela toho obstaravania…
Takto aspon budem lepsie vediet na co sa v popise API zamerat…
Taketo nieco by mal spravit aj UPVII (alebo samotne institucie), ale v sumach o jeden rad vyssich a malo by sa to tykat zlepseni uz existujucich projektov, ktorym casto krat chyba dorobenie detailov.
Napriklad (sumy iba typujem):
zlepsenie UI edesk schranok na slovensko.sk, rozpocet 20 000,
implementacia REST sluzieb pre RFO, rozpocet 50 000,
popis webovych sluzieb ala swagger, rozpocet 5000,
