[Hacker-event-theory] turning feedback from ohm into learning points

[Rejo Zenger]

++ 04/04/14 00:05 +0200 - Eelco Hotting:
>Commenting on some of the issues mentioned by Rejo.
>In general they hold up, just complicating things a bit to show that
>'as soon as possible'  doesn't automatically mean 'faster than at
>OHM2014'. Without getting too defensive, I hope. :)

I am aware of that. There are many ways to make such a declaration (e.g. 
"at least N days before start of event" or "within first N days after 
start of build-up", etc). What is most suitable depends on several 
factors, which I can't tell. Luckily I didn't intent to post the 
absolute truth. :)

>For those power and sanitation issues, it might be that this is
>important enough to declare it a requirement of the event site to have
>this infrastructure available, at least in a basic form, enough to
>facilitate build-up and tear-down. At OHM2013 this was clearly not the

But then again, what is "available" and "in a basic form"? Should there 
be power in one location or should it be available in all areas of the 
field, but just not to the maxium capacity?

And, if it is a requirement to have them available in a basic form, 
whatever that means, and it is not available from the beginning, than 
there must be some pre-buildup phase.

How is this problem solved at the CCC camp? There is some power from the 
start available, or do they start from the scratch as well?

>- For toilets and showers, you need water, power and sewage first.

Which makes me think: next time we should use a field that has all of 
that available. Like something of an area that is hosting a music 
festival at some other time of the summer (for example, the organisation 
of Lowlands have put the entire infrastructure for sanitation and water 
permanently in the field.) 

>- It helps a lot if there is some sanitation on terrain before you
>arrive. Putting it all there is a lot of trouble that you should
>avoid. Putting some extra toilets there is a lot less troublesome than
>having to arrange it all.

Exactly.

>- Having water and sewage on terrain before you arrive is worth around
>70K - 100K.

If you would have the infrastructure for power as well, what would your 
estimate be?

>> - financial - expences made during the event should be registered
>> in a system right away (preferably, there is a system that allows
>> the volunteer to enter the details in the system themselves and
>> have the volunteer attach a scan of the invoice immediately)
>
>Would be very nice to have software available to support this. We had
>arranged the CCC Koln cash desks, sadly this arrangement was aborted
>due to Foxgate. But yes, an hosted solution on site would be best.

Ok. If there was no such as Foxgate, than this issue would have been 
resolved for OHM? Or, to put it differently, this software is readily 
available - of there is no such thing as a Foxgate. 

>> More general, this should also get some attention:
>> 
>> - Internal communication (as in, between the teams, etc) and 
>> organisation.
>
>Too vague :p

I am aware of that: it's the way the different teams are talking to each 
other (who of which team will get together and at what frequency such 
meetings should happen, both horizontaly as well as verticaly). 

>There were actually quite some guidelines and policies. The sponsor
>document was quite clear. I believe the best way to go from here is to
>avoid sponsor money as a whole, and accept only sponsoring in natura
>like we do with the up-link and network equipment. Technically you
>have to value those services as well, and pay taxes over them.

Where can I find that sponsor document?

>Something to be considered: Pick a good site and stick to it. That way
>you can use the same buildup plans and improve on it, heck, you can

That sounds good to me. 


-- 
Rejo Zenger
E rejo at zenger.nl  P +31(0)639642738  W https://rejo.zenger.nl  T @rejozenger
PGP 1FBF 7B37 6537 68B1 2532  A4CB 0994 0946 21DB EFD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 931 bytes
Desc: not available
URL: <http://lists.hackerspaces.org/pipermail/hacker-event-theory/attachments/20140405/4328e499/attachment.pgp>