Continuing the discussion from Paper Writing for Critical Geographies of the sharing economy at RGS Conf:
#Methodology to collect requirements
@almereyda Ideas on how to structure the requirements in some kind of harmonized way? I suggest that we start writing with the best of our knoweldge and then a structure may emerge. A table will quickly be necessary to get an overview of requirements.
- any documented conversation, report, protocol…
- complete with direct requests
Do we write on Discourse? I would say yes, so others can participate.
(either expressed clear will to join or just inevitable)
“For us the mapping is a very important tool not just to have an idea of who exists and where they are but also what they do and how they do it [as actors of the solidarity economy are very diverse] and how they relate to each other.
So that’s a bit different from the approach on needs. But I think it can work well to put the two together. Exchanging the information, organizing it in layers.” Source, interview with Jason Nardi in May 2015.
OSM cannot be used to store all sort of data. Already received a warning in the context of discussing import of sharingberlin.de
- Data from their map is licensed under CC BY SA 3.0. Would ilike to see data in other places including OSM.
- Developing a widget for collecting initiatives’ data.
- Want embeddable Transformap on website with default layer showing only “Transition Initiatives & - Projects”, but might be interested in having other layers of data hidden behind a click.
- Updating: Maintaining data up to date is a challenge. Looking for solutions to improve the process.
- who is that actually? This is a very loose community, difficult to assemble set of requirements.
- Generally, can be expected that it would have to respect general commoning principles.
Limited info on their long-term wishes. Currently they want to display a map of 60 initiatives of the Solidarity Economy in Berlin on OSM.
interested in working together on the taxonomy for classifying the initiatives
###Imagination.social / encommuns
- Cooperation: willing to integrate their work with TransforMap. Similar actor: committed to building a thematic data commons about initiatives and projects, including the required FOSS.
- Data server in Danjgo/Python, interfaces in Angular. Will to move towards linked data.
- Multiples front-end implementations with subsets of data.
- Licenses are a mix of ODbL and CC BY SA (thinking of switching to ODbL).
- Strong interest in building decentralized systems instead of one big database.
- Vocabularies: use tags. Can accommodate taxonomies specific to one project.
(potential participants who haven’t clearly expressed interest to join)
###PEC (French CSA)
- Interest in having a new membership database that allows publishing data on pages and maps with various levels of confidentiality (e.g. data only visible by members, data visible by publi).
- Updates: Looking for a solution to avoid updating data of CSA initiatives in two places (or more).
- Priority is low-cost, high usability.
- Use imagination.social server (http://data.patapouf.org/api/v0/). Produce various maps for specific regions around specifc themes (e.g. collaborative consumption).
- Vocabularies: need to be able to display its own set of categories.
- License: declared CC BY SA but likely ODbL as it’s using data.patapouf.org. Wish for maximum reuse.
- low to no budget
- very low technical capacities to some hacking capabilities
- wish for having categories to sort initiatives
- wish for crowdsourcing
- wish for open licenses but no clue
I’m very much opposed to the term stakeholder. The WSIS in Tunesia showed us, how multi-stakeholder approaches don’t really help in organized networks. They cannot reflect their dynamics.
changed the language.
Otherwise, any thought? Are you in? we could also have working/sprint sessions sitting together to complete the info that we have.
This is solvable by focusing on the user stories, which normally do not have a mention of the technology to be used. The definition of the technology happens within the stories themselves, usually based on a team work on understanding the different technological options and deciding for one.
This does not mean that we shouldn’t have user stories for deciding on common and important aspects of the underlying framework. These can be the so-called team requirements and consist usually of non-functional requirements (read more on it here)
My proposal is that we start listing these community requirements, (which emphasize collective requirements of specific groups of people, rather than individual interests of a few people that should be allowed to say something about the topic - the stakeholder) in taiga.io cards. taiga has the advantage - in comparison to Trello - of being specifically designed for agile project development and is free software. It also allows for defining whether the stories are a client or a team requirement (the case for the non-functional requirements).
Please note that use cases and user stories are different things: whereas user stories aim at creating an improvement or a new feature, an increased value for the end-user, use cases are just ways in which people (can or do) use the system. In this sense, use cases can be an excellent source of information for building up user stories.
So, to sum it up, I propose to:
put the collected requirements into user stories on taiga, e.g.
As a coordinator of ESS global, I want to be able to visualize interactions between different actors of the solidarity economy, so that I know how they relate to each other
schedule a (proper) sprint planning meeting with all the team (and when possible some of the people from the communities) to prioritize user stories, collectively plan and detail the tasks (and technology) involved in it, define acceptance criteria and estimate the effort
allocate funding and people (paid and volunteers) and get the things done
thanks @gandhiano for the input!
that may necessitate that some of us do the work of inputing this in Taiga not asking to all from communities to do it and get to know yet another tool (I will though).
[quote=“gandhiano, post:5, topic:536”]
2. schedule a (proper) sprint planning meeting with all the team (and when possible some of the people from the communities) to prioritize user stories, collectively plan and detail the tasks (and technology) involved in it, define acceptance criteria and estimate the effort
[quote=“gandhiano, post:5, topic:536”]
3. allocate funding and people (paid and volunteers) and get the things done
if there is consent from the monkeys here we need to make sure that various plans made by the monkeys are aligned: wink to @almereyda @species
Can I get an invite to Taiga?
You have it now. I have also setup the roles to reflect our zoo structure
The project is public, meaning anyone is able to see it. If others want to join and look around, you can ask any of us to add (we need the e-mail).
I have also setup a role for communities (renamed from stakeholder): if we stay with taiga (which is very nice, has been having quite a lot of development and we can also contribute with own features), then it might make sense to have them contribute issues (and or use cases/stories). The interface for that is extremely simple and we can certainly build the already discussed (for Trello) mail gateway to allow submission of issues over e-mail, if we find it important.
But in general communities don’t have to be involved there. However the people developing the project (technically and non-technically) ideally should.
I propose we try it around until Berlin (with the building up of user stories) and then decide on further steps around its use.
that I’m not sure it’s actually required. I would rather get the small number of people required on board and then make groups if needed…