[#hack66] The Meat: Beer Assembly Structure
So, I was thinking yesterday that it would be a good idea to communicate a system that will guide our weekly assemblies :] I find this stuff is the most important & the most exciting. I've worked with Open Space & different types of Consensus Processes before & I know from experience that this is the real test. Once we have it down, hack66 & its projects will start to fly. The best guide I could find for this in a hurry is the one of Noisebridge, which I know Thrasos will appreciate: https://noisebridge.net/wiki/Meeting Take a look, C.
Especially this wiki page https://noisebridge.net/wiki/Consensus#Consensus_at_Noisebridge and https://noisebridge.net/wiki/More_Consensus_Info describes the process of "Consensus". Of course https://en.wikipedia.org/wiki/Consensus_decision-making is a great resource. To start with, using time-restricted slots for discussions on a topic will stop us from wasting time. When there are groups/individuals who do not reach a conclusion and are directly affected, they should further discuss it separately and come up with proposals at the next assembly. When the assembly consents on a topic individuals should accept it and act in accordance with it. They can always put it on the agenda for the next assembly if they have a new proposal. We should start creating pages for meetings, writing down the minutes and action items. Also the agenda should be available in advance. We have to fix the "model" of remote participation in G.A. I do agree that voting is not the best way for decision making. The tool of liquid democracy Thraros has been working on can be tested and why not adopted :) From: neeuqii@gmail.com Date: Thu, 20 Mar 2014 19:13:47 +0200 To: hack66@hackerspace.gr Subject: [#hack66] The Meat: Beer Assembly Structure So, I was thinking yesterday that it would be a good idea to communicate a system that will guide our weekly assemblies :] I find this stuff is the most important & the most exciting. I've worked with Open Space & different types of Consensus Processes before & I know from experience that this is the real test. Once we have it down, hack66 & its projects will start to fly. The best guide I could find for this in a hurry is the one of Noisebridge, which I know Thrasos will appreciate: https://noisebridge.net/wiki/Meeting Take a look, C. _______________________________________________ hack66 mailing list http://lists.hackerspace.gr/listinfo/hack66
Hey guys, regarding decision making process, i'll suggest that at the next assembly people who have an opinion or a model that they would like it to be adopted, they come prepared to explain it (using examples is a great way) and on turn-based style the rest will have to say what they like more. Then we can debate (over beer will be perfect) and finally as the great team we are, we make the final decision on how we take action for stuff. Chrystalleni and Marios already have provided some useful stuff (thanks guys) to investigate. All models more or less have a coordinator at each meeting. We should start doing it. The best way i see this working is that we all coordinate an assembly in round-robin. In this way, we all do that at some point. I think the coordinator should also take the notes for the agenda. Any thoughts on that?
We should start creating pages for meetings, writing down the minutes and action items.
Agreed. As an addition, i'd like to suggest that we start using web based project management systems. I've worked with trac, redmine and chili and i would like us to go with Chili. If you want me to elaborate just ask ;) Cheers, Nikolas. On Friday, March 21, 2014 12:53:17 PM Marios Isaakidis wrote:
Especially this wiki page https://noisebridge.net/wiki/Consensus#Consensus_at_Noisebridge and https://noisebridge.net/wiki/More_Consensus_Info describes the process of "Consensus". Of course https://en.wikipedia.org/wiki/Consensus_decision-making is a great resource.
To start with, using time-restricted slots for discussions on a topic will stop us from wasting time. When there are groups/individuals who do not reach a conclusion and are directly affected, they should further discuss it separately and come up with proposals at the next assembly. When the assembly consents on a topic individuals should accept it and act in accordance with it. They can always put it on the agenda for the next assembly if they have a new proposal.
We should start creating pages for meetings, writing down the minutes and action items. Also the agenda should be available in advance. We have to fix the "model" of remote participation in G.A.
I do agree that voting is not the best way for decision making. The tool of liquid democracy Thraros has been working on can be tested and why not adopted :)
From: neeuqii@gmail.com Date: Thu, 20 Mar 2014 19:13:47 +0200 To: hack66@hackerspace.gr Subject: [#hack66] The Meat: Beer Assembly Structure
So, I was thinking yesterday that it would be a good idea to communicate a system that will guide our weekly assemblies :] I find this stuff is the most important & the most exciting. I've worked with Open Space & different types of Consensus Processes before & I know from experience that this is the real test. Once we have it down, hack66 & its projects will start to fly.
The best guide I could find for this in a hurry is the one of Noisebridge, which I know Thrasos will appreciate: https://noisebridge.net/wiki/Meeting Take a look,
C.
_______________________________________________ hack66 mailing list http://lists.hackerspace.gr/listinfo/hack66
Hey everybody! looks like I'll be joining you virtually tomorrow as well. Chili is indeed an amazing tool! But is project-oriented. We should use it for project-specific management, progress tracking, bug and new ideas submission, documentation and so on. Loomio [0] is a new tool inspired by the Occupy movement. It is open source and we can host it by ourselves (we could event contribute). Tried Loomio beta, works very well and fits our need for an online consensus reaching tool. It's a good idea to have a coordinator and round robin shares the responsibility evenly. Not sure though if everybody must express his/her opinion on a topic. There could be a "pass" action. For the next assembly, add items at the agenda in this wiki page [1]. Goodnight, Marios [0] https://github.com/loomio/loomio/ [1] http://hack66.info/wiki:event:beerasm:2014_03_26 From: nikolas.sepos@gmail.com To: hack66@hackerspace.gr Date: Fri, 21 Mar 2014 14:01:43 +0200 Subject: Re: [#hack66] The Meat: Beer Assembly Structure Hey guys, regarding decision making process, i'll suggest that at the next assembly people who have an opinion or a model that they would like it to be adopted, they come prepared to explain it (using examples is a great way) and on turn-based style the rest will have to say what they like more. Then we can debate (over beer will be perfect) and finally as the great team we are, we make the final decision on how we take action for stuff. Chrystalleni and Marios already have provided some useful stuff (thanks guys) to investigate. All models more or less have a coordinator at each meeting. We should start doing it. The best way i see this working is that we all coordinate an assembly in round-robin. In this way, we all do that at some point. I think the coordinator should also take the notes for the agenda. Any thoughts on that?
We should start creating pages for meetings, writing down the minutes and action items.
Agreed. As an addition, i'd like to suggest that we start using web based project management systems. I've worked with trac, redmine and chili and i would like us to go with Chili. If you want me to elaborate just ask ;) Cheers, Nikolas. On Friday, March 21, 2014 12:53:17 PM Marios Isaakidis wrote:
Especially this wiki page https://noisebridge.net/wiki/Consensus#Consensus_at_Noisebridge and https://noisebridge.net/wiki/More_Consensus_Info describes the process of "Consensus". Of course https://en.wikipedia.org/wiki/Consensus_decision-making is a great resource.
To start with, using time-restricted slots for discussions on a topic will stop us from wasting time. When there are groups/individuals who do not reach a conclusion and are directly affected, they should further discuss it separately and come up with proposals at the next assembly. When the assembly consents on a topic individuals should accept it and act in accordance with it. They can always put it on the agenda for the next assembly if they have a new proposal.
We should start creating pages for meetings, writing down the minutes and action items. Also the agenda should be available in advance. We have to fix the "model" of remote participation in G.A.
I do agree that voting is not the best way for decision making. The tool of liquid democracy Thraros has been working on can be tested and why not adopted :)
From: neeuqii@gmail.com Date: Thu, 20 Mar 2014 19:13:47 +0200 To: hack66@hackerspace.gr Subject: [#hack66] The Meat: Beer Assembly Structure
So, I was thinking yesterday that it would be a good idea to communicate a system that will guide our weekly assemblies :] I find this stuff is the most important & the most exciting. I've worked with Open Space & different types of Consensus Processes before & I know from experience that this is the real test. Once we have it down, hack66 & its projects will start to fly.
The best guide I could find for this in a hurry is the one of Noisebridge, which I know Thrasos will appreciate: https://noisebridge.net/wiki/Meeting Take a look,
C.
_______________________________________________ hack66 mailing list http://lists.hackerspace.gr/listinfo/hack66
_______________________________________________ hack66 mailing list http://lists.hackerspace.gr/listinfo/hack66
Sovara I was JUST working on the same thing! (But on a google doc) C. On 25 Mar 2014 20:43, "Marios Isaakidis" <misaakidis@yahoo.gr> wrote:
Hey everybody!
looks like I'll be joining you virtually tomorrow as well.
Chili is indeed an amazing tool! But is project-oriented. We should use it for project-specific management, progress tracking, bug and new ideas submission, documentation and so on.
Loomio [0] is a new tool inspired by the Occupy movement. It is open source and we can host it by ourselves (we could event contribute). Tried Loomio beta, works very well and fits our need for an online consensus reaching tool.
It's a good idea to have a coordinator and round robin shares the responsibility evenly. Not sure though if everybody must express his/her opinion on a topic. There could be a "pass" action. For the next assembly, add items at the agenda in this wiki page [1].
Goodnight, Marios
[0] <https://github.com/loomio/loomio/>https://github.com/loomio/loomio/ [1] http://hack66.info/wiki:event:beerasm:2014_03_26
------------------------------ From: nikolas.sepos@gmail.com To: hack66@hackerspace.gr Date: Fri, 21 Mar 2014 14:01:43 +0200 Subject: Re: [#hack66] The Meat: Beer Assembly Structure
Hey guys,
regarding decision making process, i'll suggest that at the next assembly people who have an opinion or a model that they would like it to be adopted, they come prepared to explain it (using examples is a great way) and on turn-based style the rest will have to say what they like more. Then we can debate (over beer will be perfect) and finally as the great team we are, we make the final decision on how we take action for stuff.
Chrystalleni and Marios already have provided some useful stuff (thanks guys) to investigate.
All models more or less have a coordinator at each meeting. We should start doing it. The best way i see this working is that we all coordinate an assembly in round-robin. In this way, we all do that at some point. I think the coordinator should also take the notes for the agenda. Any thoughts on that?
We should start creating pages for meetings, writing down the minutes and
action items.
Agreed. As an addition, i'd like to suggest that we start using web based project management systems. I've worked with trac, redmine and chili and i would like us to go with Chili. If you want me to elaborate just ask ;)
Cheers,
Nikolas.
On Friday, March 21, 2014 12:53:17 PM Marios Isaakidis wrote:
Especially this wiki page
https://noisebridge.net/wiki/Consensus#Consensus_at_Noisebridge and
https://noisebridge.net/wiki/More_Consensus_Info describes the process of
"Consensus". Of course
https://en.wikipedia.org/wiki/Consensus_decision-making is a great
resource.
To start with, using time-restricted slots for discussions on a topic will
stop us from wasting time. When there are groups/individuals who do not
reach a conclusion and are directly affected, they should further discuss
it separately and come up with proposals at the next assembly. When the
assembly consents on a topic individuals should accept it and act in
accordance with it. They can always put it on the agenda for the next
assembly if they have a new proposal.
We should start creating pages for meetings, writing down the minutes and
action items. Also the agenda should be available in advance. We have to
fix the "model" of remote participation in G.A.
I do agree that voting is not the best way for decision making. The tool of
liquid democracy Thraros has been working on can be tested and why not
adopted :)
From: neeuqii@gmail.com
Date: Thu, 20 Mar 2014 19:13:47 +0200
To: hack66@hackerspace.gr
Subject: [#hack66] The Meat: Beer Assembly Structure
So, I was thinking yesterday that it would be a good idea to communicate a
system that will guide our weekly assemblies :] I find this stuff is the
most important & the most exciting. I've worked with Open Space & different
types of Consensus Processes before & I know from experience that this is
the real test. Once we have it down, hack66 & its projects will start to
fly.
The best guide I could find for this in a hurry is the one of Noisebridge,
which I know Thrasos will appreciate: https://noisebridge.net/wiki/Meeting
Take a look,
C.
_______________________________________________
hack66 mailing list
_______________________________________________ hack66 mailing list http://lists.hackerspace.gr/listinfo/hack66
_______________________________________________ hack66 mailing list http://lists.hackerspace.gr/listinfo/hack66
participants (4)
-
Marios Isaakidis -
nee -
nee ii
-
Nikolas Sepos