-
Notifications
You must be signed in to change notification settings - Fork 0
Danovy poznámky z VH
BIS by měl být open-source z několika důvodů:
- Software generovaný na bázi dobrovolnické práce a nebo z neziskových účelů principiálně “chce být” open-sourcovaný (MIT vs. GPL vs. BSD)
- Je zde vidina, že jiná neziskovka bude chtít systém používat a rozvíjet
- Systém bude postavený na celé řadě open-source knihoven a technologií, je slušné vrátit něco zpět
- Je snazší zasvětit další vývojáře do vývoje, který je od počátku otevřený
- Programovat open-source produkt je prestižnější než pracovat na něčem, co odborná veřejnost neuvidí
BIS by neměl být otevřený jen kódem, ale i prostředím, když se někdo odváží pomáhat s vývojem, měl by pocítit, že jsme rádi, že to dělá (pokud jsou jeho úmysly dobré) a měli bychom ho podpořit. Ideální by bylo, kdyby část práce nedělali developeři.
Je nezbytné, aby systém v budoucnu nestál na jednom člověku. Je třeba tým nebo alespoň příprava na tým (např. dokumentace, modularita, sandboxing). Zároveň musí být dobře nastavené procesy, aby byla týmová práce efektivní - tady pomůže github.com a jím prosazované workflow.
Požadavky na BIS by měli být přijímány způsobem, který je standartní u open-source produktů => na issue tracking systém (integrovaný s githubem) - je možné použít např. Mozek, ale zbytečně bychom uzavřeli pozadí vývoje ostatním developerům např. z jiných neziskovek a přidávali si práci. Issues jsou navíc osvědčené, spojené s kódem, s možností diskuze a bez práce s jejich administrací. (samo, když někdo bude mít extra odpor může poslat mail a my to tam vkopírujem, ale on přijde o možnost diskuze…)
Základní fíčury a cíle systémů musí být jasné a dané od začátku, další požadavky na nové fíčury musí být řazeny do fronty a pečlivě tříděny dle priorit.
Bugy musí být přijímány přednostně a opravovány předtím, než se budou rozšiřovat nové funkce.
Každý požadavek nemusí být ku prospěchu, je třeba opravdu řešit co je teď důležité v systémů mít… “Např. já bych chtěl v BIS kalendář akcí! A nestačí export na web, na google calendar, v .ical a v blabla?”
Systém by neměl podporovat všechny procesy, které si uživatelé vymyslí, jen by jim neměl házet klacky pod nohy a bránit jim bezdůvodně. // Některé věci by naopak asi měl vynucovat - např. věci vyžadované interními předpisy, dotačními programy atd...
BIS musí mít od začátku vyřešené, zdokumentované a otestované zálohování vestavěné přímo do systému. Vždy musí být jasné, že jsou data v bezpečí (která data a kde jsou).
Pokud bude systém využívaný k analýzám (marketing, různé diplomky…) bylo by možná dobré vytvořit anonymizační vrstvu… která by umožnila dělat validní analýzu, ale zajistila by ochranu os. údajů např. změnou jmen, zaokrouhlením dne narození, skrytím emailu atd. Tak by bylo možné dát část dat z ruky… (??)
Uživatelé, kteří vidí (a mohou exportovat) více než jeden ZČ, by měli povinně pro přihlašování používat nějakou dvoufaktorovou metodu.
Všichni by měli přistupovat k BISu přes HTTPS.
BIS2 by mohl sloužit jako centrální autorita pro přihlašování do ostatních systémů HB, např. Mozek, web, budky, ten systém pro ZZ + ZV...
Technologie bychom měli volit podle:
- vhodnosti => vhodné :D
- licence => open-source nebo jasná licence s předem danou cenou
- běžnosti => více programátorů danou technologií, znamená více potencionálních spolupracovníků
Mě se zdá nejlepší dneska:
- PHP pro API
- MySQL nebo PostgreSQL pro databázi
- HTML, JavaScript pro samotnou webovou aplikaci
- Linux, Nginx pro server.
To je všechno open-source a velmi běžné. Podle hlaviček to vypadá že stávající BIS běží na Linuxu a PHP taky (byť stará verze).
- Popsat stávající funkcionalitu BIS
- Popsat požadovanou funkcionalitu
- Popsat proč se vlastně BIS má měnit - co je špatně
- Začít sbírat další požadavky na fíčury - ideálně od nějakých zkušených uživatelů, spíše než plošně
- Sepsat jak je na tom současný systém:
- kdo má kód, kdo má hesla
- kde běží
- kde jsou zálohy
- jaké technologie používá…
Na základě tohodle, vybrat a zafixovat:
- První sadu fíčur
- Technologie a přístup
- Roadmap do verze 2.0
- Způsob testování a postupného nasazování
- Zvolit licenci
A začít!