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!