On 14.03.2017 09:01, Bernadette wrote:

ACK. To put it into other words: [...]

Wow wow wow I am not a big fan of formalizations like that. You make it look like that's a fixed state machine, and that that is how it needs to always happen. I am strongly against that, and the way I expressed it was a lot weaker. But, it helps me to clarify how I meant it.

0.0 - Project contacts gamamabel (or any other core-person)

No. _Anyone_ can suggest _anyone_.

1.0 --- Person informs the List

Not a requirement. I wrote "in cases where the new folks don't mind". We should not make complete exposure a requirement, but it is simply a sane way to offer an option of introduction.

1.1 --- List can give +/0/- on-list OR off-list 1.2 ---- IF no further discussion 2.0 ----- Project joins onionspace 1.3 ---- ELSE List decides in/out 0.2 -- ELSE person includes others from List; UNTIL reached 0.1; ELSE out

Is that correct? It might look very regulated, but thats most probably the natural way things will go anyway.

It completely depends on the reactions, on individual conversations, on how it works in the beginning. Like in any hackerspace, a "not fitting" person can kill a lot of the vibe, and it's hard to find out.

2.0 JOIN; might need to be defined a bit. Eg: - persons of project getting key/token - joins this ML (? mandatory?) - invitation to irc#onionspace

Technically, we are currently limited in that there is no expiry of keys yet. I do want permanent users to be able to hand out temporary keys, so there's another world of processes to be invented here on how that works exactly. In pracise I think we should rename the space, and move the mailinglist off of TPI infrastructure. Almost nobody that uses the space these days works on Tor. I don't want to enforce being subscribed to an organizational mailing list. This is always the question, how do we ensure that people are included and get notifications, but not flooded with a lot of mail that bores them. In our case, it's even easier: The overall goal of the space is to provide a work environment, so people can focus on their project. This means, in contrast to most hackerspaces, that we "by design" don't want more than a few to take care of things, come up with new ideas, and generally be the "space keepers". We do not need to annoy everyone who just wants to go some place to work with all the details. I think we will do fine if we /invite/ people to be part of an organizational team, but if they don't then shut up and not ask them about what the color of the toilet brush should be. That being said, I think it's a good idea to collect email addresses and put everyone on an "announcement" mailing list, in case we need to reach everyone. Then, we can create an orga mailinglist, and make the archive available to people with permanenent tokens.

...

...

We can try and keep the main room "quiet" for this, and ask people to go into the smaller rooms for longer conversations. Will add this to my notes of the concept note.

Naturally I've done it that way: When I had to do a phone call, i went outside. When Nana and me had to talk, we moved to one of the smaller rooms. But: That was only for a predefined meeting. When glaxx, richie and me ended up in discussions eg around the lock, we didnt move away. Here we might wanna have a clear statement that "quietness is more important than noise - so if you are annoyed by noise, tell the ppl to get a room" - something along those lines to give everyone a "sudo shutup -h now" ;)

And again, I think this can be best communicated and lived in form of habit, not in form of a strict ruleset. The space is a co-working space, which means people use it for work. This does not mean that if there's one guy with closed headphones that does not seem to mind, and 5 other people that want to talk, that they have to artificially stay quiet because some rule §17.4 says so. It really depends on the _current_ situation, who uses it, etc. I am not a fan of rulebooks since I'm seeing too many people that follow the rules without understanding what the initial motivation of the rule was, and when it applies. And when it does not apply. However, I agree that we should find a nice way of communicating that of course you cannot run in and start a party while others are there working.

Therefore it is also actually important to keep the rooms useable - which might have to be included into the guest-guidelines: "As a guest you shouldn't occupy any onionspace as a personal space"?

It might be annoying for the guest to re-build the bed each day even if no one ever needs the space - so maybe we should rather move towards somewhat of an "advance notice". *thinking out loud*

Anyone staying in the space should understand that they are "low priority", and that they of course should not spread out all their stuff everywhere and expect that people who come there to work won't get annoyed. I don't want to go as fas as "YOU CANNOT OCCUPY THE SPACE", because again it depends on a lot of factors and circumstances. In times where nobody uses the small room(s), why should they not be used for that. When I sleep over, I use one of the foldable beds in the small room with the door (we still need a door for the second room but nobody is working on that!), and, depending on who I know will be using the space the next day and how, I remove the bed in the morning or I don't. This can lead to surprises, but hey, don't we all like surprises. We definitely do not need to hide that people sleep there. As can also be seen by the toothbrushes etc in the bathroom. :)

Anyway this is only relevant if we have - multiple guests using both rooms at a time AND - multiple person/groups having a need for talking

I think it depends a lot on frequency.

Please let me know if I am annoying you with ETOOMANYRULES

I dont see this as rules at all, but more some best practices to live & work together.

Yeah we're on the same page, and I think it is important to bring this up and talk about it, and to derive some friendly written "best practices". Thanks!

To follow up, I'd strongly prefer this space to have a good spread of topics and activities, rather than by related groups of people working on the same or similar things. That's not to say I don't want these people here, we can try it out. But I think it should be made clear that, they should keep the balance of the space in mind. Concretely what this means is e.g.: - If they need to talk about their project for more than a few sentences at a time, they should move to a separate room. - They shouldn't regularly invite their other work friends into the space, until (we're in a situation where) the space regularly also has other types of people/projects. - Likewise, we shouldn't invite similar people/projects in, until the space also has other types of people/projects. We don't have to formalise this, these are just some concrete examples to show the sorts of things I mean. In case the above feels too much like "making rules" or "making policy": I'm also happy to talk about why I'd like this sort of balance, in more detail. That would take a much longer email though. X Ximin Luo:

Hey these all seem cool,

I am slightly concerned about the Syrian Archives one only because they are 3 people, and that is already more than the regular number of people per day (Usually 0 or 1 or 2, rarely 3). Not sure how to deal with this concretely, I will keep thinking about it.

X

Moritz Bartl:

...

Hi!

We didn't yet define exactly how we would add people. I think it's a good idea, in cases where the "new folks" don't mind, to inform the list and then allow comments to be made off-list or on-list if people object for one reason or another.

At the Prototype Fund kickoff meeting, two projects showed interest in using the OnionSpace. One is the "Syrian Archive", something which I think would fit perfectly well thematically, and also because their language is English (3 people), who some of you have already met: https://syrianarchive.org/

The other "application" is coming from a nice and friendly German, who I asked to write a brief intro for us.

All those people want to use it as office space for mostly focussed work. We can try and keep the main room "quiet" for this, and ask people to go into the smaller rooms for longer conversations.

-------- Forwarded Message -------- From: Vincent <mail@vincentahrend.com>

Hi Nerds,

My name is Vincent, I am 28 years old. I would be very glad to be able to work in your space in ExRotaprint on my current mietlimbo project for the coming six months.

Mietlimbo is an open-source project to improve the user experience of lowering your rent in Berlin according to the Mietpreisbremse law. It will consist mainly of an interactive web app with which people can more easily than now find out whether this law applies for them, how much they can save on their rent and how to *actually* go about it. I am working on this in the context of the Prototype Fund in which Accounting For All and the Syrian Archive projects are also enrolled.

I am looking for a space where I can work mostly on week days from ~noon - 6pm. When I'm working I prefer less talk and more focus on coding. Still, I would love to meet people, see what they are working on and maybe even get inspired and start hacking on something together.

For my personal background, I have studied Cognitive Science (everything about brains, how to fake them with a machine and why you shouldn't (couldn't) do it), where I was particularly interested in collective intelligence / consciousness and whether internet technology might be a first step towards that. In general, I like coding (mostly web dev and stuff I build for my raspberry pi), reading about internet culture, politics, random things, Jazz, Funk and Dubtechno, art, light and sound and talking to nice people :)

Hope to meet you all soon!

Vincent _______________________________________________ onionspace-berlin mailing list onionspace-berlin@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/onionspace-berlin

-- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git

Moritz Bartl:

[,,]

As an example, I think Syrian Archive is a good fit since it's an open source software project (not hardware), and because they use English to communicate, but also that it _is_ a project with a "human rights angle".

[..]

I think these types of projects can be good topic-wise, but my experience of the "scene" around these particular topics in Berlin is that it's heavily over-represented in terms of the number of people and community attention, and there are some unconstructive social dynamics in there that I'd prefer the onionspace not to have. (I can also talk about this in much more detail, some of it not very kind.) Balancing the number of people by topic, I think is a way to achieve that. The housing regulations project seems pretty cool, I find it interesting why not more people are working on projects like those. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git

Juris - torservers.net:

Am 14.03.2017 um 14:47 schrieb Ximin Luo:

...

Moritz Bartl:

...

[,,]

As an example, I think Syrian Archive is a good fit since it's an open source software project (not hardware), and because they use English to communicate, but also that it _is_ a project with a "human rights angle".

[..]

I think these types of projects can be good topic-wise, but my experience of the "scene" around these particular topics in Berlin is that it's heavily over-represented in terms of the number of people and community attention, and there are some unconstructive social dynamics in there that I'd prefer the onionspace not to have. (I can also talk about this in much more detail, some of it not very kind.)

I think Ximin is right here. Some "orgs" are annoying, so we should choose really carefully the orgs we want to have in the space. (I'm not talking about individual people)

@Ximin: Do you have any experience with the Syrian Archive?

No. I'm open to getting to know them better, but it's important to set some expectations beforehand. It's harder to properly express why you are annoyed by particular behaviour whilst it's happening or afterwards, better to make sure they "get" it before it happens. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git

On 14/03/17 15:23, Ximin Luo wrote:

No. I'm open to getting to know them better, but it's important to set some expectations beforehand. It's harder to properly express why you are annoyed by particular behaviour whilst it's happening or afterwards, better to make sure they "get" it before it happens. Sounds reasonable