This document is a transcript from https://hack.allmende.io/s/ecobytes-transformap-20170613-tender
Answering the TransforMap Invitation for Tenders.
Ecobytes, June 2017
We are collectively approaching these tasks and support each other mutually with design and implementation. There is one maintainer per User Story and Task. This is embedded in development community trainings, which aim at extensive skill sharing between the participating peers.
We stem our experience from building:
- transformap.co Testbed
- allmende.io Infrastructure
SSEDAS is a european research project which produces SUSY (SUstainability and Solidarity economY). It has embarked a joint venture with Get Active e.V. (Austria) to build mapping components for the TransforMap ecosystem, which are generally usable to present the SUSY Map.
This collaboration has been awarded a budget extension, which led to an invitation of tenders.
To answers this invitation, ecobytes e.V. is pooling responses and combining them into a collective proposal, which is described in detail below.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License by ecobytes e.V., June 2017.
In the following, we present conceptual notes about development and implementation vectors to persue. They stem from the User Stories and Tasks from the Invitation of tenders, where appropriate.
The group follows a multi-shell communication design, from a calmer, private inside to more publicly exposed and faster outsides. The shells are:
- Taiga ~ weekly sitins and quick reviews
- TransforMap Discourse ~ bi-weekly letters to the public
- Allmende Riot ~ ad hoc everyday
Additional participation in social coding platforms is implicit.
This proposal seen as a pattern language.
EUR 2.000,00 #410 - User login
@mrothauer deploy and extend web services and their interfaces with federated identity and access control.
This involves the deployment of hydra or a similarily simple solution into the TransforMap Testbed at Ecobytes.
This intends to implement the Implicit Grant flow at the editor.
This intends to implement the verification of HTTP bearer tokens against an authorization server during write access to data.transformap.co.
EUR 2.000,00 #407 - History queries and restore function
@yala expose the prepared revisioning system in machine- and human-readable form.
This task is about adding additional endpoints to the data service for retrieving or aggregating views on the underlying database.
/places/UUID/revisonUUIDendpoint to retrieve arbitrary versions
- Implement changes feeds per endpoint and per user
EUR 1.000,00 #419 - Building an interface for restoring versions
In this task we add user interface components to expose the revision history of POIs to the Editor user, to allow her to revert previous ones if needed. Additionally we present user activity on a dashboard.
- list revisions for a POI in a specific view
- save a new version from an old version (restore), includes restored revision UUID
- welcome page to the editor, showing recent site activity as well as create and edit history of a logged in user
EUR 2.000,00 #424 - Ability to add media to POIs
@yala implement an HTTP BLOB store following the FAIR Guiding Principles for (meta)data management by implementing Standards-compliant discovery mechanisms.
EUR 750,00 #427 - Integration with editor
contributor of a Task
Additionally to the vertical integration of multiple tasks into user stories, a horizontal perspective connects peers that work on the same end product. These could be tags to the Tasks in Taiga once implementations start getting documented there.
T415, T419, T427
T425, T415, T416, T428
About budgeting and estimation
The actual budget distribution will be reassessed collectively by the whole group after individual deliveries. When laying out needs and costs for development activities, we follow an agile procurement approach.
This model requires acceptance of some budget uncertainty: the total cost of delivery of software may not be fully known in advance.
However, one can, alternatively, fix a budget and accept some uncertainty over features delivered.
We emphasize that this limitation is not a limitation of open source but of software in general. As the maxim goes: in software development you can have any two of features, time and budget – but not all three.
Traditional tendering with its fixed requirements, fixed timeframes – and implicitly fixed costs – exists in an illusory world where one can have all three and implicitly imagines that buying software is like buying traditional goods like chairs whose features, usage and cost are all well-known up front.