nottinghack / rules Goto Github PK

Some rules say "We" (such as "We ask that you respect the Hackspace") but it's not immediately clear who "We" is.

Maybe these items should be reworded to avoid the use of "We" and prefer the use of the Hackspace being the object of the sentences? (It's been a long time since I did any formal English studying so apologies if that's not the correct terminology!)

This may need to extend to the difference between the Hackspace (as a legal entity and a collection of the physical space and it's memberships) and the space (the physical area the Hackspace occupies) as well.

Then again, maybe I'm being a bit too pedantic and these changes would make the wording seem too formal and authoritarian.

The rule currently states:

"When a member stops paying their standing order, they will become an Ex-Member."

Some clarification of what this means, and the timescales involved would be good. E.g.

How long it is before it is decided a member has not paid their standing order?
Is a member given a chance to correct this before their membership is terminated (i.e. before RFID access is cancelled?)

Maybe a link to a full description of the "termination process" is needed.

Looked at all the rules now and FWIW, think they're all excellent - specially Be Excellent To One Another. But there's the issue for me, embedded in link [1] which ==> SafeSpaces policy.
Could we call it SafeSpace policy ? This is Hackspace, not Hackspaces, albeit there's going to be 2.5 accessed by a flight of stairs.

SafeSpaces , plural as here, connotes all sorts of very recent political things, like no-platforming people in institutions of Higher Education (until not so long ago spaces for open and free debate and discussion) ; areas on campuses reserved for people of a certain race ; and erasing / denying history by tearing down sculptures and etc., etc.

I don't know if the phrase "SafeSpaces Policy" was intended to evoke this overtly political aspect, to be embedded in our rules ?

(Can't fault the actual policy)

I propose that the SafeSpaces policy be brought into the rules as well for the same reason that the greivance procedure should be brought in.

We should amend the rule numbering to place rule 0 in section zero or remove the rule 0 designation on the "do not be on fire" rule.

It is disharmonious to have a rule 0 in section 1, we should strive for consistency, harmony any beauty in all that we attempt.

we should include something about young hackers and under 16's in here

Lines in questions

We encourage the safe use of tools and you must self certify that you are comfortable using a tool - except in the case of tools requiring an induction, where the inductor will certify you have been fully inducted.

Inductors do not "certify" a members used for use of a tool but rather ...

Possibly reword / replace the "Tasks that always require..." section with a link to a Wiki page of common tasks that anyone (unskilled) can do to help improve the space (even in a small way) with cross links to where to find materials and items required to complete the task (e.g. for empty the bins & recycling, where the bin bags are, where the full bags should be put and how to get there).

The membership of the hackspace rule contains amongst other provisions
"Nottingham Hackspace Ltd is required under Companies Act [1] to keep a record of all members legal name and current address."

I think this section may be confusing the term "Member" as used by the hackspace and "Member" as used by the companies act.

In the companies act a "Member of the company" is a shareholder of the company.
As far as I am aware "Members of the hackspace" are not shareholders of the limited company and hence not in the legal sense members of the company ?.

As a matter of interest who are the shareholders of the limited company ?

Hey folks,

I'm in the process of setting up a Hackspace in Monmouth, Wales - are we ok to steal this and amend as we see fit? I'm not too sure what we can and can't do having read the LICENSE file as this isn't my area of expertise...

Thanks,

Matt

What do you think about creating a directory called "rules" and moving the rules into it? It might make it more accessible for the non-technical amongst us if all the rules were in the same place and not mixed with other files used for building the documents etc.

Similarly, we could rename the filenames so as to include their number, which would also put them in the right order. For example: "0-do-not-be-on-fire.rst".

Link to cost of hacking page seems to be broken

Further to the discussion in issue #24, do the obligations of the Hackspace to its insurer require any other additions or amendments to the rules? Perhaps someone (me?) can read through and see if there are other duties which should be made clear to the members in the rules.

It would be regrettable if a member were to breach the terms of our insurance because we hadn't properly made clear our obligations to the insurer in the rules.

I propose that the grievance procedure be brought into the rules, so that it can come into the source control of the github repository and be part of the consultation. It has already become relevant to discussions, including the debate on inclusion of UK law.

Arguably, the greivance procedure already contains its own rules separate from the current rules. For example, it says action will be taken against people who "demonstrate unwillingness to address behaviour which has caused offence, harm or distress to another member or members; or has threatened the safety of the Hackspace". I would suggest amalgamation with the existing rules where possible.

There isn't really any mention of the RFID approach we'll be using in the 2.5 plan, and while that will happen before the end of the consultation period on the rules as a whole, there have been some conversations taking place that are perhaps better here.

So...copying the jist (key points from the Slack chat in #Networking today (2016-01-06 around 13:00ish)):

• The new doors downstairs will all have break-to-exit switches, and there will of course be a manual override for when things go wrong
• they will be swipe in and swipe out
• so you can't open the door if you have your card in the laser cutter / mill / lathe ......
• you shouldnt be leaving a tool unattended anyway
• what if someone's visitor wants to visit the toilet?
• if they are your guest you accompany them
• people will just prop open doors
• No, they wont, Because if they do, they will, I expect, suffer some sort of disciplinary action.
• can laser cuts be interrupted and resumed?
• Yes, but Your card still has to be on the machine for that to work though
• A change will be going into HMS to allow people to have more than one card
• So if you need to, you can leave your card on the laser cutter (with it paused, of course) and use your other card to get to the toilet
• Everyone with access to a RFID controlled tool will ​_need_​ a second card
• Everyone will also be migrated to white cards anyway in the near future
• so if a friend wants to go out for a pizza you have to "see" them to the door?
• if they want to wander around the space themselves, they need to come in on a Wednesday, get a tour and become a member
• That brings up an interesting question - who is responsible for visitors on a Wednesday night?
• They're often walking around unattended. If we don't want individual friends of members going to the loo, how do we justify having the general public all over the place?
• I think the general consensus was that we are a space are responsible for people on open nights, and I ​_suppose_​????? that means the responsible trustee is the eventual responsible person

As I understand it, a grievance is when a member makes a complaint to the Hackspace which may or may not be about another member. Normally the grievance procedure would explain who will look into the complaint, how long it might take and what kinds of actions may result from the investigation. It might also say if the person can appeal to an independent person if they are unhappy about the handling or outcome of the grievance. Suitable outcomes to a grievance might be an apology, a mediation meeting, rule changes, new signage or the commencement of a disciplinary investigation, for example.

On the other hand, if the Trustees decide that they should take action against a member (which could arise because of a grievance, or for other reasons - such as just noticing that someone is breaking the rules) then that would be disciplinary action and would normally follow a different route, the displinary procedure. This would set out who would investigate, in what timescales and what action could be taken (informal warning, warning, temporary ban, permanent exclusion etc). Again, it may be that there could be an appeal process.

The current grievance procedure seems to conflate these two procedures and I propose that we create a fresh disciplinary procedure and trim back the grievance procedure to specifically cover grievances.

I haven't had much involvement with these types of procedure so the above may not be 100% accurate, but I think it is the way these policies are normally done. If anyone has experience in this area then please do chip in and say if I'm getting things wrong.