For the sake of simple maintainability, using the discourse calendar might be the best medium-term approach? (The short term being the upgrade to latest-1 discourse). Does anyone have any experience with how open the project is to feature contributions?
Happy to be an extra pair of hands in any server work or discourse plugin work as needed. 
No to custom software development.
Yes, syncing roles and permissions- but maybe we do that manually (e.g. when a person passes an induction). It’s a little more to do, but not that often, and maybe we have a role for an admin volunteer to support that.
I’d start by looking at existing systems e.g. deskbird. They are paid for, but they often give free accounts to educators, non-profits etc. We can reach out and ask if there is a system that might be suitable. We could be a marketing case study to show how e.g. deskbird can be used not just for hotdesks. Extending their use in that way might bring tech support and assistance from the developers.
https://www.deskbird.com/desk-booking?_gl=11p1uy0g_up*MQ…&gclid=Cj0KCQjwlZixBhCoARIsAIC745A4d0Z72L1ch_cQdwhhbffHet5KplNSB8k_RUjy8eHi6X_1X2hETcYaAqhJEALw_wcB
When I looked at these kinds of systems I felt like we would end up with something similarly hacky to the discourse calendar.
I’ve not looked specifically at DeskBird (or at least I dont remember looking at it) but I looked at several similar systems and at best they provide a way to book the space as a host, but then we still would have to fall back to doing tools as a comment or something. Doing that leaves most of the functionality of these systems unused.
None of the systems I looked at offered a way for a group of users to easily control the open times and then allow booking of resources during that time (which is effectively what we want, it could also be booking a resource that is the space which then allows other to book a sub-resource which is the tool). Sadly there is basically zero motivation for companies to add this as they wont get much money from it. I even asked a few that looked more promising and got nothing useful back.
If we do find something that works it would be great but I dont hold much hope for it.
Glad to see a lot of folks who had volunteered jumping up to help! Just tagging @vladisl0th and @Martyn_Thomas as well
The plugin I wrote is a simple interface with a datetime picker for the start, a duration, and an optional tool dropdown. It fires from the top menu so only takes a couple clicks. It does handle duplicate bookings but offers to truncate your booking past existing bookings. The logic can certainly go beyond MVP for anyone who is interested.
I think we should definitely evaluate SSO options. The challenge comes in that we would like to only have shutter holders make the space available for further booking.
Would be good to meet up an evening this week if folks available so I have included a poll
0 voters
I have briefly looked at options with a room+desk paradigm but came up short as well
Same here - I’m keeping hunting and currently talking to a product atm to see it’s suitable…but looking less likely.
Sadly not around this week
I don’t know, but that might potentially be done via managers and groups. I.e. a manager makes a booking for the space for a certain period. Users could then join that group and make bookings of resources.
Not denying that there are options - just saying that in my opinion, in everything I have seen so far you end up trading a lot of other things to be able to fit that square peg into a round hole (members who can open a space and allow other members to book subspaces/desks/rooms/tools) because none of the systems I have seen had such a use case actually in mind. If by luck you end-up being able to sorta make it work, it will come with caveats like having those users be admins and being able to change everything about how that system works.
I struggle to come up with a realistic example where a person being able to control the opening/closing time of your office/gym/school/business/etc. without being able to control much more about how that space operates outside of SLMS.
In the end, I really do feel that what we have is kinda the best option (however bad/sad that sounds).
I hope I am making sense.
Makes total sense about roles and permissions. Want to have suitable tiers e.g. - global admin, manager, group manager, user. If every member with SA had to have global admin, it wouldnt be fit for purpose.
https://help.deskbird.com/hc/en-us/articles/8608059313681-Roles-and-permissions-in-deskbird
In my opinion a Discourse plug-in is a good idea, versus having a separate platform for booking. This would be less complex for the end-user experience and is one less system to manage for our time-strapped @systems team.
Therefore, I would suggest we build a proof-of-concept plug-in to determine the feasibility of having a first-class booking tool built-in to Discourse. This is something that I would be personally willing to invest time in.
The Discourse tech stack being Ruby and Ember.js is a little unfortunate as these are technologies that are less popular in 2023. The documentation from Discourse on creating plug-ins seems rather limited too. However, I’d be willing to give it a good go!
If following the proof-of-concept we determine that it is not feasible [1], then (again, in my opinion) a third-party platform with SSO / OAuth integration would seem like a reasonable second chioce we could build a PoC for.
[1] My primary concerns with the feasibility of the plug-in approach are 1) the plug-in is prohibitively difficult to write, due to limitations of the Discourse plug-in API, etc. 2) breaking changes to the plug-in API making it more difficult to upgrade Discourse in general, 3) the limitations of the user experience having to fit into the Discourse UI.
Agreed that the technologies aren’t my preferred but getting Discourse + discourse-events + docker running on my local MacOS env wasn’t horrible (once I sufficiently downgraded each to old versions). So that’s nice at least.
Also agree with everyone that custom code is a maintenance risk, but with the outpouring of responses here I think our bus factor for programming is pretty decent + we won’t be making constant code changes so good documentation goes a long way (vs docs getting stale quickly).
In theory one reason to use an external plugin vs our own is that the maintainers will update it as necessary for us, but that’s not guaranteed.
Where do we keep our documentation for Discourse and our internal stuff?
I see https://github.com/southlondonmakerspace but I feel it would be fairly reasonable to have a Tool page for Discourse (it’s not physical but it’s a useful tool!) that could explain how members could contribute development expertise + time.
Do we know if any other Makerspaces in the UK or elsewhere use Discourse for their forum? They all likely are solving similar problems (or wish to) and sharing a plugin could also make it easier to maintain.
Aware that we might be edging into too many cooks territory here, but if ruby expertise is needed, I’ve been working primarily with Rails for 16 years or so now (
) and would be happy to make myself useful.
(ETA that this doesn’t mean I favour a custom plugin particularly, and I share @jwa’s three concerns about the viability of a custom plugin, particularly around plugin API stability. Happy to help assess that, though.)
Most other Makerspaces are very much smaller. They are often open at set times e.g. 2 evenings a week. Others don’t seem to have the shutter access type requirement with 2 tiers of users etc.
It makes a lot of sense to have documentation etc. on Discourse as you suggest. I’m not sure toolpages are the right place. It’s already cluttered there and getting hard to find things. Perhaps the ‘How To’ section and signposting, or probably better, a separate section for SLMS systems (tool control, interlocks, Discourse, Apps etc.).
Gotcha, too bad. We’re not the only space that thinks about this so we can pull UI/UX ideas elsewhere if we decide to have our own discourse plugin (if we can’t find a suitable alternative that fits our needs and is maintained elsewhere.)
We have this already - you just can’t see it unless you are on @systems
All the code is on GitHub - in a private repo…
So the bones are there, we just need more folks on @systems… @urbanautomaton - there are enough projects to divide and conquer if you will, so I think we can use the help!
Hand in hand with that, we also need help in documentation. Toolpages could be better organised. The info in them is often incomplete. Some don’t even say that an induction is needed, and can give the impression it’s not. There is probably things could be done to e.g. document fire system etc. And a starting point might be a brief ‘how to ‘ for creating pages in Discourse - with collapsible navigation, titles etc. (and style guide).
An @documentation group might be a way to get new members to participate and contribute.