[PPNL-Techteam] Weet jij nog projectmanagement-software? Re: Bettermeans -- Advies

[Bèr Kessels]

Hoi,

Als jullie accoord gaan, onderzoek ik wat opties die als alternatief
kunnen dienen voor taken-management Bettermeans.

Wat ik IIG op mijn lijstje heb staan:

http://www.fengoffice.com/web/index.php?lang=en
http://teambox.com/ https://github.com/teambox/teambox
https://github.com/dim/retrospectiva
https://www.chiliproject.org/

Heb jij nog ervaring met Open Source projectmanagement-software?

*Het doel is een pakket vinden waar we taken in kunnen beheren.*

Als het extra features bevat, kan het mogelijk ook andere zaken
overnemen. Denk aan werkgroepen, chat, agenda, etcetera. Dat is echter
niet het primaire doel!

Ik wil het vergelijken op de volgende punten:

* Hoe stabiel en maintained is het?
* Kunnen wij het inzetten en klaarhebben voor de ALV?
* Hoe onderhoudsvriendelijk is het?
* Hoe gebruiksvriendelijk is het?
* Heeft het ticketing, features, met tickets die onder projecten en/of
werkgroepen geplaatst en beheerd kunnen worden (groepering).

Alle andere is mooi meegenomen, maar neem ik niet mee in het overzicht.

Bèr

On 08-09-12 17:07, Bèr Kessels wrote:
> Hallo,
> 
> Ik heb de afgelopen dagen wat verder in Bettermeans gegraven. Hierbij
> mijn advies voor de PP.
> 
> # Organisatorisch
> Bettermeans is niet af of stabiel.[1]
> Bettermeans is geschreven in Ruby on Rails.
> Bettermeans is gereleased als pakket, maar feitelijk is gewoon de
> codebase van een SAAS online gedumpt. Er is nauwelijks doorontwikkeling
> en de code is vergeven van business-specifieke onderdelen:
> facturatiediensten die hard ingebouwd zijn, monitoringsoftware die
> vereist is enzovoort.
> 
> Bettermeans past qua opzet, features en workflow perfect bij een
> organisatie als de Piratenpartij.
> Bettermeans is OpenSource en bied ons de mogelijkheid zelf aan door te
> ontwikkelen.
> 
> Omdat het niet stabiel is, is doorontwikkeling door onszelf vereist.
> Maar is het moeilijk te zeggen wanneer het productieklaar is. Bovendien
> moeten enkele business-specifieke zaken weggehaald worden, voordat het
> in productie gebracht kan worden. Deze zaken worden in de issuequeue
> bijgehouden[2].
> 
> Omdat het in Ruby on Rails is geschreven is het moeilijker hiervoor
> vrijwilligers te vinden; vrijwilligers met genoeg Ruby on
> Rails-ontwikkelkennis om dit pakket te kunnen doorontwikkelen en
> onderhouden. Moeilijker dan bijvoorbeeld PHP-ontwikkelaars.
> Zover bekend, ben ik momenteel de enige met kennis hieromtrent bij het
> techteam[3].
> 
> Mijns inziens is het erg slecht als een belangrijk onderdeel van de
> communicatie draait op een systeem waar slechts één vrijwilliger kennis
> van heeft. Valt die weg, dan is de kans groot dat een belangrijk
> onderdeel voor het functioneren van de PP wegvalt.
> 
> # Technisch
> Het pakket bevat nogal wat aannames die voor de SAAS heel goed zijn,
> maar voor ons niet. Zo zitten er allerhande creditcard- en
> betaalfaciliteiten in de weg, worden externe diensten gebruikt om te
> monitoren, gebruikers te beheren enzovoort.
> 
> Dat zal allemaal moeten worden verwijderd in onze fork vooraleer we het
> in productie kunnen brengen.
> 
> Het pakket lijkt in eerste oogopslag veilig, maar zover mij bekend,
> heeft het geen grondige security-review gehad. Iets wat ik adviseer om
> zeker te doen vooraleer we het in productie brengen en er cruciale
> informatie in gaan beheren.
> 
> Het pakket is vrijwel geheel gecovered in tests.
> Het pakket is netjes volgens Rails conventies opgezet.
> Het pakket kan zeer goed schalen door goed gebruik van caching,
> database-replicaties en delayed-jobs (asynchrone processing).
> 
> # Conclusie en advies.
> 
> 1. We moeten er nog veel energie in steken vooraleer het in productie
> kan. Dat is niet haalbaar voor de ALV.
> 
> 2. Voor de ALV kan er wel een demo staan waar mensen in kunnen
> rondkijken; dit kost echter veel inzet, waardoor zo een Demo enkel
> opgezet moet worden als we ons committen het ook te gaan inzetten.
> 
> 3. Doorontwikkeling en onderhoud is vereist en vergt Ruby on
> Rails-kennis, waardoor in de praktijk de ene Rails developer (Ikzelf) de
> bottleneck zal worden. Aantrekken van Rails-kennende vrijwilligers is
> mijns inziens een vereiste als we Bettermeans als belangrijk gereedschap
> gaan inzetten.
> 
> 4. Onderzoek naar alternatieven is mijns inziens een betere optie.
> Alternatieven zullen qua features en workflow minder goed passen, maar
> qua onderhoud en technische inzetbaarheid wel beter passen.
> 
> 5. Eventueel kan besloten worden een alternatief tijdelijk in te zetten
> en onderwijl aan Bettermeans door te werken.
> 
> 6. Bettermeans zou in elk geval zodanig klaargemaakt kunnen worden dat
> het ook door andere piratenpartijen gebruikt kan worden. Eventueel als
> SAAS, eventueel als installeerbaar pakket. In ieder geval zou het dan
> gedragen en beheerd kunnen worden de PP-internationaal. Vergelijkbaar
> met LQFB. Dat zou de benodigde investering aan doorontwikkeling beter
> verantwoorden.
> 
> Bèr
> 
> 
> [1] Merk op dat ik hierin vrij conservatief en streng ben. Ik zie de
> LQFB bijvoorbeeld ook als niet stabiel en vrijwel vergelijkbaar qua
> status als Bettermeans.
> [2] https://github.com/piratenpartij/bettermeans/issues
> [3] Ik heb, na deze evaluatie besloten dat Bettermeans in huidige staat
> niet in mijn portfolio zal komen; ik zal er dus niet professioneel mee
> aan de slag gaan voor mijn klanten. Daarom zal ik er enkel in mijn
> Piratenpartij-tijd aan kunnen werken. Deze tijd is beperkt en heeft
> bovendien een lager prioriteit dan mijn betaalde projecten en klanten.
> Ik zie mijzelf dus ook in de praktijk als bottleneck als een project
> geheel van mij alleen afhankelijk is.
> 


-- 
  http://berk.es

  Open Source Webdevelopment.
  Ruby on Rails development.
  Drupal Development and -consultancy.