Minutes

Expectations of this meeting

ML : wants to have a way of working in order to come to a specification that we can agree on

TR: Listening

TB: Process to get to the specification, way on how people participate and work and decide on specs

DW: Help everyone do the work they want to do

JA: wants to get a deeper insight on decision making and wants to know where productu is at right now.

BN: since Malo unclearity on Specs, finding a way to efficently make product specifications

JT: Decision process is very simple, as soon as you have clear questions. We probably have unclear questions.

Discussion

DW: If decisions are made in small working groups write down names. Would envision a 'Contributors: x, y & z' - would include all contributors.

JT: Take the current problems and formulate questions.

ML: Seperate task of writing specification from carrying it out. 

JT: Review old decisions, find out if people responsible for those decisions are still around

DW: Some background - if all the desired features for the yunity platform were to be implemented before launch, we might not launch for a very long time. Launching different version is a standard way of developing. In Mainz the Minimum Viable Product was proposed. The MVP would be the first release, and would provide functionality for foodsharing users to migrate.

TB: Manuele puts some thoughts on Invision, Wiki specs did not connect to graphical mockup. We can not say wiki content is decided on.

JA: Some concerns about the vagueness in the three questions for the selection criteria for systemic consensus. 

TB: How do we reach the people who should/want to be involved into the decision making?

JT: People who are actually active are normally quite easily reachable, e.g. through slack, If they are not responding, they are not active. Online sc concerning really important decisions normally last a pretty long period od time, so that people who want to participate will be able to.

BN: In Malo everyone was in the product . There are few people who are actually working on the product now. There shold be more people giving input on what the product should be.

TB: Stages - 1) giving input 2) decision

TB: How do we know if people are actually fit to participate in votes?

JT: Trust them. Don't expect them to abuse the system beforehand.

DW: We deal with abuse if the problem pops up. In the end it all boils down to trust anyways.

TB: Working in a group needs adjustment from people that are used to work alone. Product team writes specification.

Bodhi: I see product tream as parent of design, development and specification.

JT: If i had asked 'Who is the product team?', would you have answered differently?

JT: You can change the definition of the word 'team' if it helps you getting the work done.

JT: You can be part of a multitude of teams, but it needs to be clear where the borders between the different teams are set and what the specific tasks of every team actually are.

TB: It's important to have a clear workflow, so it's important to identify in which team any given work originated, especially when it comes to work or suggestions coming from people who are part of various teams.

JT: Do we know how the product team works internally?

DB: Well... the product team doesn't officially exist, although we all seem to agree on the fact that a product team should exist.

JT: But if somebody is working on it, then we have a product team. We just really need to make it official, so that the chaos and unclarity stops spreading.

TB: We should definitely formally establish a product team. For me the definition of a product team includes: The product team evaluates our potential user's needs and formulates specifications for the product based on that.

JT: Isn' that hierarchical then, when the product team makes all the important decision?

TB: No? It's just a flow of information..?

DW: If we keep on using systemic consensus it won't be a problem.

JT: Ok, i don't have a problem with organizational hierarchy, we just need to have it clear and still keep on producing democratic decision making.

TB: It actually would be an hierarchical process, as to that product makes specifications and development and design carry them out. 

JT: This is actually collecting proposals right now. It's asking 'Should we work like that?'.

JT: What is the short definition of the product?

DW: I'd say it's the webapp and everything that makes it work. From the current glossary: "Refers to the webapp that individuals will download and use on their device. 'The product' is a webapp, 'the webapp' is the product - can be used interchangeably."

JT: But that is your personal definition then, but what is the opinion of the product team?

DW: Well, there is no product team...

TB: Why are we afraid of making a decision?

JT: It's first about collecting proposals and then decide later on.

TB: Question for the structure group: If there is something on the wiki and somebody disagrees, what should (s)he do? Simply change it?

JT: Good question... We are building a hopefully well documented structure now, but there have already been a lot of things happening before, and that's why we have a lot of confusion regarding these older developments. It will get better from now on, if we really adapt to the new culture of documentation and legitimizing, though.

TB: The problem is that we don't know how to document. Meaning most of the people who have been working in the frame of WuppDays. We normally document the outcome and not the process that lead to it.

JA: We definitely need a documentation team at some point, and also right now, we should name a person to take minutes on every important meeting, because it needs to be taken care of and everybody who does it cannot participate in the meeting as productively as those that don't have to write down what happens.

TB: Ok, we formulated questions and should put them out there for a sc, to take care of them. I also like the idea of taking the git-logic for the specifications: Everybody can add a modification/patch and if the others are okay with it...

JT: ...meaning nobody has strong objections...

TB: Yes, then it's gonna be added to the specs. I like it.

ML: It might be possible to put these kinds of discussions on the lower part of the specific pages of the wiki, although it would get kind of messy.

JT: We seem to be on a good way here. We just need to get it started somehow.

TB: So basically we collect proposals about how our workflow should look like, and then..?

JT: Then you decide on it. Because you are the ones who'll actually gonna do the work. But this way everybody who is interested is still able to contribute and participate. It's just the other way around as we are used to, because in traditional democracy the many only vote on proposals given by the few, whereas in sc the many can give proposals and the few(er) decide on them.

Feedback

TB: expected more workflow proposals, feels we need to skip some things.

DW: is overall happy, well spent time, 

JA: also thinks that it was time well spent, knows more about product now, is getting better at taking minutes

BN: feels like we are getting somewhere, even with loads of stuff popping up we are on the right track

JT: is was absolutely important to do this. it's exactly the communication we need, as it brings together teams in a productive way, which wouldn't understand a lot of what the other one is doing normally.

ML: we are on the way, we don't have a clear solution, but we now have means to work with, so i'm happy with it and it was actually all i was expecting this meeting to accomplish

Outcomes

Who is working on the tasks of the product team right now: Tilmann, Raphael, Manuele, Matthias, Martin