Meeting #3 2015-10-02

Present: Doug W (Minutes), Raphael F (Mission and Vision), Raphael W (Development), Martin S (User Needs), Sara P (Design).

Apologies: none

RF: Presents 'Pages' mockup for shops, NGOs, businesses, etc. It would support comments, 'stars' + reviews, hearts (instead of 'likes'), photos, connections (e.g.. you → your mum → the store), etc.

MS: Discusses 'Events'. When looking for people to participate in events, there should be a feature to 'assess character' (i.e. reliability, etc.). Begins subject of user trust. In FoodSharing there currently exists the 'trust-banana' system, presents trust metrics mockup.

• RF: A 'vouch' (personal review) would be higher than a 'star' (simple feedback for food baskets.)

• MS: Although 'stars' seems harsh (i.e. a member could be 'two-star-quality'), previous FoodSharing experience suggests it is necessary (as people being unreliable has proved problematic). Presents a proposed 'trust algorithm' – which could include 'gives', 'receives', 'reliability', 'stars', etc. A combined value could be calculated.These measurements and calculations could be used to filter when searching (e.g.'my basket only available for members with a minimum of 80 % reliability')

• RF: Confirms that reliability has been a known issue for FoodSharing so far.

• SP: How would reliability be calculated?

• RF: Calculations of both giving and receiving... precisely how still being discussed.

• MS: Platform relies on trust and user metrics are important, hence the platform should provide appropriate prompts for feedback. Having 'connections' visible on profile can provide evidence the profile represents a real person. Have user metrics view-able on profile?

• RF: Thoughts about icon: should be humanistic. For example; 'sharing' could be two hands holding, 'receiving' could be a hand receiving a heart and 'giving' could be a hand releasing a heart. A clock could represent reliability. Presented the use of 'spider diagrams' to present different user metrics (such as reliability, gives, etc)

• RW: Spider diagrams and user metrics could make things 'game-y' and induceunwanted competition.

• MS: Suggested a neutral 'trust-o-meter' which always returns to neutral ('OK') with time. Prevents your mistakes from following you for the rest of your account history. Eases entry for new users.

RF: Personal wall could contain personal interactions like 'giving' or 'receiving', personal connections as well as comments and photos, etc.

• MS: Wall/profile would also show communities and groups that that person is a member of.

• RF: Wall could have preferences about what is displayed.

• MS: Personal feed on a wall – 'like-able' or not?
  [Discussion]

MS: Starts talking about communities and groups...

• SP: Has to regularly explain the difference to others – perhaps use clearer names?

• MS: Groups are any group of members, communities have 'food-sharing' rights and are more structured – perhaps connected to a page. Groups are looser and interest related people can form them as they like.

• RW: Doesn't want to make things so complicated for the user (in terms of pages, communities, groups, etc, etc). However, the differences aren't so hard technically.

• MS: Whatever the term, a 'groups' purpose should be immediately obvious.

• SP: Thinks it's complicated to have both. Perhaps better not to have any user create a community?

• RF: No, any user could create a group or community.

• RW: What about having no pages - only communities?

• RF: No, pages are for useful for stores, etc. Keep pages. But communities and groups?

• RW and RF: Perhaps a useful distinction would be just to keep. Just keep communities regional?

• MS: One page for Germany, with other pages for communities all over Germany linked on the master page.

• RW: Countries not defined in current development model, only areas.

RF: First blog post published. Email translators soon so they can get started translating. We should involve other developers – is development team ready for remote developers?

• RW: No problem to inform remote developers, but development team not yet ready to keep contact with, inform or /include them at this moment. Gather details for when we can incorporate them. Not easy to get involved right now, but we are working on documentation to include them.

• RF: Important to address the fact that a lot of work will be done on a distributed basis later on and we need to think about how we enable that now: make the project understandable. FoodSharing Newsletter going out soon. We need to be transparent about our finances – publish our expenditure online. We should have a project name decided by tomorrow – this will allow the progress of the legal processes (and Beatas colleague is willing to help!)

SP: Now using Justinmind (usable offline) - but can't share... will sort out later. Presents multiple mock-ups.

• RF: Motion towards circular icons over square?

• RW: We have the technology.

DW: Presents proposed structural model in an aim to help organise the team here and prepare for later, distributed work.

RW: Brief update from development... things going well, 2 different APIs, not so much else to share (for humans)

Drawing 1: Page mockup

Open

Drawing 2: Profile and Trust metrics mockup

Open

Drawing 3: Current structure with proposed changes

Open