i guess i can also add that the ethos of makerspaces in general is that you can solve your own problems, including with the space. you don’t need permission to do that. we only found the limit of that ethos a few weeks ago.
so if someone believes that the way to solve this problem is to have a rota of sa members, then they should feel free to find people who are willing to join and set it up.
that applies to any of the other proposed solutions itt.
Sorry this is a bit scattered as several topics have come up.
I made a raspi Pico device to flash an LED strip when the shutter was up but there was no booking but was told in no uncertain terms by Joe it wouldn’t last long in the space. A physical shutter host chit might serve a similar purpose in ensuring we have a responsible shutter member as folks should know their own bookings. I’m happy to assist with either if that’s what we collectively decide.
Last time this came up, I did some analysis and 5 people were responsible for a majority of shutter opens yet only one of them regularly booked (shout out to @Ryanf!). It is a documented rule and responsibility of opening the shutter! Clearly it is important to some people and not to others.
I have suggested to each person who has reached out to help out with systems that a 3 click booking tool that would handle conflicts would be hugely helpful. It sits well with our current system but just make it a bit easier. I’m digging up the spec as @tmilner has recently volunteered. Anyone willing to join the effort?
I would argue that anyone who is regularly using the space should be contributing back and should easily get shutter! We tell people on tours, the expectation is that each person will find a way to chip in. Requiring that for even just one month doesn’t seem excessive to me.
Side note, the shutter bot often does not log when the shutter opens or closes which means the checkbox I wrote can’t see it. Hopefully we can replace the node soon but I am prioritizing getting woodshop tool control in place.
Culture change is hard. I’m echoing one of the above points - I think a simple change to SA would help enforce bookings and steer the culture back to our desired behaviour.
We use our fobs to unlock the door. I don’t know how SA works technically, but you could also use the fob to see if the person opening the shutter has booked in the calendar, and not permit opening it until a booking in their name has been made. No kiosk needed, use your phone or laptop. If the shutter is already open, no booking is technically enforced even if the second person is staying longer than the first.
This doesn’t help with planning ahead, but it does help with not knowing if the space will be closed before you arrive. It also supplements the current guidelines to pre-book.
Maybe the calendar isn’t mobile friendly. That’s not a blocker, but let’s fix that too.
I’m in UX design with frontend experience (mostly HTML/CSS). If there’s a way for me to help, I’m happy to!
I initiated the discussion and I just want to say that there is more to it than I initially thought. I believed that I was the only one with the problem, but it appears that there are many people in the same situation.
This is my interpretation
The Makers comments express concerns about the maker space’s shutter access (SA)
policy.
Some people think that the policy is not being enforced effectively, while others think that the policy is too restrictive.
There are a number of proposed solutions, including making it easier to book the space, using a gadget to alert people if the space is not booked, and requiring people to book the space even if they are only going to be there for a short time.
General Consensus:
In general, it appears that we are all discussing ways to improve the current system while acknowledging the complexities of changing culture and habits. There are suggestions for technical solutions, adjustments to the booking process, and finding a balance between flexibility and structure.
While some comments express concerns and frustrations with the current system, it is important to note that there is also recognition of the efforts being made by certain members to keep the space accessible.
Based on the feedback, here are some possible solutions that could be taken into account:
Implement a technical solution that provides reminders or facilitates quick input of expected time upon entry.
Encourage members with SA to consistently book their time in the space, reinforcing the importance of the policy.
Explore the possibility of setting specific open times during the week when the space is accessible to members without SA.
It is important to encourage members to work together to maintain an open and accessible space, especially given that they are volunteering their time. Recognizing the valuable contributions of these volunteers can play a significant role in ensuring a smooth-running process. Consistent adherence to booking policies and mutual support among members can help create an environment that benefits everyone.
Consider ways to balance the convenience of the “just show up” culture with the need for more predictability in access.
Any solution implemented should try to find a middle ground between the diverse requirements and preferences of the maker space community. It might also be advantageous to start discussions or surveys among members to gather more input and assess their preferences before making any changes.
Manuel, thank you for your work and input.
We are volunteer run, not a paid service.
Every person knows this before they sign up. It says in the invitation e-mail and we make sure that this is said at every single Open Evening.
Setting up a schedule for fixed opening times and in particular finding volunteers for that - in my humble experience of finding volunteers for a bi-weekly, 2 hour long event called Open Evening - is literally impossible, at the current state of how the Makerspace is set up to run. This is not a criticism, this is a matter of fact.
If you want 24/7/365 access to the Makerspace, have you considered applying for shutter access yourself?
Shutter access is for everybody. Since we are a community, we just want to make sure we know the people who we vouch for. It is a straightforward, proven process that has worked for quite a while.
When I was without SA, I found it very frustrating because of when bookings are made and for how long. I live 30 minutes away so can’t just “show up” and often bookings are made somewhat close to the date. The bookings are also spread in time, so some bookings might only be in the day but I only have time in the evening, etc…
Now that I have SA, I understand why. Life is a moveable target and not everyone can commit to a large chunk of time, especially if you don’t want to be in the position of kicking out someone who just started their project. For example, I only booked for tomorrow middle of this week and for the evening only, so other members who live away and wanted to come in this saturday will have to maybe cancel evening plans (normal things to make for Saturday) to ensure when they come. But there is a 60% chance the space will actually be open during the day and they needn’t have rescheduled things.
My point is that for members without SA, the current system can be frustrating, and for them it’s not overblown.
EDIT: qualified the above a bit.
This is a bit of a Catch 22: to get shutter access, you need to be around the space often enough that people recognize you as reasonable but to be around the space often enough without shutter access is difficult because of the ad-hoc booking system.
I’m not against the current system by the way, just wanted to say I sympathize with Manuel’s frustration because I felt it as well.
Just throwing a thought into this discussion, as a new member who is staring at the calendar thinking ‘uh oh, am I going to be able to do what I want to do later this week?’.
My proposal 
Add the marker (SA) against the names in Discourse of anyone who has shutter access
Right now I believe it’s only ‘Director’ or ‘Member’.
If getting friendly specifically with people who have shutter access is a key requirement in order to efficiently pursue SLMS projects, this would be helpful for figuring out who those people are (alongside correlating people I meet in the space with their profiles on Discourse…)
Discourse only allows the “primary” user group to be displayed next to a user avatar so this would probably require some heavy lifting behind the scenes. Not impossible though.
The old membership system used to do this, it would show “Member 
” as we used to call it key holder.
EDIT: In fact the group is still there unused - https://discourse.southlondonmakerspace.org/g/keyholders
EDIT 2: If someone gives me approriate access I am happy to periodically update this group manually until we stabilise our Discourse updates and then write an API integration again.