Законопроектите като git pull request

Вчера министър Божанов обяви законопроектът за промяна на Закона за движение по пътищата и описа нещата, които спадат в сферата на електронното управление. Целият текст на проекта ще намерите на страницата на МВР заедно с мотивите и оценката за въздействие.

Исках да разбера в какво се изразяват промените и да разделя тези, които идват от електронното управление и са за облекчаване от бюрокрацията както и за автоматизация, и тези идващи от МВР. Законопроектът има доста точки, а и самият закон не е лесен за четене с всички препратки, отменени текстове и прочие.

Затова седнах и въведох публикуваната от институциите последна версия на Закона за движение по пътищата в Github, след това от основната версия направих branch и добавих промените предвидени в проекта. Това е нещо основно, което се използва за разработването на софтуер и позволява да се правят паралелни промени, да се следят множество версии на един и същи документ и накрая да се решава какво следва да се слее в основната версия.

Пътят на един български законопроект всъщност далеч не е по-различен чисто административно, просто е до оглупяване муден, ръчен, непрозрачен, пълен с грешки и възможности за манипулация. Причините за това са както традиция и закостенялост, така и фрапираща липса на компютърна грамотност в администрацията, но най-вече сред законотворците и взимащите решения за процесите в НС, които ние избираме.

Това, което направих в Github не е решение само по себе си, но е пример как може да бъде с минимални усилия. Учудващо бързо успях да дигитализирам толкова сух закон и да прехвърля законопроекта. Така може да се види нагледно направо в закона какво се променя. Тук, например, виждате промяната на Божанов премахваща изискването за талон и стикер.

Чисто технически, система като Git може да се използва за тази цел, но има проблеми, които трябва да се решат. Като процес вече споменах, че съвпада в огромна степен до този вече използван в повечето софтуерни компании. Може би като изключим нападките от подиума на пленарна зала по адрес на нечия сестра или сексуална принадлежност… може би.

Markup езикът на github конкретно е подходящ, но не пасва изцяло на практиката за форматиране на законите ни. Списъците там не поддържат буквите в номерата на точките и подточките на алинеите ни, а не може да слагаме 7 нива на подзаглавия. Отделно адресирането на препратките следва да става по йерархичен ред, за да не се чупи при промени в закона. Сега при еднакви имена на алинеите, линковете към тях в github md са по пореден ред на заглавието с еднакъв текст. Има начин да се заобиколи, но не е удобно. За целта следва да се направи вариант с тези добавки, включително автоматично адресиране директно до точка и подточка в редакторите. Това ще позволи по-бързо въвеждане и по-малко грешки.

Трудни ще бъдат първите стъпки, защото говорим за огромно количество нормативни актове, трупани с промени десетилетия. Докато дори толкова сложен закон ми отне 30-тина минути да прехвърля без да имам опит, всъщност много следва да се внимава, когато това се прави за официален източник, защото тогава ефектите ще са значителни.

По-важен проблем обаче е сигурността. Докато тази информация следва да е публична, трябва да сме сигурни, че няма да се променя. Колкото и да е станало клише вече, именно blockchain технологията е подходяща тук – публикуването на хеша след всяка промяна ще даде възможност на всеки да провери, че дори една буква не е била подменена в цялата дигитална нормативна база или история на България.

Всичко това не е самоцелно, за използване на overhype-нати техно термини в нещо закостеняло или да се модернизира работата на една от основните институции в страната ни. Прозрачността тук е сериозно засегната. Независимо, че законопроектите се публикуват отдавна, те остават недостъпни за голяма част от населението. Дори за активно търсещите и интересуващите се е нужно часове, а понякога дни заедно с консултации с адвокати да разберат какво се случва. Често промени нарочно се описват в законопроектите по начин, които прави разкодирането им изключително трудно. Всичко това цели единствено и само да се укрие истинската цел на авторите.

Друг важен аспект тук е, че България като държава всъщност не притежава законите си. Не съществува в нито една институция, включително в Народното събрание, едно място, на което да се пазят законите. Ако днес някой попита какво казва даден член на даден закон, няма институция, която може да ви до каже. Да, всеки нов закон и стотиците промени по тях се публикуват надлежно в Държавен вестник и това се пази от НС чинно. Но крайната версия на законите – не. Тази функция държавата без решение, закон или заповед е изнесла като отговорност на няколко частни компании, на които те, както и всички български компании плащат ежемесечно за правото да знаят покрай много други неща и какви са българските закони. Дори администрацията на Народното събрание когато подготвя промени, всъщност не ги прилага в някакво тяхно копие, които пазят тайно от нас, а сверява с последното от съответната частна софтуерна система.

Има публични безплатни източници, разбира се, но информацията там е собственост на въпросните компании. От гледна точка на прозрачност и сигурност на толкова критична за държавата ни информация като текстовете на съвкупността от нормативните ни актове, това е най-малкото стряскащо.

В никакъв случай не казвам, че е лошо фирмите да предлагат такива услуги. Не следва обаче държавата и особено първоизточникът на законите да разчитат на тях, за да достигат до крайния резултат от законодателния процес. Това, което показах горе не е непременно решение, а показва, че такова далеч не е трудно и не изисква особено сложни технологии или време.

Не на последно място, допълнителна полза от подобна система е, че лесно може да се правят предложения и да се осмислят далеч по-бързо. Ето, тук съм показал моите предложения към законопроекта, с който започнахме. Включил съм аргументи за предложенията ми и тук може да се видят конкретните промени. Пратих ги отделно по мейл. Ако имате и вие предложения или обратна връзка, консултациите текат до 13-ти май.

Това тук е един закон дигитализиран за половин час от един човек. С аналогична на описаната от мен, но по-стройна и сигурна система може да се проследява от всеки кой кога какво е променял, от къде е започнал, какво е прието, как е било изменено, слято или омаскарено. Цинизмът у нас ни дава още доводи, защо няма да се случи скоро. Иначе, ако искате да разберете как се приемат тези закони и най-вече какви машинации се правят, за да не се свърши никаква работа, ви съветвам да обърнете внимание на Стража.

6 коментара

  1. Тъй като търся информация за Безследно изчезнали в България, попаднах на сайт от 2014, който обаче е спрян и след това видях съобщението в този блог защо.

    Има ли някакво развитие по сайта?

  2. +1 от мен за идея в правилната посока.
    Трябва да се мисли по-скоро за данни, които да могат да се обработват машинно, а не само за текст, който ще бъде разпечатан/запазен и (може би) прочитан след това.
    Уикимедия ЦМС-а също може да се използва в случая с история на промените и техният маркъп. Предимство би било, че покрай Уикипедия и другите уикипроекти се употребява по-широко от непрограмисти. Уикитата са поначало с акцент върху данните. Евентуален недостатък при уикитата – системата им за дискусии. Според мен нарочно е направена да бъде не съвсем приятелски настроена, за да се избегнат припряните дискусии.
    На гитхъб и гитлаб дискусиите, със техните кратки тагове и други екстри. Акцента върху криптографските хешове в гит-а, също е предимство. Според мен.

    Сещам се и за едно готово, компактно решение, което не е популярно като Гит или Уикимедия, но комбинира в себе си и двете. Проектът е Фосил и е от създателя напопулярната ЕсКюЛайт. https://fossil-scm.org

    Спирам се до тук, защото темата ми е доста присърце и може да се увлека повече от поносимото.

  3. @Йордан Вълчев – той имаше проект в същата връзка преди години.

    @Krokodil – абсолютно може да се направи много, включително да се барне markup-а, за да пасва на българската традиция на форматиране на законопроектите. Не мисля, че може да се вкарват машинно-четими елементи, защото списването на законите е строго определена процедура, която ще е достатъчно трудно на този етап да се дигирализира, за да се адаптира и към машинно-четими формати. Отделно, че трябва да се изкара някаква обща структура, а е пълен хаос през годините с твърде много странни въведения. Първата фаза трябва да е набиране на законите в структуриран формат, за да може да се открият проблемите и да се вкара някакъв ред и проследимост. След това ще се чисти.

  4. @Р.Н. – няма напредък. От време на време ми пишат журналисти и хора изгубили близки. Скриптовете и акаунтите продължават да вървят и да правят това, което правят вече 12 години. Напредък в МВР обаче няма, а без тях описах защо е проблемно да продължи проекта.

  5. @Боян Юруков

    Не съм сигурен че разбирам изразените резерви за въвеждането на машинно четими елементи.

    Според мен процедурите свързани с документирането на закони и други актове могат (и трябва) да бъдат променени в съответствие с достъпността на технологиите. Законова пречка за такава промяна не намирам, по-скоро намирам, че това е задължение на законотворците. Непреодолими технически пречки също не мога да намеря. Вярвам че обсъжданият пример с Git е стъпка именно в тази посока, а избистрянето на структурата си е направо необходимост за да се работи нататък.

    Редът ми на мисли е горе-долу следният:

    Продукта, който се получава в следствие на гореупоменатите процедури обичайно е волеизявление, което се съдържа в документ.

    Едно от основните предназначения на този документ би трябвало да е ефикасното (а не привидното) информиране на гражданите.

    Процедурите трябва да са съобразени с това. Организирането на работния процес по начин, който позволява да се постига по-добро информиране на гражданите на всички етапи, би следвало да е стандартно изискване.

    В настоящият момент, както и в обозримо бъдеще, информацията която е структурирана като универсални цифрови данни готови за многоцелева машинна обработка, би могла да бъде много по-полезна, в сравнение с информацията, която е предвидена просто да бъде разпечатана или показана на екран (което изглежда по настоящем да е правило, с някои редки изключения).

    В случай че за създаването на документите-първоизточници се ползва достъпен и стандартен формат за данни, примерно XML, възможностите за последващо полезно действие на този законотворчески/административен продукт нарастват значително. Това е относимо и към по-доброто оползотворяване на архивните документи.

    За конкретното реализиране на процедури, които да интегрират въвеждане на данни с XML или друго форматиране на информацията, има различни варианти според мен. Ефикасното представяне на тези варианти обаче не пасва на блог-коментар формата. В случай на интерес, може да се уговори и друг формат, както и подход за взаимодействие и работа с цел да се придвижат възможно най-ефикасно решенията на обсъжданите проблеми.

    Бих подкрепил доколкото имам възможност, решения, при които има добра воля за постигането на по-добро организиране на информацията, която е достъпна за гражданите с цел те да могат реално да взимат информирани решения, а не това което е в момента.

    В заключение, според мен първата фаза във връзка с обсъжданите от нас хай-тек проблеми, по-скоро е да се направи риалити шоу, в което участниците (че и публиката) да се хванат на работа по другите фази. То и в днешно време изглежда риалити формата е както първата, така и последната инстанция 🙂

Вашият коментар

Вашият имейл адрес няма да бъде публикуван.

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните ви за коментари.