2016-06-09 - Foodsharing.de and MVP

dreaming, planning

Present: Janina Abels, Bodhi Neiser, fritz holscher, Tilmann, Tais Real, Paul Free, Philip Engelbutzeder, Matthias Larisch, Nick Sellen
Notary: Tais Real
Location: Heichelheim

Topics (unplanned)

1. Defining the partnership we want with foodsharing.de
2. Proposal of beta MVP

Outcomes

1- clearer situation on where we stand with foodsharing.de -what we can offer them and what we would still do without their direct support

2- developers agree on much smaller MVP

2- run plan of smaller MVP by coreteam channel through Tilmann's short written presentation

Open questions

1,2- what do we tell international people? Wait for software?

1,2- do we want early beta MVP for communities to try it out or for devs to play around with the code more easily?

[Meeting begins: 11:30]

• get a list of Orgateam members with contact info 

Get in touch

Suggestion: send email with goals and actions we take, while asking if we can use name & logo. FH: should involve them before approaching them on legal questions.

Or physical meeting in Heichelheim, 24^th July; only few actually join and then the others don't agree with decisions made. Still is an opportunity to give short 20min presentation (because very tight schedule) of yunity's internationalization plan. It gives us time to figure out what we actually want to do. 

What for?

Do we really need their approval? We can reach much more 24 people...

→ It's the only real thing that yunity has so far. It would be nice to have their approval. But we shouldn't run after them to approve of us, but let them approve of us with our actions.

• Cooperations for emails from foodsaving initiatives - NO- Raphael has already granted access to that. 200 or 300 emails (JA)
• Logo and success story - they have no license so technically anyone gets limited access to their stuff.
• Help with finalizing Restructured German Wiki - which is actually only meant for foodsharing.de, as JA is creating a new, more flexible one for international audience. Problem: administration on Mediawiki is too complicated: only administrators can edit and no subgrouping possible. If we had our own Confluence server it would be fine, even though there is skepticism about a completely open wiki.
  Maybe Orgateam doesn't disagree so much on content of new wiki but on the platform?

And now?

BN: If we have a version of RGW working, then we can present it to Orgateam and have a syscon about it. JA: that's done, but I need more foodsharing people to look at it. First draft Kristijan and other Orgateam members were critical about mistakes. BN: badly communicated because it wasn't ready yet to be shown.

• Janina is waiting for Kristjan's help, will also ask the help of André and Alena
• have RGW proofread by one yuniteer before 24th of July

At the presentation we can also kindly ask for proofreading. If no one from the Orgateam is on board, we let it go. If they are, they then make syscon to adopt new RGW. In either case we will have shown our willingness to help them!

2. yunity- a tool for foodsharing.de or for worldwide foodsaving initiatives?

TR: unclarity about MVP and primary goal: do we want a better platform for foodsharing.de or do we want to create platform from scratch for foodsharing communities who have asked us or foodsharing for help?

TB: For a long time I've had in mind a platform as simple as possible for worldwide users. We go for the new groups and ask them if that's enough for them already. It's much more simple to get it going for them than for Germans who already have something (general approval)

BN: and then we wouldn't need all the layers of foodsharing organisation. We'd get big resistance from Orgateam because it would change a lot of the structure of foodsharing. Personally I think the platform should just be a tool for local communities without all big administrative mess.

ML: features that are being implemented right now fit to what TB described

FH: run it on foodsaving.org instead of yunity.org

TR: this changes the specification process: by asking the international users what they need, we implement features that they define as helpful and desirable (ML+). We find some starting communities who are struggling with organization, want our help and who are ready to try out our software as soon as our features get interesting enough for them to use, even though software would sometimes break.

ML: then we need to keep compatibility. It makes it more complicated but it's more interesting and then we have users.

JA: How long would this take if we get down to work?

ML: i don't know but I could say 2 or 3 months

BN: we have enough crisps to lock Matthias in a room for 3 weeks

TB: for this plan we would need much less development work. Raphael and Martin have a goal too complicated for 2 developers. And now they want to hire developers.

JA: do Raphael and Martin know about this idea? They should be on board!

PE: i like this idea. Wechange guys were doing exactly this - open source (BN: sure?)

TB: i created a yunity profile in wechange some months ago but discovered they have no features we really could use. It works but it's simpler that anything we use. For us not appropriate but for people who start new project it can be.

JA: how many users could this handle? Big discussion atm between Raphael and Pranav etc. 

MT: we don't need to focus on something that can power millions of users

JA: is it possible to rescale when it grows?

FH: it's always a build-up! We will restructure when it is needed.

TR: if we decide to go down that road, we would need to redefine how we integrate developers. Perhaps stop being so eager for more to join because we would need less?

TB: for developers right now we don't have any structure. We don't release the stuff that we do, and we don't test it. We have the front end already. We could release it right now and just fix it... It is so much less than we wanted to do but it makes sense now.

TR: what could be the down side of releasing it now?

FH: people see it and get bad opinion on it

TB: we just put a Beta sticker on it!

NS: I distinguish 3 opinions

1. new idea, minimal thing that international people can start using

2. existing specification - are they appropriate to that new idea?

3. how to get developers' productivity. 10 or 100 developers around the world isn't enough. We need very motivated developer, maybe just one, passionate about this code. Example i saw of a project, three types of developers: ones that fix bugs, ones that create features, and core developers for at least 6 months.

TR: but if we go for a very basic, very adaptive beta MVP, the last problem becomes less relevant. We go from very difficult mission with bad developers situation to manageable challenge with bad developers situation.

TB: design wouldn't really work for this kind of platform build-up because they go to specification team to know what to do.

Two options: front-end people could do design themselves or could get more direct contact with designers.

NS: Not sure front-end developers and designers really exist.

BN: idea: we could create a beta version powered by Confluence, create a space for each new country. There are some tools already in place. But no maps.

NS: basis for our Confluence partnership is that they support open source software, but if Confluence becomes our software...

TR: suggest syscon to confirm that we want a beta version to be constantly improved rather than a lot more work for perfected version for foodsharing.de - JA. not directly syscon but post in #coreteam and ask if there is any resistance.

For this TB writes up short presentation of this plan (preferably collaboratively)

[Meeting begins: 13:40]