RÉSZVÉTELI DEMOKRATIKUS ARCHITEKTÚRA

RÉSZVÉTELI DEMOKRATIKUS ARCHITEKTÚRA Magosányi Árpád

Magosányi Árpád: Részvételi demokratikus architektúra

Kivonat Az előadás az informatikai architektúra eszközeivel próbálja megközelíteni korunk legfontosabb információelméleti kérdését: képes-e emberek nagy tömege intelligens közösségként viselkedni, és ha mégis, akkor ennek mik a feltételei? Az előadás épít a "szabad szofver mozgalom" című szociológiai kísérlet eredményeire, rendszerez a cél szempontjából fontosnak tűnő eredményeket, és felvillantja a lehetséges megoldás egyes elemeit. A kitekintés inkább vitaindító, mint "én megmondom a tutit" jellegű, és nem tartalmaz aktuál- vagy pártpolitikát.

Tartalomjegyzék 1.‍ A demokrácia..................................................................................................................................1 1.1.‍ Célkitűzések............................................................................................................................1 2.‍ Követelmények................................................................................................................................1 2.1.‍ Demokratikus célok..............................................................................................................1 2.2.‍ Szervezeti megfontolások....................................................................................................1 2.3.‍ Dokumentumszerkezet........................................................................................................1 3.‍ Irodalomjegyzék.............................................................................................................................2

1. A demokrácia A „politika” szó Arisztotelész Πολιτικά című könyve nyomán vonult be a köztudatba. A politika tárgya a kormányzás, vagyis a közösség ügyeinek elrendezése. Az emberiség története során már többféle módját kipróbálta a kormányzásnak, a különféle diktatúráktól a többé-kevésbé demokratikus rendszerekig. Fontos it szót ejteni az „Idióta” (ἰδιώτης) szó etimológiájáról is. Ez a régi görög nyelvben azokat a személyeket jelölte, akik nem vetek részt a közösség ügyeinek rendezésében, a politikában. A demokrácia az „emberek uralma”, amelyben a cél az lenne, hogy az ügyeket olyan módon oldják meg, ami a „a résztvevőknek eginkább jó”. A demokrácia egy módja a közvetlen demokrácia, amelyben minden résztvevő beleszól az ügyek alakulásába. Ez kis méretekben jól működik, de egyszerű információelméleti megfontolások1


kal belátható, hogy nagy méretekben nem működtethető: meghaladná a résztvevők információfeldolgozási kapacitását, gyakorlailag bármekkora is az. Ez az információáramlási korlát a demokrácia legnagyobb nehézsége. Hogyan lehetünk biztosak abban, hogy egy döntés konszenzuson alapul, ha az emberek legnagyobb része nem csak bele sem szólt, de nem is hallot arról, hogy a döntési helyzet egyáltalán létezik? Kinek van felhatalmazása meghozni egy döntést? A legitimációs kérdést az alábbi módokon szokták megoldani: • A képviseleti demokráciában a résztvevők választot képviselők útján kormányoznak. Ma nagy méretekben ez a leginkább elterjedt • A részvételi demokráciában mindenkinek joga van részt venni a döntésekben, és a döntéseket azok hozzák, akik ezt meg is teszik. Ennek leginkább működőképesnek tűnő formája a részvételi költségvetés, amely pl. Brazília Rio Grande do Sul tartományában több mint tízmillió fős méretben működik, képviseleti elemeket is tartalmazva. • A likvid demokráciában mindenkinek joga van részt venni a döntésekben, de a döntéseket az egyén másokra delegálhatja. Fontos megjegyezni, hogy a politikához is lehetséges az elméleti megalapozotság igényével nyúlni. Néhány példa: • Condorcet márki 1785-ben, több mint 200 éve fordítota le a matematika nyelvére a „a résztvevőknek leginkább jó” kifejezést, amely alapján egy olyan szavazási módszert alkotot, amely bizonyíthatóan megtalálja ezt a megoldást, ha létezik. A politikai döntéshozásban azóta sem használja senki, csak a Debian projekt. • Az információelmélet alapvető szabályai az emberek közöti kommunikációra is alkalmazhatóak. Ez nem csak azoknak a folyamatoknak a magyarázatára jó, amelyek a jelenleg tapasztalható korrupcióhoz és demokratikus deficithez vezetek, de talán felhasználható a hatékony kommunikáció megtervezéséhez is. • A dinamikus rendszerek elméletéből ismert a pozitív visszacsatolás és a rezonancia-katasztrófa fogalma. Ezek a fogalmak pl. egyszerűen alkalmazhatóak arra a helyzetre, hogy ma vannak olyan gazdasági érdekcsoportok, amelyek a politikát a saját érdekeik szerint tudják meghajlítani. Ez egyértelműen pozitív visszacsatolásos folyamat, tehát ha nem sikerül leállítani, az a politikai berendezkedés megváltozásához fog vezetni. A kérdés csak az, hogy milyen irányban. Azt sem szabad figyelmen kívül hagyni, hogy a demokrácia információáramlási korlátját az alkalmazot technológia is befolyásolja. Lehet hogy továbbra sem fognak meghatni a csongrádi cipőfelsőrész-készítők szempontjai, de talán arra van esélyünk, hogy legalább a minket közvetlenül érdeklő ügyekben időben megtudjuk hogy döntés készül, vagy a sokakat érintő ügyekben ki lehessen kényszeríteni a megfelelő döntést. Hogy lássuk, mit tehet a technológia, először tekintsük át azokat a célkitűzéseket, amelyek egy demokráciával szemben fennálnak:

1.1. Célkitűzések Egy demokratikus döntéshozatali mechanizmusnak az alábbi célkitűzéseknek kell megfelelnie:

2

1.‍ A demokrácia

• • • •

• •

Kooperatív: próbálja megtalálni „a résztvevőknek leginkább jó” megoldásokat, az együtműködésre, és ne az ellenségeskedésre ösztönözzön Részvételi: azoknak a tevékenysége számítson, akik tesznek valamit. Legyen képes a részvételi költségvetés támogatására. Likvid: ha valaki nem ismer egy témát, de megbízik valaki másban, tudja neki delegálni a szavazatát A valósággal kapcsolatban lévő: vegye figyelembe az információáramlási, szociológiai, stb. korlátokat, legyen képes hatni a valóságra (a kialakítot folyamatok támogatása, egyszer majd költségvetési támogatás), legyen flexibilisen a valós igényekhez alkalmazható. Elérhető: a résztvevők könnyen tudják használni, jelenjen meg számukra az őket érdeklő információ Interaktív: tartsa fenn az érdeklődést

2. Követelmények 2.1. Demokratikus célok A célok első csoportja magának a demokráciának a mibenlétével foglalkozik. Ezek a következőek: • Kooperatív • Részvételi • Likvid • A valósággal kapcsolatban lévő A követelmények levezetésekor tekintetel kell lenni mindenféle tényekre és összefüggésekre is. Ebben a témában az alábbiak tűnnek nyilvánvalónak: • Egy embert nem érdekelhet minden. Ez gyakorlatilag az információáramlási korlát másik megfogalmazása, a likvid célkitűzés indoklása, és a részvételi demokrácia legitimációs érve. • A szavazási rendszerek befolyásolják a szavazói magatartást. Ennek a ténynek bőséges az elméleti megalapozotsága a szavazás- és a játékelmélet területéről, és a szociológiai eredmények az elméleti eredményeket valódi emberek esetében is igazolják. • A Condorcet szavazási módszer direktben épít a „résztvevők számára legjobb” definíciójára. Nem véletlenül mércéje a szavazási módszereknek a Condorcet kritériumnak való megfelelés. A Condorcet módszer egyben a kooperációt is elősegíti. A fentiekből az alábbi elveket és követelményeket lehet levezetni: • Az inaktív szavazó szavazata legyen delegálva: Ez a likviditás és részvételiség célkitűzéséből fakad. A kérdés csak az, hogy hová delegáljunk, ha a szavazó nem rendelkezik a delegálásról. Legésszerűbbnek a csoport vezetője tűnik. • A szavazási rendszer segítse elő a kooperációt: Ez a kooperativitás célkitűzéséből fakad. Figyelembe véve, hogy a különféle kooperációt elősegítő szavazási

3


•

•

•

módszerek (szinte bármelyik preferenciális módszer) közül a Condorcet ráadásul maga a „résztvevők számára legjobb” definíciója, ezért logikus azt választani. A képet árnyalja az, hogy – pl a szavazás témájának előkészítésekor – szükség lehet egyszerűbb módszerekre, illetve követelmény a flexibilitás. Ezért azt mondjuk, hogy a Condorcet módszer az elsődleges, és másik módszer választásánál figyelmeztessen a rendszer. Flexibilitás a legjobb struktúrák és folyamatok megtalálásához: Ezt a valósággal kapcsolatban maradás célja diktálja; nem tudjuk, hogy milyen folyamatok válnak be legjobban az egyes célokra, hát legyen a rendszer alkalmas ezek megtalálására, hangolására. Legyen alkalmas döntéshozatali eszközként bármely szervezet (civil szervezet, önkormányzat, kormányzat, de akár a Parlament vagy egy cég) számára. Ezt is a valósággal kapcsolatban maradásból vezetjük le. Ezek közül néhány az egész projekt direkt céljába esik, a maradék pedig azért szerepel, hogy a flexibilitás igényét hangsúlyozza. Legyen képes költségvetés és számlák kezelésére, támogassa a gyűjtéseket. A részvételi költségvetés sikere az „alternatív” demokratikus kezdeményezések közöt azért annyira egyértelmű, mert maga a költségvetés nagyon jó mérő- és visszacsatoló eszközként működik. Ezért nem lehet ezt a témát figyelmen kívül hagyni, még ha rengeteg implementációs kérdést is felvet, és biztosan nem a 0.1-es verzió fogja tartalmazni. Bizonyos típusú civil szervezetek számára a gyűjtés szintén nagyon fontos tevékenység. Ennek része és folyománya a képesség pénzügyi műveletek végzésére.

2.2. Szervezeti megfontolások Az információáramlási korlátból az következik, hogy több kommunikációs csatornát kell kialakítani, méghozzá olyanokat, amelyeken egyenként feldolgozható mennyiségű információ áramlik az egyes résztvevők számára. Ezek a csatornák az emberek csoportjai; szervezetek, szervezeti egységek, projektek, stb. A csoportokkal kialakuló kommunikációs szerkezetet érdemes az információelmélet segítségével elemezni, és persze a szociológiai szempontok is fontosak. Ezeken kívül a delegálással kapcsolatos követelmények is szerepet játszanak. A szociológiai jellegű peremfeltételek az alábbiak: • Léteznek ideális csoportméretek. A Dunbar szám1 a közösségek ideális méretét írja le. Ennek felső határa az életcélszerű misszióval bíró csoportoknál (katonai egységek, törzsek) 150 körül van, az online közösségeknél 40-60 környékén. A gerillaháborúkban is komoly összefüggések vonatkoznak a csoportméretekre2. • Az egy ember által feldolgozható információnak nem csak – a Dunbar számban megmutatkozó – felső határa van, hanem egy alsó is: a motiváció fenntartásához szükséges a folyamatos információáramlás. • Általános emberi igénynek tűnik, hogy egy csoportnak legyen vezetője. Érde-

1 1 htp://www.lifewithalacrity.com/2004/03/the_dunbar_numb.html 1 2 htp://www.ted.com/talks/sean_gourley_on_the_mathematics_of_war.html 4

2.‍ Követelmények

kes módon nem igazán találtam tudományos igényű munkát ami ennek a miértjét boncolgata volna. • A valós életben nagyon sok véges erőforrás létezik, amelyek elég ha csak a különböző területekre, ingatlanokra, életközösségekre gondolunk. Ezek nagy része hierarchiába szerveződik (település/önkormányzati társulás/ország/unió). Ezekkel akkor lehet ésszerűen gazdálkodni, ha azok egyértelműen egy gazdához vannak hozzárendelve, ahol a gazdák struktúrája követi az erőforrás-struktúrát. A fentiekből következnek a szervezeti struktúrára vonatkozó követelmények: • A résztvevők csoportokba szerveződnek. Minden résztvevő pontosan egy „strukturális” csoportnak a tagja. A strukturális csoportok egy fát alkotnak, amelynek a leveleiben közvetlen tagok a résztvevők, a csomópontjainak tagjai pedig strukturális csoportok. • A csoportoknak lehetnek szervei (szintén csoportok), pozíciói (pl. vezető), és vannak közvetlen tagjai. Amikor a csoport közvetlen tagja egy másik csoport, akkor annak tagjai is a csoport tagjainak számítanak: mindenki, aki egy csoportnak akár közvetlenül, akár közvetve tagja, egy szavazati joggal rendelkezik. • A strukturális csoportok taglétszámára vonatkoznak olyan szabályok, amelyek azokat a Dunbar szám környékén tartják. A példában ez 30 és 80 közöti, de persze ez egy hangolható paraméter. • A kommunikáció robusztussá tétele érdekében fontos a kommunikációs csatornák redundanciája. Ezért önszerveződő csoportokat is létre lehet hozni, amelyekre nem vonatkoznak a strukturális csoportok megkötései. A fenti szerkezetben a strukturális csoport felel meg a „hivatalos” kormányzatnak. Nagy különbség persze, hogy ma a szavazókörzetek határait területi alapon húzzák meg, a méretük pedig befolyásolja a szavazás menetét. Fontos még, hogy ebben a rendszerben a közvetlen tagokkal rendelkező strukturális csoportok aránylag kis létszámú, egymást ismerő tagokból álló klánok. A klán szervező ereje bármi lehet: lehet klán egy tágabb család, egy utcaközösség, vagy egy civil szervezet. Sok szó esik arról, hogy a társadalom alapszövetét (amelyet hagyományosan a családban, az ugyanabba a templomba – a szocializmus idején pártalapszervezetbe – járók közösségében szokás megtalálni) a modern idők változásai kikezdték, és a társadalom atomizálódik. A javasolt struktúra talán egy olyan megoldást adhat a problémára, amely a mai idők sajátosságainak megfelel.

2.3. Dokumentumszerkezet A vázolt informatikai rendszer alapvető célja az emberek akaratának egyeztetése és publikálása. Ezeknek a dolgoknak a realizálására a legjobb ismert módszer a dolgok dokumentumba foglalása. Ezek lehetnek • vitaanyagok, • munkaanyagok, • nyilatkozatok, • szabályzatok, 5


• döntések, • stb. Lássuk, hogy mit kell ezeknek a dokumentumoknak tudniuk: • Legyenek a résztvevők akaratát kifejezni, • Tartalmazhassanak a szervezetre vonatkozó szabályokat (folyamatokat), amelyeket a rendszer kikényszerít • A rendszer egyszer képes legyen hatni a valóságra (pl. átutalás) • A jó információáramlást is elő kell segíteni A fentiekből következő követelmények: • A dokumentumok építőkövekből épülnek fel (ezzel semmi újat nem mondtunk persze) • Az épitőkövekkel meg lehet határozni a dokumentum struktúráját és tartalmát (ez sem újdonság) • A dokumentumok feldolgozásának menetét is dokumentumok, és azok építőkövei határozzák meg • A feldolgozás metaadatokra épül, tehát az ezeket tartalmazó építőkövekre is szükség van: ◦ állapot ◦ tulajdonos ◦ történet • A feldolgozáshoz szükség van a felhasználókról és csoportokról szóló adatokra is, tehát azokat is reprezentálni kell tudni a dokumentumokban • A folyamatok leírását kiszolgáló építőkövek ◦ elegendő leíró erővel kell rendelkezzenek a rendszer bármilyen folyamatának leírásához, és ◦ lehetővé kell tenniük a világban zajló történéseket indukálni (pl. átutalás) • Minden elemnek kommentelhetőnek kell lennie ◦ A kommenteket szálakba rendezze

2.4. Részvételiség A célkitűzések egy része arra vonatkozik, hogy a rendszer valóban használható is legyen, tehát • elérhető • részvételi • interaktív Ezzel kapcsolatban fontos megfigyelés a szabad szofveres projectekből is, hogy • az alacsony belépési küszöb rendkívül fontos, és • a visszacsatolás fontos az emberek mozgósításában Emiat a következő alapelveke azonosíthatjuk: • Legyen alacsony a belépési küszöb, legyen könnyű részt venni • Minden legyen kommentelhető A fentiekből a következő követelmények származtathatóak: • Legyen egyszerű regisztrálni

6

2.‍ Követelmények

• • •

Mindenhez lehessen megjegyzéseket fűzni, a megjegyzéseket szálasan kezelje a rendszer A folyamatlépések generáljanak értesítéseket Legyen intuitív a használata ◦ A csoportok, folyamatok, szavazás, stb. Grafikusan egérhúzogatással legyenek kezelhetőek

2.5. Megbízhatóság, biztonság Mint látuk, a rendszernek eléggé ambíciózus céljai vannak, amelyek közöt szerepel a világmegváltás, fontos kérdések eldöntése, és erőforrásokkal való gazdálkodás. Ebből következően nem csak az fontos, hogy biztonságosan, manipulálhatatlanul működjön, hanem az is, hogy az emberek ezt elhigyjék, és megbízhatónak tartsák a rendszert. Ugyanakkor • A demokrácia új módszereivel való próbálkozás támadásokat és FUD kampányokat generál Mint láthatjuk, ez a probléma is összetetebb annál, mintsem pusztán technológiai eszközökkel kezelhető lenne. De nézzük, hogy a technológia mit tud tenni: • A publikus adatok legyenek elérhetőek • A személyes adatok legyenek védve, kezelődjenek elkülönülten • A konfigurációs adatok (azauthentikációs kulcsok kivételével) és a végrehajtható állományok legyenek elérhetőek a nyilvános ellenőrzés céljából • A rendszer legyen nyílt forrású • A naplók pszeudonimizáltak legyenek • A naplóadatok (a pszeudonimitást feloldó információk kivételével) legyenek elérhetőek nyilvános ellenőrzés céljából • Szerepkör alapú hozzáférésvezérlés • A rendszer biztonsági tulajdonságait formális audit erősítse meg Különösen az ellenőrizhetőség és a személyes adatok védelmének igénye közöti ellentmondások feloldása, a pszeudonimitással kapcsolatos részletek kidolgozása nem lesz egyszerű.

3. Alkalmazás architektúra Mint láthatuk, a rendszerrel szemben még ezen a magas szinten is eléggé összetet követelményrendszert sikerült felállítanunk. Ráadásul ezeknek a követelményeknek nagy része a szervezeti struktúrára és a folyamatokra vonatkozik. Az elmúlt ötezer évben nem sikerült megtalálni az ideális politikai szervezetet és folyamatokat, és bár elég nagyképű vagyok, annyira azért nem, hogy azt mondjam, hogy az általam felvázoltak pontosan így kell működjenek. Tehát az alkalmazásnak képesnek kell lennie tükrözni bármilyen szervezeti felépítést és folyamatot. Ezen kívül láthatuk, hogy még ezen a magas szinten is eléggé sokféle entitást sikerült azonosítani. A folyamatkezelési és biztonsági követelmények pedig megkövetelik, hogy minden entitásra vonatkozóan lehessen műveleteket végezni, és azokat kontrollálni. Ha nem akarjuk a következő kétszáz évet kódolással, az azutáni háromszázat hi7


bajavítással, és még háromszázat az audital tölteni, akkor mindezek kezelésére egy flexibilis keretrendszert kell használni, amely • sokféle entitást képes kezelni • az entitások hierarchiákba vannak rendezve benne • a műveletek és azok kontrollja a hierarchia minden szintjén biztosítot Azért nagyon messzire nem kell menni. Az első két problémát a mesterséges intelligencia kutatás és a szakértői rendszerek jól kezelik, az arhcitektúra lerakatok (repository) pedig ezt a tapasztalatot kiegészíteték a hozzáférésvezérlési kontrollal is. Tehát a feladatot le lehet redukálni a következő komponensekre: • Egy architektúra lerakat felelős a perzisztenciáért • A lerakat interfésze nyújta a résztvevők számára a hozzáférést • A lerakatban végzet módosítások eseményei hajtanak egy folyamatmotort, ahol a folyamat definíciója szintén a lerakatból származik. A jó hír az, hogy folyamatmotoroknak bővében vagyunk, az architektúra lerakat készítéséhez szükséges tapasztalat rendelkezésre áll. A rossz hír pedig az, hogy jó nyílt forrású lerakat implementáció jelenleg nincsen.

3.1. Dolgok A lerakat működésének megértéséhez kalandozzunk el kicsit az ontológia területére. Ez a filozófiának az az ága, amely a dolgok természetével, a létezéssel, a valóság mibenlétével, és ezek kategorizálásával foglalkozik. Elegendően elvont ahhoz, hogy egy IT architekt ne érezze lealacsonyítónak az alkalmazását, ezért mi is szoktunk vele fog lalkozni. A lerakat adatszerkezetét egy ontológia határozza meg. Gyakorlatilag az ontológia definiálja azt a nyelvet, amelyet a lerakatban használunk. Az ontológiát magát is a lerakatban tárolva érhetjük el, hogy egy flexibilis rendszert kapunk, ahol a különböző entitástípusok meghatározását is a rendszeren belül végezhetjük el. Az ontológia alapja a „dolog”, „létező”, angolul Thing, amelyből minden más származik. Vizsgáljuk meg azt, hogy mit tudunk a dolgokról: • Minden egy dolog • A dolgoknak van típusa, ami szintén egy dolog • A dolgok közöt összefüggések vannak. • Az összefüggés szintén egy dolog. • Az összefüggéseket fel lehet bontani két dolog közöti összefüggésekre, ahol ◦ Az összefüggésnek van egy forrása, ami egy dolog, és ◦ Az összefüggésnek van egy célja, ami szintén egy dolog Tehát a feladat „mindössze” annyi, hogy a dolgot modellezzük, és készen vagyunk. Illetve kell még • változáskezelés • hozzáférésvezérlés • lerakatok közöti hivatkozások • felhasználói felület 8

3.‍ Alkalmazás architektúra

• • •

a mindezeket támogató ontológia a dokumentumok, és az építőköveik ontológiája beleértve a folyamatvezérlést is

Ha a folyamatvezérlést olyanra alakítjuk, hogy azt egy folyamatmotor megérti (pl BPEL), és a változáskezelés során keletkeznek események, akkor „csak” össze kell kötni a folyamatmotort és a (publikus és privát adatokat hordozó) lerakatokat, hogy működő rendszert kapjunk. … amelyben létrehozhatjuk a folyamatokat és az első csoportokat…

4. Megközelítés Annak ellenére, hogy kialakítotunk egy többé-kevésbé átlátható méretű alkalmazásarchitektúrát, a feladat mérete még nem változot jelentősen. Annyit értünk el, hogy néhány feladat megoldását magasabb szintre toltuk fel, amitől azok talán egyszerűbben kezelhetőek, és talán több segítő kéz fér hozzá. A másik előny az, hogy lehetséges a lépésről lépésre haladás. A rendszer minden pillanatban tesztelhető állapotban van, és talán kevesebbszer kell a fejlesztés során néhány hónapnyi munkát kidobni így. Amikor a rendszer elér arra a szintre, hogy az egyszerűbb folyamatokkal rendelkező csoportok döntéseit kezelni tudja, még a követelmények nagy része nem fog teljesülni. Különösen a biztonsággal kapcsolatos követelmények alkotnak nehéz diót. Ennek ellenére fontos az, hogy minél hamarabb minél élesebb feladatokra lehessen használni, hogy a gyermekbetegségek kijöjjenek. Persze ésszel, és felkészülve arra hogy eleinte nem lesz kizárható az adateresztés és a manipuláció. Az sem utolsó szempont, hogy amikor úgy érezzük hogy már megéret az éles használatra, akkor lehessen mutatni egy elégedet felhasználói csoportot, akik már két éve használják. Persze amíg a rendszer még csak félig funkcionális lerakatként működik, addig sem érdemes elhanyagolni azokat a tevékenységeket, amelyek a folyamatok kialakításával kísérleteznek. Folyamatámogató rendszerek ma is vannak, ilyen pl a Request Tracker. Ha azokat később ki is dobjuk, a tapasztalat felhasználható, esetleg a migráció is megoldható.

5. Hol tartunk ma? 5.1. A repository A repository jelenleg gyengén funkcionális: egy egyszerű felhasználói interfésszel lehetséges ontológiákat definiálni benne. A projekt a htps://github.com/magwas/worldmodel címen található, a kanban táblája pedig a htp://huboard.com/magwas/worldmodel/board címen. A hibajegyek közül zölddel vannak a könnyen megoldhatóak jelölve, hogy a belépési küszöböt csökkentsük. Szintén többek közöt ennek érdekében a szerver oldal java, a kliens javascript nyelven van írva, maven, hibernate és dojo használatával.

9


5.2. Önkormányzati projekt Van egy egyelőre névtelen projectünk, amelyben egy önkormányzat folyamatámogatását szeretnénk informatikai eszközökkel támogatni. Azt hiszem nem kell bizonygatni, hogy a helyi önkormányzatok nagy része erősen rászorul némi támogatásra a folyamataik tekintetében. Éppen egyeztetünk egy helyi önkormányzatal, ahol a polgármester nagyon lelkes, de még erősen kérdéses, hogy a képviselő-testület és a hivatal bugyraiban hol akad el a projekt. Ha ez nem jön össze, akkor keresünk másikat. Az ország több ezer önkormányzata közül talán lesz legalább egy, amelyik szívesen veszi hogy ingyen javítjuk a hatékonyságát. A projekt fő célja az önkormányzati folyamatámogatás, de természetesen a polgár-önkormányzat interfész fejlesztését annyira komolyan fogjuk venni, amennyire az adot környezetben lehetséges. A projekt a Request Trackerre épül, mivel abban van nagyon erős tapasztalat.

6. Kérdések Talán szokatlan módon szeretném én kezdeni az előadáshoz kapcsolódó kérdések sorát. Ezek a következőek: • Milyen szempontokat kell még figyelembe venni? • Hogyan lehet beindítani ezt a projectet? ◦ Ki az, aki beszállna a fejlesztésbe addig is, amíg az még csak egy lerakatról szól? ◦ Melyek azok a témák, szervezetek, stb. Amelyeket segíteni tud egy ilyen rendszer, amelyek tudnák a rendszert pilot felhasználóként segíteni? Én pl. szeretném már most a következő alkotmány szövegét megalkotni rajta, de ez sem technológiailag, sem politikailag nem kivitelezhető egyelőre. • Melyek azok a létező komponensek, amelyeket fel lehetne használni? Minden hozzászólást szívesen várok a későbbiekben is. Elérhetőségeim: [email protected] +36 388308791

10

RÉSZVÉTELI DEMOKRATIKUS ARCHITEKTÚRA

Recommend Documents