7pm, Classroom. … a week from now.
Two Agenda Items:
1 - to vote in “Proposal 1” as described here, and to have it added to the laser-cutter wiki page as sanctioned digifab process for becoming a “laser supervisor”:
2 - to vote in “Proposal 2” as described here, and to have it added to the laser-cutter wiki page, officially. ( ie approving Buzz to be added to the list of Laser supervisors ).
discussion on these items has occurred here: Digi fab meeting 27/12/2016 @ 10pm
Currently causes can’t vote on anything other than expenditure of their cause budget, but I am working on a rewording of the cause rules to allow causes to define processes and expectations for inductions, tool use, maintenance lockouts and general expectations of members using the area.
The one thing I’d add to the supervisor process that you’ve specified in the other thread is a required number of hours of supervised use like you would with a drivers license.
This way the person wishing to be a supervisor will hopefully have been exposed to regular and even some irregular faults that will come up in general use as we can’t adequately simulate all the game-over faults that can happen with the laser cutter.
I’d also suggest that should any preventable faults with the laser cutter occur under any supervisors watch they lose their right to supervise and would need to complete the hours again. This includes but is not limited to fires, water in the laser cutter and supervised users not cleaning the machine adequately.
I’ve finally had a chance to read and digest the proposed supervisor rules, and it’s very well written, though I’d like to suggest a few additions. It’s been a long day for me so none of this is worded properly or anywhere near as concisely as I would like, so please bare with me while I braindump. FWIW, I’m working on the premise that these rules may be modified & adapted in the future to other tools too, since there’s no point reinventing the wheel with the Hulk etc. 
Supervisors must pass a short 10-ish question test. The purpose of this test is not to measure competency, but to save us time to make sure someone has a bare minimum of knowledge about where all the more in-depth knowledge is located. Eg the wiki, the Smoothieboard website’s FAQ, the manuals for some of our hardware, basic knowledge about the proper names for parts of a laser cutter, that you know how to search the forums and slack for information, etc. At the end of it you’ve got a list of 10-ish places that contain important information, and making sure someone knows the basics puts us on the same page and hopefully save us time making sure someone knows how our specific tool works compared to other similar tools they may have used in the past. This isn’t designed to be hard, it would be open-book, the questions themselves will provide hints as to where you can find the relevant information, assistance can be given to people if they ask (depending on the question), multiple attempts can be had, etc. I’ve got a draft of this I’ve knocked together, and would love some feedback (just keep in mind it’s supposed to be generic and is testing that someone knows where information is found, not that someone is competent). This could theoretically replace item number 4 on the proposal, as the only way to pass the test in its current version involves being a member in the relevant slack channel.
To encourage continuous improvement, discourage project stalling and also discourage cookie licking, I’d like for there to be a quick review summary of the tool plus who are the current supervisors every 3-6 months. This can be informal and done by the cause itself but it’s a chance to sit down and re-evaluate the tool’s state, update the Trello list, prioritise what still needs to happen, and identify if any of the supervisors are currently incapable of continuing to improve this tool due to other obligations getting in the way so another person can step in. Life happens and there’s nothing wrong with that, it’s unavoidable. We don’t want to get into a “too many cooks” situation by just adding extra supervisors, so this will give us a chance to check if people can either continue contributing or if it would be better for them to make way for someone else.
In relation to the above, to avoid a “too many cooks” situation, the cause and/or the supervisors themselves should identify a maximum number of supervisors that a tool can have in its current state of operation, perhaps as a percentage of the current number of cause members. This should also be revised every 3-6 months depending on the tool’s current state, the cause’s opinions, the availability and opinions of the current supervisors, etc. This is not intended to try and lock people out, but as the proposal is currently written there is no limits to the number of people that could attempt to become supervisors, and having 20 supervisors would be an absolute nightmare & the machine’s progress would likely stall or even go backwards due to communication limits.
Supervisor positions are intended for people who are actively working to improve the tool so it can be more readily available to all members. Supervisor positions are not intended for people who just want to use the tool themselves without contributing to its improvement, as that will like just end up slowing down the other supervisors and becoming a supervisor should not be considered a shortcut around being inducted. Depending on the tool and its state, supervisor positions may or may not be for people who intend to only supervise others using the tool without contributing to its continued development - this is up to the existing supervisors as if they think that will or won’t slow down their efforts to improve the tool. (At this point in time it is my opinion that the laser cutter couldn’t handle a supervisor who intended to only cut stuff for other members without helping with the maintenance as the other supervisors would be spending too much time cleaning and recalibrating the machine, not improving it, but this is just my personal opinion )
I have merged the proposal 1, as well as a couple of Mike’s suggestions ( 10 questions, and regular review of positions ) into the wiki page for vote:
http://wiki.hsbne.org/tools/lasercutter
Minutes from tonights Digifab Cause meeting:
Quorum reached? Yes. 10 cause members. Luke H, David B, Mike Ando, Rosa T, James C, Jaimyn M, Blair C, Aaron B, Michael/Doc, Niklas C. thank you all for coming.
1 - Buzz/Nog note that causes currently can not enforce rules within their cause and can only write “guidelines”, so the lasercutter wiki document is not enforcable at present, but may become that in the future.
2 - Buzz tried to lead a discussion on the pros of the proposed changes. Many people have heated opinions about this, and a number of worthy suggestion/s and process change ideas were made. It seems that most suggestions were either unworkable for our current situation ( such as getting another laser cutter ), or were not fully formed in such a way as they could be added to the proposed document in a way that improves it.
3 - Because there was much discussion, it was initially unclear where many people stood on the draft/proposal, so Buzz/Luke asked for a non-binding show-of-hands first, so that we could get a sense of how many people support the general idea having a documented process for becoming a laser supervisor.
4 - non-binding vote by show-of-hands was then taken. result: 8/10 ( all those present at that time) voted in support of the “general” direction of the proposal. ( but a number think it needs more fleshing out). The 2 who were taken as abstaining were the two members ( James and Mike ) had left the room prior to this point, so their non-binding-vote was counted as ‘abstain’. ( 8 in favour, 2 abstains , zero against ).
5 - After the general show-of-hands, we agreed that a binding vote should be delayed to give people more time to have input, read the proposed changes again, and make further suggestions on how to make it better, etc. Constructive input is welcome from anyone who wants to help improve the processes.
6 - meeting closed without further action/s. Revised/Improved document will be voted on at the next Digifab Cause Meeting, which has not yet been scheduled.