we've grown to a size where it's becoming harder to manage the Hackspace on a casual "things will sort themselves out" basis. I'd like to suggest a few things we could do to cope with this. Let me know what you think.
(And please stay on topic.)
Things I would like to improve:
- how new members get introduced to the organisation
- how we manage shared resources (space, tools, donations, consumables)
- how we make decisions about the above
1. Subgroups
Most importantly I think it's worth formalising our relationship with Hackspace subgroups, to strengthen their remit, and to encourage the organisation of LHS activities within such groups. We've made some great experiences with the lockpickers, biohackers, the Music Hackspace, mind hackers, … Such subgroups solve many of the aforementioned problems (they take care of their own resources, they meet regularly, etc.)
I think it could work well to treat the main organisation merely as responsible for rent, memberships and donations, and a few basic resources, and let the rest be managed by subgroups. This could even mean that we stop supporting any activity that cannot be hosted by a suitable subgroup (a simple social mechanism to address a resource management problem.)
Additionally a few people are already discussing to what extent LHS member donations could be shared with subgroups; I think all trustees are keen to figure out a way to make this happen.
2. Meetings
Our initial decision not to have meetings worked well for a comparably small community where it was still easy to know all key members, but I think it's time to reconsider that now. I wouldn't mind a semi-regular member meet-up to discuss current issues, introduce new people to the organisation, etc.
This could also become a forum where subgroups negotiate their use of the space.
3. Mentors
Do people think it's worth introducing "mentors"? People who know the space well, who can introduce new people to the organisation, who can introduce them to other members with particular skills, or who could even help manage misunderstandings and disputes? (I'm not quite sure what best to call this. "Mentors", "community organisers", "volunteers", "moderators", …?)
Otoh maybe all of that would already be addressed by having more formal subgroups.
There's an AGM coming up soon, and a long-discussed members-only meetup (dates for both tbd). I think both could provide a good opportunity to discuss these matters in person, preferably in the presence of Hackspace subgroup representatives and both long-term and new Hackspace members.
I agree with the point on meetings. Although hackspace is not technically a club, we could take some guidance from a club structure. I've been a member of multple Astronomy and Ham radio clubs and the monthly meeting is an important part of it.
I propose a monthly meeting of members, open only to members. The meeting would be a chance to talk about the serious issues of the club with a set agenda each time. At the clubs I've been a member of in the past there was an executive comittee that met once a month about a week before the club meetng. They would produce and circulate an agenda for the club meeting that would be emailed to all members. Members could ask at any time before this for items to be included in the agenda. Once circulated no items could be added to the agenda.
So, if anyone has any issues that they would like discussed then they would send an email to one of the trustees and ask for it to be added to the next agenda. Certain re-occuring items are always on the agenda every week such as a review of the finances, etc. Long term projects (such as finding a new location) would be given a slot to deliver progress updates by the appointed person each month. Any rule additions or ammendments would be on the agenda for disucssion / debate and then voted on by the body. We always had tea / coffee / doughnuts at the astronomy / ham radio club meetings, and usually a talk of some sort pertinant to the club. For us a regular monthly general talk might be pushing it, but perhaps it could be done.
A sample agenda:
1. Call to order 2. Review of minutes from previous meeting. 3. Membership report (current membership numbers, introductions of new members if they wish, etc). 4. Financial review (Income for the last period, expendatures, donations, etc). 5. General news items or announcements from the trustees 6. Discussion of items ( bikes in the space, cleaning, sleeping in the space, rule changes, etc) 7. Break for tea / coffee / doughnuts 8. Show and tell presentations of projects, talks or presentations from members, etc. 9. Adjourment 10. Beer.
Obviously, not being a formal club by definition we do not have to abide by the strict structure for taking minutes and such that would be required of a proper club, but it couldn't hurt to have som discipline in this area. As well as general structure.
we've grown to a size where it's becoming harder to manage the Hackspace on a casual "things will sort themselves out" basis. I'd like to suggest a few things we could do to cope with this. Let me know what you think.
(And please stay on topic.)
Things I would like to improve: - how new members get introduced to the organisation - how we manage shared resources (space, tools, donations, consumables) - how we make decisions about the above
1. Subgroups
Most importantly I think it's worth formalising our relationship with Hackspace subgroups, to strengthen their remit, and to encourage the organisation of LHS activities within such groups. We've made some great experiences with the lockpickers, biohackers, the Music Hackspace, mind hackers, … Such subgroups solve many of the aforementioned problems (they take care of their own resources, they meet regularly, etc.)
I think it could work well to treat the main organisation merely as responsible for rent, memberships and donations, and a few basic resources, and let the rest be managed by subgroups. This could even mean that we stop supporting any activity that cannot be hosted by a suitable subgroup (a simple social mechanism to address a resource management problem.)
Additionally a few people are already discussing to what extent LHS member donations could be shared with subgroups; I think all trustees are keen to figure out a way to make this happen.
2. Meetings
Our initial decision not to have meetings worked well for a comparably small community where it was still easy to know all key members, but I think it's time to reconsider that now. I wouldn't mind a semi-regular member meet-up to discuss current issues, introduce new people to the organisation, etc.
This could also become a forum where subgroups negotiate their use of the space.
3. Mentors
Do people think it's worth introducing "mentors"? People who know the space well, who can introduce new people to the organisation, who can introduce them to other members with particular skills, or who could even help manage misunderstandings and disputes? (I'm not quite sure what best to call this. "Mentors", "community organisers", "volunteers", "moderators", …?)
Otoh maybe all of that would already be addressed by having more formal subgroups.
There's an AGM coming up soon, and a long-discussed members-only meetup (dates for both tbd). I think both could provide a good opportunity to discuss these matters in person, preferably in the presence of Hackspace subgroup representatives and both long-term and new Hackspace members.
(I've not found a design pattern to manage very large communities, but experience shows that social groups above a few dozen members tend to yield challenges that are hard to address, and community segmentation can help. EMF teams and villages worked incredibly well.)
Some excellent suggestions there. I think a (bi-weekly/monthly?) members
only meeting would be very good.
The subgroups idea is also nice, assuming we can get enough of the members
involved with infrastructure subgroups to keep the place ticking over
nicely without the same 5 or 6 people being _all_ the groups, I'd almost be
tempted to say that if you e.g. lead a group and commit to making sure the
workshop is tidy we'll waive membership fee (donations still welcome from
those that want to give them).
I know that having 'paid' members is an idea that has been shot down
several times but we have enough members that to run the workshop I'd be
inclined to say we need someone who's job it is to make sure that we have
the required consumables, that stuff is safe, that the wood pile is tidy
etc.
A lot of the rage re tidiness is that a lot gets done on a boom/bust cycle
(i.e. once every few weeks someone rage cleans) rather than
steady maintenance which is what is really needed.
S
On 28 September 2012 17:32, Martin Dittus <deks...@gmail.com> wrote:
> (I've not found a design pattern to manage very large communities, but
> experience shows that social groups above a few dozen members tend to yield
> challenges that are hard to address, and community segmentation can help.
> EMF teams and villages worked incredibly well.)
> (The "plenum" is one of the most widely adopted design patterns that we
> don't currently use. I'm told other groups have had great success with it.)
In terms of the work areas I personally think it would be very useful to have a dedicated member/members whose role is to be caretakers of the work areas.
But that does move us toward being a different type of organisation.
This may not be a bad thing as the being good to each other ethos in terms of workshop and tool maintenance does not always work.
How would this caretaker role be remunerated becomes a potential issue, as it does invoke significant involvement, perhaps some form of rota between caretaker volunteers ?
These 'caretakers' require enough authority to be able to stop stupid and 'bad' behaviour, and be able to organise and indeed 'run' the workshop so that members can effectively work there.
This authority does not have to be based upon punitive action but it does need to be there, they must be able to actually act.
\t
On 29 Sep 2012, at 12:32, SamLR <sam.lindenrat...@gmail.com> wrote:
> Some excellent suggestions there. I think a (bi-weekly/monthly?) members only meeting would be very good.
> The subgroups idea is also nice, assuming we can get enough of the members involved with infrastructure subgroups to keep the place ticking over nicely without the same 5 or 6 people being _all_ the groups, I'd almost be tempted to say that if you e.g. lead a group and commit to making sure the workshop is tidy we'll waive membership fee (donations still welcome from those that want to give them).
> I know that having 'paid' members is an idea that has been shot down several times but we have enough members that to run the workshop I'd be inclined to say we need someone who's job it is to make sure that we have the required consumables, that stuff is safe, that the wood pile is tidy etc.
> A lot of the rage re tidiness is that a lot gets done on a boom/bust cycle (i.e. once every few weeks someone rage cleans) rather than steady maintenance which is what is really needed.
> S
> On 28 September 2012 17:32, Martin Dittus <deks...@gmail.com> wrote:
> Just adding a few links to Hackerspace design patterns that relate to the three suggestions.
> (I've not found a design pattern to manage very large communities, but experience shows that social groups above a few dozen members tend to yield challenges that are hard to address, and community segmentation can help. EMF teams and villages worked incredibly well.)
On Saturday, 29 September 2012 12:56:58 UTC+1, timS wrote:
> Some interesting reading Martin...
> In terms of the work areas I personally think it would be very useful to > have a dedicated member/members whose role is to be caretakers of the work > areas. > But that does move us toward being a different type of organisation. > This may not be a bad thing as the being good to each other ethos in terms > of workshop and tool maintenance does not always work.
> How would this caretaker role be remunerated becomes a potential issue, as > it does invoke significant involvement, perhaps some form of rota between > caretaker volunteers ?
> These 'caretakers' require enough authority to be able to stop stupid and > 'bad' behaviour, and be able to organise and indeed 'run' the workshop so > that members can effectively work there.
> This authority does not have to be based upon punitive action but it does > need to be there, they must be able to actually act.
> \t
> On 29 Sep 2012, at 12:32, SamLR <sam.lind...@gmail.com <javascript:>> > wrote:
> > Hey Martin,
> > Some excellent suggestions there. I think a (bi-weekly/monthly?) members > only meeting would be very good.
> > The subgroups idea is also nice, assuming we can get enough of the > members involved with infrastructure subgroups to keep the place ticking > over nicely without the same 5 or 6 people being _all_ the groups, I'd > almost be tempted to say that if you e.g. lead a group and commit to making > sure the workshop is tidy we'll waive membership fee (donations still > welcome from those that want to give them).
> > I know that having 'paid' members is an idea that has been shot down > several times but we have enough members that to run the workshop I'd be > inclined to say we need someone who's job it is to make sure that we have > the required consumables, that stuff is safe, that the wood pile is tidy > etc.
> > A lot of the rage re tidiness is that a lot gets done on a boom/bust > cycle (i.e. once every few weeks someone rage cleans) rather than steady > maintenance which is what is really needed.
> > S
> > On 28 September 2012 17:32, Martin Dittus <dek...@gmail.com<javascript:>> > wrote:
> > Just adding a few links to Hackerspace design patterns that relate to > the three suggestions.
> > On 28 Sep 2012, at 16:26, Martin Dittus wrote:
> > (I've not found a design pattern to manage very large communities, but > experience shows that social groups above a few dozen members tend to yield > challenges that are hard to address, and community segmentation can help. > EMF teams and villages worked incredibly well.)
> > (The "plenum" is one of the most widely adopted design patterns that we > don't currently use. I'm told other groups have had great success with it.)
On 29 September 2012 13:18, tgreer <ukt...@gmail.com> wrote:
> I was under the impression this caretaker role was part of the trustees
> responsibility?
It is not, and I'd be interested to know where you got that
impression. The trustees exist purely to oversee the legal
responsibilities of the organisation. London Hackspace is operated by
its *community*, not by the trustees.
On Saturday, 29 September 2012 13:27:19 UTC+1, Russ Garrett wrote:
> On 29 September 2012 13:18, tgreer <ukt...@gmail.com <javascript:>> > wrote: > > I was under the impression this caretaker role was part of the trustees > > responsibility?
> It is not, and I'd be interested to know where you got that > impression. The trustees exist purely to oversee the legal > responsibilities of the organisation. London Hackspace is operated by > its *community*, not by the trustees.
There's nothing stopping members from warning other members that
they've overstepped the rules, but only trustees can formally warn and
ban people from the space.
As a new member, I am really interested in both the idea of newbie mentors, and subgroups.
For eg, some of us may benefit from a couple of weeks of new member inetgration. I'm not sure what rate people join at, but maybe a twice per month new members evening? I imagine if people were to volunteer to hold an evening session new members would be happy to donate a bit extra (and possibly beer and pretzels to the volunteer?). Maybe some of each new group could help with the next intake, as it were.
My issue with subgroups is the same as all specialisms - you end up not hearing much about the knitting with electrofluorescent material because you aren't a member of the threads subgroup. Maybe have two structures, the subgroups, and a random grouping, with it's own discussions and possibly meet ups - encouraging dissemination of info, news et cetera through those groups?
This maybe all sounds like a schools 'house' system - I went to a very middle class school, and it's ground in to me, sorry...
It only states: The trustees<http://wiki.london.hackspace.org.uk/view/Organisation/Trustees> have the authority to ban anyone from entering the space, and to strip anyone of their membership, but must only do so in circumstances where this is best for London Hackspace as a whole. It doesn't mention anything about giving warnings, is this written down somewhere?
Also: At every stage, the trustees must make their reasoning available to the offending party. They must also make as much detail as is appropriate<http://wiki.london.hackspace.org.uk/view/Grievance_Procedure/Warnings...> available to all members. I don't see much detail on there, and given this is the Grievance Procedure agreed by the members, all formal warning should be recorded not just the 2nd warnings and bans. If it states otherwise elsewhere please feel free to point me in that direction, otherwise please update the wiki with the relevant information of all warnings been issued.
On Saturday, 29 September 2012 14:18:25 UTC+1, Russ Garrett wrote:
> On 29 September 2012 14:11, tgreer <ukt...@gmail.com <javascript:>> > wrote: > > So what gives trustees the privilege to give warning and not other > members?
> Only trustees can give formal warnings, because that's what's set out > in the grievance procedure, which was agreed on by the membership back > in March:
> There's nothing stopping members from warning other members that > they've overstepped the rules, but only trustees can formally warn and > ban people from the space.
> It only states: The trustees have the authority to ban anyone from entering the space, and to strip anyone of their membership, but must only do so in circumstances where this is best for London Hackspace as a whole.
> It doesn't mention anything about giving warnings, is this written down somewhere?
> Also: At every stage, the trustees must make their reasoning available to the offending party. They must also make as much detail as is appropriate available to all members.
> I don't see much detail on there, and given this is the Grievance Procedure agreed by the members, all formal warning should be recorded not just the 2nd warnings and bans. If it states otherwise elsewhere please feel free to point me in that direction, otherwise please update the wiki with the relevant information of all warnings been issued.
> Regards
> Thomas
> On Saturday, 29 September 2012 14:18:25 UTC+1, Russ Garrett wrote:
> On 29 September 2012 14:11, tgreer <ukt...@gmail.com> wrote: > > So what gives trustees the privilege to give warning and not other members?
> Only trustees can give formal warnings, because that's what's set out > in the grievance procedure, which was agreed on by the membership back > in March:
> There's nothing stopping members from warning other members that > they've overstepped the rules, but only trustees can formally warn and > ban people from the space.
On 29 September 2012 14:23, tgreer <ukt...@gmail.com> wrote:
> It only states: The trustees have the authority to ban anyone from entering
> the space, and to strip anyone of their membership, but must only do so in
> circumstances where this is best for London Hackspace as a whole.
> It doesn't mention anything about giving warnings, is this written down
> somewhere?
The "intention" section is not the "binding" part of that document -
it's purely an introduction. Section 2.1 of the document says "The
offending party must be given at least two official warnings before
being banned."
> I don't see much detail on there, and given this is the Grievance Procedure
> agreed by the members, all formal warning should be recorded not just the
> 2nd warnings and bans. If it states otherwise elsewhere please feel free to
> point me in that direction, otherwise please update the wiki with the
> relevant information of all warnings been issued.
2.3 says "[the trustees] must also make as much detail as is
appropriate available to all members."
In August the trustees decided to only publish details of members who
are on their second formal warning or beyond. The reasoning behind
this was to avoid "naming and shaming" people who may have just
overstepped the line once.
On Saturday, 29 September 2012 14:31:29 UTC+1, Martin Dittus wrote:
> tgreer you're well off-topic now. If you want to discuss this then please > start a new thread.
> m.
> On 29 Sep 2012, at 14:23, tgreer wrote:
> > Ok thanks for clarifying...
> > It only states: The trustees have the authority to ban anyone from > entering the space, and to strip anyone of their membership, but must only > do so in circumstances where this is best for London Hackspace as a whole. > > It doesn't mention anything about giving warnings, is this written down > somewhere?
> > Also: At every stage, the trustees must make their reasoning available > to the offending party. They must also make as much detail as is > appropriate available to all members. > > I don't see much detail on there, and given this is the Grievance > Procedure agreed by the members, all formal warning should be recorded not > just the 2nd warnings and bans. If it states otherwise elsewhere please > feel free to point me in that direction, otherwise please update the wiki > with the relevant information of all warnings been issued.
> > Regards
> > Thomas
> > On Saturday, 29 September 2012 14:18:25 UTC+1, Russ Garrett wrote: > > On 29 September 2012 14:11, tgreer <ukt...@gmail.com> wrote: > > > So what gives trustees the privilege to give warning and not other > members?
> > Only trustees can give formal warnings, because that's what's set out > > in the grievance procedure, which was agreed on by the membership back > > in March:
> > There's nothing stopping members from warning other members that > > they've overstepped the rules, but only trustees can formally warn and > > ban people from the space.
> On 29 September 2012 14:23, tgreer <ukt...@gmail.com> wrote:
>> It only states: The trustees have the authority to ban anyone from entering
>> the space, and to strip anyone of their membership, but must only do so in
>> circumstances where this is best for London Hackspace as a whole.
>> It doesn't mention anything about giving warnings, is this written down
>> somewhere?
> The "intention" section is not the "binding" part of that document -
> it's purely an introduction. Section 2.1 of the document says "The
> offending party must be given at least two official warnings before
> being banned."
>> I don't see much detail on there, and given this is the Grievance Procedure
>> agreed by the members, all formal warning should be recorded not just the
>> 2nd warnings and bans. If it states otherwise elsewhere please feel free to
>> point me in that direction, otherwise please update the wiki with the
>> relevant information of all warnings been issued.
> 2.3 says "[the trustees] must also make as much detail as is
> appropriate available to all members."
> In August the trustees decided to only publish details of members who
> are on their second formal warning or beyond. The reasoning behind
> this was to avoid "naming and shaming" people who may have just
> overstepped the line once.
On 28 September 2012 17:18, IrradiatedHaggis <hs_t...@codemaven.me> wrote:
> I agree with the point on meetings. Although hackspace is not technically a
> club, we could take some guidance from a club structure. I've been a member
> of multple Astronomy and Ham radio clubs and the monthly meeting is an
> important part of it.
We are "technically" a club, although there's not a legal definition
of a club. We're a membership association, and hence we're the same as
most other clubs, with the difference that most clubs don't have
limited liability.
> I propose a monthly meeting of members, open only to members. The meeting
> would be a chance to talk about the serious issues of the club with a set
> agenda each time. At the clubs I've been a member of in the past there was
> an executive comittee that met once a month about a week before the club
> meetng.
A formal in-person decision-making meeting would be a fairly
significant change from the ethos we've been operating under. Although
we're a physical space we decided fairly early on that we wanted as
much of our decision-making as possible to be done online. We were
planning on using One Click Orgs to do this, but the changes necessary
have been taking some time.
> On 28 September 2012 17:18, IrradiatedHaggis <hs_t...@codemaven.me> wrote:
>> I agree with the point on meetings. Although hackspace is not technically a
>> club, we could take some guidance from a club structure. I've been a member
>> of multple Astronomy and Ham radio clubs and the monthly meeting is an
>> important part of it.
> We are "technically" a club, although there's not a legal definition
> of a club. We're a membership association, and hence we're the same as
> most other clubs, with the difference that most clubs don't have
> limited liability.
>> I propose a monthly meeting of members, open only to members. The meeting
>> would be a chance to talk about the serious issues of the club with a set
>> agenda each time. At the clubs I've been a member of in the past there was
>> an executive comittee that met once a month about a week before the club
>> meetng.
> A formal in-person decision-making meeting would be a fairly
> significant change from the ethos we've been operating under. Although
> we're a physical space we decided fairly early on that we wanted as
> much of our decision-making as possible to be done online. We were
> planning on using One Click Orgs to do this, but the changes necessary
> have been taking some time.
*LONDON HACKSPACE LTD is a not for profit company ltd by guarantee*
*
*
*as such it has directors and members*
*
*
*it can appoint trustees or any other officer to delegate powers and to
decide how other things are run*
*
*
*Question are LHS members, members of the company?*
*
*
*If so members meetings if properly notified can decide any issue such as
in an AGM or other type of meeting
*
On 29 September 2012 15:16, Benjamin Blundell <onida...@gmail.com> wrote:
> +1 for One Click Orgs. I remember hearing about this and I think its
> progressive and in the spirit of the thing.
> On 29 September 2012 15:12, Russ Garrett <r...@garrett.co.uk> wrote:
> > So, getting back on topic,
> > On 28 September 2012 17:18, IrradiatedHaggis <hs_t...@codemaven.me>
> wrote:
> >> I agree with the point on meetings. Although hackspace is not
> technically a
> >> club, we could take some guidance from a club structure. I've been a
> member
> >> of multple Astronomy and Ham radio clubs and the monthly meeting is an
> >> important part of it.
> > We are "technically" a club, although there's not a legal definition
> > of a club. We're a membership association, and hence we're the same as
> > most other clubs, with the difference that most clubs don't have
> > limited liability.
> >> I propose a monthly meeting of members, open only to members. The
> meeting
> >> would be a chance to talk about the serious issues of the club with a
> set
> >> agenda each time. At the clubs I've been a member of in the past there
> was
> >> an executive comittee that met once a month about a week before the club
> >> meetng.
> > A formal in-person decision-making meeting would be a fairly
> > significant change from the ethos we've been operating under. Although
> > we're a physical space we decided fairly early on that we wanted as
> > much of our decision-making as possible to be done online. We were
> > planning on using One Click Orgs to do this, but the changes necessary
> > have been taking some time.
-- *Paul Randle-Jolliffe Esq*
*Practicing Principal *(Lay Advocate & Public Interest Intervener)
Patrocinium Interventus
Isle of Wight, England.
www.patrocinium.eu Land Line: +44 (0) 207-193-9991
Mbl: +44 (0) 7 411 99 6893
*"Justice is itself the great standing policy of civil society; and any
eminent departure from it, under any circumstances, lies under the
suspicion of being no policy at all." Edmund Burke*
Warning: This message is for the named recipient only. Dissemination
prohibited without prior written authorisation. If you are not the named
recipient, please disregard this entire message, inform the sender then
destroy.
This message may contain material or opinion that does not necessarily
reflect the policy or opinion of the parent organisation, Patrocinium
Interventus* *. Copyright (C) 2010 Patrocinium Interventus.
On Sat, Sep 29, 2012 at 12:32 PM, SamLR <sam.lindenrat...@gmail.com> wrote:
> Hey Martin,
> Some excellent suggestions there. I think a (bi-weekly/monthly?) members
> only meeting would be very good.
> The subgroups idea is also nice, assuming we can get enough of the members
> involved with infrastructure subgroups to keep the place ticking over nicely
> without the same 5 or 6 people being _all_ the groups, I'd almost be tempted
> to say that if you e.g. lead a group and commit to making sure the workshop
> is tidy we'll waive membership fee (donations still welcome from those that
> want to give them).
> I know that having 'paid' members is an idea that has been shot down several
> times but we have enough members that to run the workshop I'd be inclined to
> say we need someone who's job it is to make sure that we have the required
> consumables, that stuff is safe, that the wood pile is tidy etc.
> A lot of the rage re tidiness is that a lot gets done on a boom/bust cycle
> (i.e. once every few weeks someone rage cleans) rather than steady
> maintenance which is what is really needed.
> S
> On 28 September 2012 17:32, Martin Dittus <deks...@gmail.com> wrote:
>> Just adding a few links to Hackerspace design patterns that relate to the
>> three suggestions.
>> (I've not found a design pattern to manage very large communities, but
>> experience shows that social groups above a few dozen members tend to yield
>> challenges that are hard to address, and community segmentation can help.
>> EMF teams and villages worked incredibly well.)
>> (The "plenum" is one of the most widely adopted design patterns that we
>> don't currently use. I'm told other groups have had great success with it.)
Yes, I agree that when turning them into actual proposals it will become important to explicitly state the problems that these suggestions are intended to solve. Additionally the suggestions don't clarify potential risks we'd be taking on; a proper proposal should attempt to identify them as well.
I left these parts out because the initial email was already long enough. I can add quite a bit of detail if desired. Email maybe isn't the best medium to have a conversation about it; but for now I'd be more than happy to discuss it in person.
I think over the past year many people have started pondering ways in which the space does and doesn't work as we keep growing. Based on my conversations there's a surprising amount of overlap in many people's perspectives and ideas. Meaning the process to "start by enumerating problems, and then move onto solving them" has already started long ago; it's just not very well expressed, and mostly happens in people's heads.
> These seem to be solutions.
> Shouldn't we start by enumerating problems, and then move onto solving them ?
> -adrian
> On Sat, Sep 29, 2012 at 12:32 PM, SamLR <sam.lindenrat...@gmail.com> wrote:
>> Hey Martin,
>> Some excellent suggestions there. I think a (bi-weekly/monthly?) members
>> only meeting would be very good.
>> The subgroups idea is also nice, assuming we can get enough of the members
>> involved with infrastructure subgroups to keep the place ticking over nicely
>> without the same 5 or 6 people being _all_ the groups, I'd almost be tempted
>> to say that if you e.g. lead a group and commit to making sure the workshop
>> is tidy we'll waive membership fee (donations still welcome from those that
>> want to give them).
>> I know that having 'paid' members is an idea that has been shot down several
>> times but we have enough members that to run the workshop I'd be inclined to
>> say we need someone who's job it is to make sure that we have the required
>> consumables, that stuff is safe, that the wood pile is tidy etc.
>> A lot of the rage re tidiness is that a lot gets done on a boom/bust cycle
>> (i.e. once every few weeks someone rage cleans) rather than steady
>> maintenance which is what is really needed.
>> S
>> On 28 September 2012 17:32, Martin Dittus <deks...@gmail.com> wrote:
>>> Just adding a few links to Hackerspace design patterns that relate to the
>>> three suggestions.
>>> On 28 Sep 2012, at 16:26, Martin Dittus wrote:
>>> (I've not found a design pattern to manage very large communities, but
>>> experience shows that social groups above a few dozen members tend to yield
>>> challenges that are hard to address, and community segmentation can help.
>>> EMF teams and villages worked incredibly well.)
>>> (The "plenum" is one of the most widely adopted design patterns that we
>>> don't currently use. I'm told other groups have had great success with it.)
> Yes, I agree that when turning them into actual proposals it will become important to explicitly state the problems that these suggestions are intended to solve. Additionally the suggestions don't clarify potential risks we'd be taking on; a proper proposal should attempt to identify them as well.
> I left these parts out because the initial email was already long enough. I can add quite a bit of detail if desired. Email maybe isn't the best medium to have a conversation about it; but for now I'd be more than happy to discuss it in person.
> I think over the past year many people have started pondering ways in which the space does and doesn't work as we keep growing. Based on my conversations there's a surprising amount of overlap in many people's perspectives and ideas. Meaning the process to "start by enumerating problems, and then move onto solving them" has already started long ago; it's just not very well expressed, and mostly happens in people's heads.
> m.
> On 10 Oct 2012, at 00:28, Adrian Godwin wrote:
>> These seem to be solutions.
>> Shouldn't we start by enumerating problems, and then move onto solving them ?
>> -adrian
>> On Sat, Sep 29, 2012 at 12:32 PM, SamLR <sam.lindenrat...@gmail.com> wrote:
>>> Hey Martin,
>>> Some excellent suggestions there. I think a (bi-weekly/monthly?) members
>>> only meeting would be very good.
>>> The subgroups idea is also nice, assuming we can get enough of the members
>>> involved with infrastructure subgroups to keep the place ticking over nicely
>>> without the same 5 or 6 people being _all_ the groups, I'd almost be tempted
>>> to say that if you e.g. lead a group and commit to making sure the workshop
>>> is tidy we'll waive membership fee (donations still welcome from those that
>>> want to give them).
>>> I know that having 'paid' members is an idea that has been shot down several
>>> times but we have enough members that to run the workshop I'd be inclined to
>>> say we need someone who's job it is to make sure that we have the required
>>> consumables, that stuff is safe, that the wood pile is tidy etc.
>>> A lot of the rage re tidiness is that a lot gets done on a boom/bust cycle
>>> (i.e. once every few weeks someone rage cleans) rather than steady
>>> maintenance which is what is really needed.
>>> S
>>> On 28 September 2012 17:32, Martin Dittus <deks...@gmail.com> wrote:
>>>> Just adding a few links to Hackerspace design patterns that relate to the
>>>> three suggestions.
>>>> On 28 Sep 2012, at 16:26, Martin Dittus wrote:
>>>> (I've not found a design pattern to manage very large communities, but
>>>> experience shows that social groups above a few dozen members tend to yield
>>>> challenges that are hard to address, and community segmentation can help.
>>>> EMF teams and villages worked incredibly well.)
>>>> (The "plenum" is one of the most widely adopted design patterns that we
>>>> don't currently use. I'm told other groups have had great success with it.)
