New member manual

[Tim Hardy]

This thread is primarily to discuss what the contents of a new member manual should be, an idea arising from a long discussion about membership of the space. 

Jonty:

> Ideally a new member manual that can be issued along with this email. 
  A PDF is fine, but hard-copies in the space would be lovely. 
  Nottinghack have a beautiful one if you'd like an example of this. 

A copy of The Nottinghack manual is here: http://wiki.nottinghack.org.uk/images/9/96/Nottingham-hackspace-manual-web-Nov2011.pdf .

Akki also started this ages ago with the aim that it'd be on an A4 sheet of paper, easily printable from lovelace with a link on the desktop. 

 http://wiki.london.hackspace.org.uk/view/New_members_guide

If you felt lost when you first joined please use this thread to point out what you found most confusing at first (eg did you know about registering an RFID card).

If you have very strong feelings about what needs to be in the document, please jump in as well.

[Akki]

I had an idea about this the other week, partly to try to tailor to different types of individuals in the space. Unfortunately it involves a little more work and may end up being a little more confusing...

Basically, we may need mini guides for each part of the space... Not hugely specific but if someone is interested in the workshop, you can give a more detailed run-down of how the workshop works (wood pile, cleaning up after yourself, using tools and putting them back, 3 in 1 and laser cutter trainings etc) vs another guide for the electronics bench (wire and components, soldering irons, heat gun, bring your own breadboard etc). I don't know if there's anything else in the space that'd need a specific mini guide though.

I realise this means there'd actually be more like 3 guides(basic, workshop & electronics) which may be confusing but it also means if someone is specifically interested in one thing but not the other (or is interested in both) they can get a broad spectrum or a narrow spectrum of useful information.


~Akki

[Martin (Crypt)]

Definately a good idea to do this.  I think possibly what we could do is have a small printed booklet with the basics, and cover most of the stuff new members need (was thinking we could send this through the post, but would be work for people posting it out.  I'd be willing to help on this if its what we decide) then have a larger guide available online, or possibly a single printed copy in the space.  That way we're covering everything in a larger book that people can refer to, without forcing people to read huge ammounts of text on equipment they may never use.

I'll add a few bits to the wiki anyway for the guide.

[Tim Hardy]

Thanks everyone! :) We can do most of the initial data gathering on the wiki and in this thread before shaping it into one or many booklets

Just pasting this in from the other thread since it might be good to include a definition of member in the final document

As an aside it may be worth reiterating what a 'member' is in 
hackspace terms for those people who may not be aware. 
You are NOT (necessarily) a member if: 
* You are on this mailing list 
* You have signed up for a wiki account/put your profile on the members page 
* You have been on the IRC channel 
* You have a hackspace.org.uk account 
* You have been trained on the laser cutter 
* You turn up every week 
* You pay money to other groups (biohacking?) 
* You really helped someone/the space out on $thing 
* And many other things... 
You are ONLY a member if: 
* You have a hackspace.org.uk account and have set up a standing order 
with the correct reference and logging into that site shows your 
payments and your name appears in that members list 
This isn't meant to pick on anyone. It is purely for clarity. 
Cheers, 
Paul 

On Wednesday, 24 October 2012 20:16:44 UTC+1, Tim Hardy wrote:

[Tim Hardy]

Also from Oskar:

Just a quick note - I've put together https://github.com/oskarpearson/lhs-checklists as an attempt to try and come up with a way of generating readable HTML, which can then be PDFed via a standard browser print-to-pdf. It's built for checklists though, so formatting isn't great for standard text. You can see output here: http://www.deckle.co.za/LHS-Laser-Cutter-Checklist.pdf
I have based it on a version at https://github.com/oskarpearson/squid-users-guide which includes a build system that uses ruby templates, so as to allow many different documents. http://www.deckle.co.za/squid-users-guide/terminology-and-technologies.html is an example there. I can expand the checklist repository to have a similar structure if you want, and add support for non-checklist material. But it presupposes HTML + github access.
Note: this is just bikeshedding - you can use whatever way you want that makes life easy. By no means is "my" method "the LHS way". I just hate the way that wiki articles print :)

Note that in March Paul Randle-Jolliffe and Hanna Wybranska started putting something together - search for "OK here is a draft members manual" here for the word doc link:
        https://groups.google.com/forum/?hl=en&fromgroups=#!searchin/london-hack-space/wiki$20guide/london-hack-space/si2kdqFdaBo/o8UN3MCLaKkJ

[Tim Hardy]

I have skimmed through Paul Randle-Jolliffe and Hanna Wybranska's excellent manual (cheers Oskar for the link) -

https://docs.google.com/viewer?a=v&pid=forums&srcid=MDk2MzA1NDg0MDM3MDU0MDUyODIBMDQ0NzQ3OTU3MDk0MjI5ODg2MzABX2ZQaUZHYWhtaFVKATQBAXYy

It has a few TODOs in it that need to be completed but other than that I think it is great. This is a really excellent piece of work and it's a shame this was dropped. I get the impression from the thread that the authors were waiting for endorsement from more established members before following through on the project. 

21 pages is a good length for something this comprehensive given that much of that content (directions to the space, useful QR codes) can be skimmed on a first read but are  useful as a reference. There's also a shorter edited version in the original thread that I haven't read yet by Sam Kelly.

My vote would be to fill the TODOs, add a version number, print it, bind it cheaply, leave a copy in the space, direct new members to it and then constantly revise it. 

There's no need to wait for approval or worry about formatting or design the perfect CMS solution. These are holding it back. We're a hackspace yet we're doing "big design upfront" on our manual! Let's just get this out there! Publish, revise, repeat.

I have some time free this coming weekend so I'll go through it properly then.

Paul and Hanna, Sam, thanks! 

[tom]

oh god we cant show that to people, there are people with ECDL courses under their belt that can format better text than that.

Given that we *actually want people to read this* i think coming to some consensus on its presentation is important. Copying and pasting the wiki into a word doc, printing and binding it then throwing it onto a wall will help no one.

a lot of that info is redundant, why would someone who's in the space need to know how to get there? 

[Sam Kelly]

Right, let me take another look at the condensed version I did, and
format it up. Or even better, someone else take a look at the text and
give me a re-edited version to format nicely.

--
Sam Kelly, http://www.eithin.co.uk/

That's it. We're not messing around anymore, we're buying a bigger
dictionary. - Tibor Fischer, The Thought Gang.

[Akki]

That incredibly long, biased, unreadable version of the wiki that was put together into a pdf is the whole reason why I wanted to do a condensed, A4 sheet version.

I will continue to be against QR codes as I do not have a phone that reads them. K.I.S.S. - Keep It Simple, Stupid.

I agree it's been held back but not over worry with formatting. It's about getting it right, keeping it simple and readable and most importantly useable. If we're just going to print out the wiki... Print out the wiki? It's not very useful in printed form, though.

Also I have offered before to make/bind this formally once written in bright neon pink book cloth I've got especially for the job to make it obvious in the Space.

~Akki

[Tim Storey]

put it into LaTex for non existent deities sake…
\t

[Tim Hardy]

Thanks Sam. That's brilliant.

Tom, I don't think you're being helpful. It's better a badly formatted doc than no doc at all.

We have members of long duration getting warnings for breaking the rules they're implicitly claiming not to have understood in one active thread and people moaning about noobs not knowing the rules in another.

I worked in book and magazine publishing for over a decade before I became a softwre engineer and I understand the importance of formatting and layout - but I also understand that when a project has stalled for seven months then we need to stop being so precious and get something out the door.

If you feel so strongly about the formatting, please go ahead and reformat it and we'll release an updated version with your changes.

[Akki]

The whole "noobs not reading the rules" is the reason why I printed out 7 copies of the rules on A3 paper and put them all around the hackspace, including the toilets.

Pieces of paper do not solve all complex social problems.

~Akki

[David Murphy]

On Tue, Oct 30, 2012 at 12:06 PM, tom <bollo...@gmail.com> wrote:

oh god we cant show that to people, there are people with ECDL courses under their belt that can format better text than that.

 

may I refer you to rule 4. 

Thanks Tim for putting it together though I have to agree with akki that we need a mico A4 version as it's probably a bit long.

[David Murphy]

The whole "noobs not reading the rules" is the reason why I printed out 7 copies of the rules on A3 paper and put them all around the hackspace, including the toilets.

it's where I read the rules. actually a good place for that kind of info.

[Tim Hardy]

Akki, what do you want a new members manual to achieve?

[Jonty Wareing]

I disagree, Tom's point is completely valid. The last thing we want is
to write a wall of text that every member tl;dr's.

Getting it written and getting it distributed are different things. Yes
we shouldn't let it bitrot, but we do actually need to make sure this
is something people will actually consume otherwise we're back to square
one.

I'll take the form of editor-jonty soon and attack it. I might bung this
into an etherpad instance, as I find it aides collaboration when editing
large documents.

--jonty

----- Original Message -----
> From: "Tim Hardy" <johnny...@gmail.com>
> To: london-h...@googlegroups.com
> Sent: Tuesday, 30 October, 2012 12:21:21 PM
> Subject: Re: [london-hack-space] Re: New member manual

> Thanks Sam. That's brilliant.
>
>
> Tom, I don't think you're being helpful. It's better a badly formatted
> doc than no doc at all.
>
>
> We have members of long duration getting warnings for breaking the
> rules they're implicitly claiming not to have understood in one active
> thread and people moaning about noobs not knowing the rules in
> another.
>
>
> I worked in book and magazine publishing for over a decade before I
> became a softwre engineer and I understand the importance of
> formatting and layout - but I also understand that when a project has
> stalled for seven months then we need to stop being so precious and
> get something out the door.
>
>
>
>
> If you feel so strongly about the formatting, please go ahead and
> reformat it and we'll release an updated version with your changes.
>
>
>
>
>
>
>
>
>
> On Tuesday, October 30, 2012 12:08:19 PM UTC, Sam Kelly wrote:
>
> Right, let me take another look at the condensed version I did, and
> format it up. Or even better, someone else take a look at the text and
> give me a re-edited version to format nicely.
>

> On Tue, Oct 30, 2012 at 12:06 PM, tom < bollo...@gmail.com > wrote:
> > oh god we cant show that to people, there are people with ECDL
> > courses under
> > their belt that can format better text than that.

[Tim Reynolds]

I think the assertion that any mess is better than nothing is dangerous. Tl;dr is a meme for a reason. People wot read a printed out wiki. It needs to be accessible 

[tim_n]

Things I wanted to know as a member on arrival was: where the parking spaces and passes were, where the donation pots were, what rooms were what and what the rules were, where could I stick a bike (that was later) and stuff like wifi access, where to find more (like the wiki)

Might be a good idea to have a few often found friendly faces on a board with names to ask questions, though that'd be better on a wall do it can be changed and the location on the members page.

I like QR codes, but that could link to an online version of the document so if they run out, you can grab a copy on your phone.

[Akki]

People stop getting put off the hackspace or getting confused. We've had cases where people have verbally given out wrong information which has caused a heap of misunderstandings and ill-feeling in the hackspace. If there's a hackspace manual, people can look it up and refer to it rather than believe random people who may not understand the rules correctly... or, god forbid, have their own version of the rules that is not correct or that is detrimental to hackspace. Like bending the rules on leaving items, bringing in bikes or sleeping.

Yeah, I said it. Deal with it. 8)

[Tim Hardy]

My point was if we get a TLDR reaction, we can revise and make it shorter but as long as my threat to stick it up as it is gets people moving then I'm totally happy to be overruled and outvoted. /me gladly passes editor hat to Jonty :)

tim_n, thank you! Knowing what people want to know when they arrive is exactly what we need to make prominent in any document to make it helpful.

[Tim Hardy]

Thanks Akki :)

I had been imagining a new members manual as a friendly, detailed, comprehensive overview that helps new people orientate themselves quickly in an unfamiliar environment.

But this kind of suggests that "the rules" aren't really a comprehensive record of the rules doesn't it? Perhaps a new members manual is not the answer to that particular problem. 

[Akki]

Slightly off-topic now but the rules need to be adhered to and enforced. No ifs, ands or buts. Or else they are utterly worthless.

Orienteering can be left to A4 sheet. The manual was always envisioned to be a hefty tome.

[Oskar Pearson]

Hi All

> I think the assertion that any mess is better than nothing is dangerous. Tl;dr is a meme for a reason. People wot read a printed out wiki. It needs to be accessible

I previously sent a mail to Tim Hardy privately about this, but it seems that writing things has now moved to other people. I'm thus resorting to broadcasting my suggestions to the list.

The core of my mail is to be prescriptive, rather than descriptive. The examples I give are for demonstration purposes, rather than necessarily a definite structure... but I think it sort of works.


The mail I sent to Tim Hardy:
>
> My ideas are as follows:
>
> 1) There should be a "your responsibilities to the space" section.
>
> 2) The document should be prescriptive, not descriptive. So lots of "do" and "don't" sections, but not much "hey, like be cool and awesome, and you should think about, like, joining the community.. but it's all like open and you can do just whatever you want, but people will [** let's just say 'freak out' here **] if you do whatever you want".
>
> Instead, as a random example:
>
> Welcome. You are now a member.
>
> Now you have to do this:
> a) read the rules and your responsibilities and "when you are at the space" sections. If you don't agree, you can't come to the space.
> b) join the mailing list by going to this url: quicklink
> c) register on the wiki by going to this url: quicklink.
> d) Add a page to the wiki about yourself by clicking here: quicklink
> e) If you "do IRC", go here ....
> f) Go to the space, apologise to person that lets you in, and follow this process to register your RFID card as per this process: quicklink
>
> Rules:
> .... hackspace rules ...
>
> Responsibilities:
> a) ... be awesome ...
> b) ... be responsible for the space ...
>
>
> When you are at the space:
> a) Clean up after yourself, nobody else does, and we don't have cleaners.
> b) Vacuuming is your responsibility.
> c) Rubbish bins need to be emptied by you. Do so before you leave: quicklink
> d)
>
>
> Problems?
> a) Mail the list
> b) ...
> c) Grievance Procedure: ...
> d) Failure of all the above? Contact the trustees.
>


Responding to his section about gripes:

>
> Gripes:
> I think the biggest bit that's still difficult for me is to grab people and get them to train me.. but I've not been pushing hard, honestly. It'd be great if there was a schedule that I could fit into, rather than have to drive. The laser cutter is good that way, but not things like the 3-in-1.



Oskar

[Sam Kelly]

Right, further-trimmed & formatted version attached. It has
Welcome/Access/Rules/Social Evenings/Governance/Events/Keeping the
Hackspace in Shape/QR codes, and it fits onto 9 sides of A4 or will
(if we increase the font to 13pt) two-up onto a small A5 booklet.

Further edits/suggestions (including "stop wasting your time") entirely welcome.

Sam

[Dave Ingram]

Looking good, although I would personally like a vector version of the Hackspace logo at the top instead. That may be an artefact of the particular PDF conversion process you're using, however.

I'm considering throwing something together in LaTeX. I have an idea in my head of how I'd like it to look, and it even involves colours! Should I bother?


D

[Sam Kelly]

Do!

I'm just using LibreOffice for this, and the logo is the one included
originally; I'm having trouble getting the github version working with
it, but I'll have another go later.

[Russ Garrett]

On 30 October 2012 13:48, Dave Ingram <da...@dmi.me.uk> wrote:
> I'm considering throwing something together in LaTeX. I have an idea in my
> head of how I'd like it to look, and it even involves colours! Should I
> bother?

If you have the ability to make it look not massively formal in LaTeX
then that would be awesome. The big advantage of LaTeX is that it's
easy to manage in git.

--
Russ Garrett
ru...@garrett.co.uk

[Dave Ingram]

That's my plan -- I've got memories (and hard copies) of my uni's student handbook in mind. I'll put something together this week (unless there are work catastrophes etc) and see how far I get.

I use LaTeX for presentations precisely because I can put the sources into git and keep track of the tiny things I change that make it all entirely different.


D

[Tim Hardy]

@Oskar, sorry I missed that originally since it was below a quoted section otherwise would have copied it into the thread already.

@Sam, love it! I can't edit it because it's a pdf but my minor suggestions would be 

* add the url for the wiki since it is possible new joiners won't know where to find it.

* add "(See rule 17 below)" after "Please don't keep your bike in the space unless you're working on it."

* change each ampersand to the word and in the introduction (this is a personal preference: feel free to ignore it)

@everyone especially Akki, Tom, Jonty (since you weren't entirely happy with original doc), are you happy with Dave going ahead and using Sam's text without further major edits? (don't want Dave to start working on something only to have the text revised/rejected)

@Dave, sounds like a great plan! If people are happy with the text, do it! 

Perhaps when you have done this you or someone else who knows LaTeX could add a very brief page to the wiki with a link to the sources for the manual and recommending any good tools to use for editing/updating LaTeX along with a link to a reference for the markup. This will make it easier for others to help maintain it.

On Tuesday, October 30, 2012 2:10:15 PM UTC, Dave (DMI) Ingram wrote:

On 30/10/12 14:03, Russ Garrett wrote:

[Ulisses Pinto]

There's something else that I think would be useful to have in the manual: it's a plan of the hackspace site, showing the location of the main tools, or anything else that might be useful.

[Dave Ingram]

On 30/10/12 14:44, Tim Hardy wrote:

@everyone especially Akki, Tom, Jonty (since you weren't entirely happy with original doc), are you happy with Dave going ahead and using Sam's text without further major edits? (don't want Dave to start working on something only to have the text revised/rejected)

I'm happy for it to be a work in progress, as long as I know what's changed. My first plan is to use the current version of the PDF as a base, to get some formatting together; after that, we can replace it wholesale, as necessary.

@Dave, sounds like a great plan! If people are happy with the text, do it!

Perhaps when you have done this you or someone else who knows LaTeX could add a very brief page to the wiki with a link to the sources for the manual and recommending any good tools to use for editing/updating LaTeX along with a link to a reference for the markup. This will make it easier for others to help maintain it.

I plan on putting the LaTeX sources in a repo under the London Hackspace github account (if someone could give me access?), so that they're available to all. I also intend on documenting it as I go, to try to make it as understandable as possible. I guess there's no reason I can't put a brief primer in there too.


D

[Evan Davey]

I'd recommend http://johnmacfarlane.net/pandoc/. That way the text can be kept in plain text as Markdown which is much friendly to edit than latex directly. I use this framework for creating all my business presentations, reports and I'm now working on a brochure (each have custom latex templates). The other advantage is that you can easily convert to other formats eg. HTML

[Dave Ingram]

On 30/10/12 23:07, Evan Davey wrote:
> I'd recommend http://johnmacfarlane.net/pandoc/. That way the text can be kept in plain text as Markdown which is much friendly to edit than latex directly. I use this framework for creating all my business presentations, reports and I'm now working on a brochure (each have custom latex templates). The other advantage is that you can easily convert to other formats eg. HTML

I'll have to look into how much control Pandoc gives you over the
formatting, as I will want more than just basic text (e.g. vector
images, in-LaTeX QR code generation, image floats, etc). But it might be
an interesting start.


D

[Evan Davey]

Images are handled fine in normal markdown and pandoc normally wraps them up nicely in the latex output.  Usually, I convert from markdown to tex which just outputs the content which I then include in a wrapper file that has the main document structure e.g.: class etc. Additionally, I normally do stuff with the 'meta' data of my source files eg: title, author etc. (which requires using multimarkdown rather than pandoc first due to the better meta handling).

My approach has been to build anything complex into the latex templates (manipulating what pandoc outputs) but it is also possible to intersperse latex and plain text in the source if necessary - e.g.: calling a QR code generation macro

[tom]

Congratulations, we have achieved peak-bikeshed!

[Jonty Wareing]

Lies, we haven't discussed the colour yet. (Blue please, I would like
it to look like a Haynes manual)

--jonty

----- Original Message -----
> From: "tom" <bollo...@gmail.com>
> To: london-h...@googlegroups.com
> Sent: Thursday, 1 November, 2012 11:11:46 AM
> Subject: Re: [london-hack-space] Re: New member manual

> Congratulations, we have achieved peak-bikeshed!
>
> On Thursday, November 1, 2012 11:09:09 AM UTC, Evan Davey wrote:
>
> Images are handled fine in normal markdown and pandoc normally wraps
> them up nicely in the latex output. Usually, I convert from markdown
> to tex which just outputs the content which I then include in a
> wrapper file that has the main document structure e.g.: class etc.
> Additionally, I normally do stuff with the 'meta' data of my source
> files eg: title, author etc. (which requires using multimarkdown
> rather than pandoc first due to the better meta handling).
>
>
> My approach has been to build anything complex into the latex
> templates (manipulating what pandoc outputs) but it is also possible
> to intersperse latex and plain text in the source if necessary - e.g.:
> calling a QR code generation macro
>
>
>
>
>
>
>
> On Wednesday, 31 October 2012 08:10:47 UTC, Dave (DMI) Ingram wrote:
>
> On 30/10/12 23:07, Evan Davey wrote:

> > I'd recommend http://johnmacfarlane.net/pandoc/ . That way the text

[Nigel Worsley]

> we haven't discussed the colour yet. (Blue please

Yes, but WHICH blue?

I favour Pantone 286.

Nigle

[cepm...@yahoo.co.uk]

Dayglo orange cover for maximum visibility. And an arduino controlled
1.5khz interrupted locating tone for the braille/audiobook edition. Any
volunteers to translate into Bangladeshi/Klingon/Togalog??

On Thu, 01 Nov 2012 11:27:21 -0000, Jonty Wareing <jo...@jonty.co.uk>
wrote:

> Lies, we haven't discussed the colour yet. (Blue please, I would like
> it to look like a Haynes manual)
>
> --jonty
>
> ----- Original Message -----
>> From: "tom" <bollo...@gmail.com>
>> To: london-h...@googlegroups.com
>> Sent: Thursday, 1 November, 2012 11:11:46 AM
>> Subject: Re: [london-hack-space] Re: New member manual
>
>> Congratulations, we have achieved peak-bikeshed!

--
" et cognoscetis veritatem et veritas liberabit vos. "

[Tim Hardy]

I'm calling foul and I expect I'll get flamed for doing so.

This is all very amusing but why is it considered more acceptable to flood a thread with jokes than it is to discuss technical implementations?

I know all of you contribute enormously to the space - indeed Jonty co-founded it - but I am asking you to consider the impact of your contributions to this particular thread and project.

I don't think low profile members would get away with this. I don't see why high profile members should either.

"Bike shedding" is an in-joke. Complaining of it marks you out as part of the in-crowd. But surely the only possible real objection to "bike shedding" is that it gets in the way of work being done.

Dave has already agreed to mark up the text in LaTeX. Evan is suggesting another way of doing this that might be easier to maintain. This is not getting in the way of anything.

I don't know what impact your sarcasm will have on Evan but I am certain that anyone else who might want to contribute - especially a new person - will think twice about doing so if they're going to meet a response like this.

One of the purposes of the manual is to make the space more welcoming to people. 

Let's make a start by making this thread more welcoming to people who want to contribute.

[Dario]

To be honest Tim, the part I most enjoyed on this thread was the Pantone/Haynes manual jokes!

That aside I've already downloaded the manual draft and read it to my 7-year-old every evening... she's never fallen asleep faster! ;-)

Cheers
Dario

[Sam Kelly]

a) http://wiki.london.hackspace.org.uk/view/File:Haynes-style_manual_cover.jpeg

b) Could someone who is currently in the space please print out the
PDF I sent earlier in the thread, write "INTERIM" across the top with
a black marker, staple it, and put it up somewhere near the front
door?

c) Discussing new technical implementations WHICH ARE ACTUALLY
HAPPENING is awesome.

[Clare Greenhalgh]

Our Haynes maunal is GREEN!

Noko

x

[Tim Hardy]

Thanks Dario. We look forward to your suggested edits.

Awesome work Sam! I love it

[tom]

or an ikea instruction sheet?

[Dave Ingram]

The advantage of LaTeX is that we can create multiple templates so we can cater for ALL THE CHOICES.

"Welcome to London Hackspace! Choose your preferred style from our range of manuals!"


D

[Jonty Wareing]

> "Bike shedding" is an in-joke. Complaining of it marks you out as part
> of the in-crowd. But surely the only possible real objection to "bike
> shedding" is that it gets in the way of work being done.

Bikeshedding is not an in-joke, it is a well-understood term also known
as Parkinsons Law of Triviality. It originated in the 1950s, and is
commonly used in the software industry.

http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality

> This is all very amusing but why is it considered more acceptable to
> flood a thread with jokes than it is to discuss technical
> implementations?

Because the thread truly has become an absurd technical bikeshedding
discussion deviating from the matter at hand, which is getting the
content written and agreed on.

Once the content has actually been finalised it's highly likely that
one of the many designers in the space will take it and typeset/format
it beautifully. Having it in Latex is actually likely to hinder this,
and make contributing to it significantly more difficult for people who
are unfamiliar with *tex. Which is nearly everyone.

Obviously you took offense to it rather than taking me seriously, but
I actually have always wanted the hackspace new member manual to look
like a Haynes manual.

--jonty

[Morris]

Haynes +1

--
>
++++++++++[>+>+++>++
+++++>++++++++++<<<<
-]>>>+++++++.>++++++
+++++.+++..---------
.++++++++++.<<+++.<.

[Russ Garrett]

On 1 November 2012 13:06, Jonty Wareing <jo...@jonty.co.uk> wrote:

> Because the thread truly has become an absurd technical bikeshedding
> discussion deviating from the matter at hand, which is getting the
> content written and agreed on.

Perhaps, but the solution is not for everyone to pile on and bikeshed
it in a different way. Surely arguing about the colour is more absurd?

> Once the content has actually been finalised it's highly likely that
> one of the many designers in the space will take it and typeset/format
> it beautifully. Having it in Latex is actually likely to hinder this,
> and make contributing to it significantly more difficult for people who
> are unfamiliar with *tex. Which is nearly everyone.

Which is where Markdown is a good solution. It's very human-readable
and can be trivially converted to LaTeX using Pandoc if we need to.
It's easier to typeset it than a pile of unstructured text.

(I do have more of an opinion on this, but I'm not going to share it,
lest I be considered bikeshedding.)

--
Russ Garrett
ru...@garrett.co.uk

[Dave Ingram]

On 01/11/12 13:06, Jonty Wareing wrote:
> Once the content has actually been finalised it's highly likely that
> one of the many designers in the space will take it and typeset/format
> it beautifully. Having it in Latex is actually likely to hinder this,

I'm curious as to why this would be a hinderance? LaTeX is meant to help
typesetting. If creating a LaTeX version is going to be rejected, then I
won't bother carrying on with doing it.

> and make contributing to it significantly more difficult for people who
> are unfamiliar with *tex. Which is nearly everyone.

I don't know -- I'd argue that simple contributions don't become
significantly more difficult because it's possible to look through
what's already there and duplicate that. Plus, if the manual is in git,
then contributions can be accepted and tweaked as pull requests, and we
get to keep a history of how it has changed. This would be virtually
impossible with binary formats, and plain text isn't compatible with
typesetting.

How much more difficult would it be to contribute if it's typeset using
some other system? In fact, what other systems are there?


D

[Tim Hardy]

Haynes is a fantastic idea. At the least we can all agree on that. And I love Sam's implementation.

I'm not personally offended at all - I'm just pointing out what kind of a negative atmosphere this creates when those who are actively working on this project are mocked by people who have so far made no positive contribution.

I know the origins of the term. It is the act of complaining of bike-shedding that is an in-joke for the hackspace and the label is used to shut people up and close down discussion. Grandstanding by established members, however, is encouraged.

This is not helping what we all agree is the purpose:

>> getting the content written and agreed on.

We have a draft already - which some people have been very vocal about not liking but haven't actually contributed any alternative suggestions for wording or edits - and people working to design a layout while waiting for others to make positive suggestions towards how the document should be worded.

I also share your hesitation about the maintainability of LaTeX which is why I asked for a brief links to tools and references. However I'd rather see someone create a first draft with LaTeX than for no one to create anything at all. The suggestion of using Pandoc - dismissed as bike-shedding - is directly addressing your concern.

[Russ Garrett]

On 1 November 2012 13:32, Dave Ingram <da...@dmi.me.uk> wrote:
> I'm curious as to why this would be a hinderance? LaTeX is meant to help
> typesetting. If creating a LaTeX version is going to be rejected, then I
> won't bother carrying on with doing it.

Because most people don't know how to manipulate LaTeX. If a designer
volunteers their help to build a layout then it's likely they're going
to be doing it in InDesign.

I would strongly recommend starting with Markdown; I use Pandoc to
convert Markdown to PDFs via LaTeX quite extensively at my day job,
and it means that non-technical people are quite comfortable diving in
and editing the files.

--
Russ Garrett
ru...@garrett.co.uk

[Dave Ingram]

On 01/11/12 13:37, Russ Garrett wrote:
> On 1 November 2012 13:32, Dave Ingram <da...@dmi.me.uk> wrote:
>> I'm curious as to why this would be a hinderance? LaTeX is meant to help
>> typesetting. If creating a LaTeX version is going to be rejected, then I
>> won't bother carrying on with doing it.
> Because most people don't know how to manipulate LaTeX. If a designer
> volunteers their help to build a layout then it's likely they're going
> to be doing it in InDesign.

I think that this would introduce a barrier to people contributing. Only
people who have InDesign can make any changes, and it's not a free
product. LaTeX wouldn't necessarily give the same "perfectly-designed"
output, but because it's just marked-up text I think it would encourage
people to suggest changes or improvements, and even write them.

> I would strongly recommend starting with Markdown; I use Pandoc to
> convert Markdown to PDFs via LaTeX quite extensively at my day job,
> and it means that non-technical people are quite comfortable diving in
> and editing the files.

I have no objection to using Markdown (or a superset thereof) for the
majority of the document, but there will be cases where more complex
things are required. I'd also prefer to start with pure LaTeX until I
have some idea of how it will look, and then add a Pandoc-powered
conversion step later.

Anyway, these are just my personal opinions -- I have no experience with
doing this sort of thing in any professional capacity. I'm not trying to
start a flamewar, and I'm not trying to block anything. If there is a
better solution that looks good and also involves me doing no work, then
I'm more than happy. I just want to make sure that we get something that
looks better than a standard word processor can provide, which people
can easily contribute to and which we could share with other
hackerspaces. Being able to track its history and evolution is a bonus.


D

[Russ Garrett]

On 1 November 2012 13:45, Dave Ingram <da...@dmi.me.uk> wrote:
> I'd also prefer to start with pure LaTeX until I have some
> idea of how it will look, and then add a Pandoc-powered conversion step
> later.

Actually I've just realised that you can use pandoc to convert TeX to
Markdown, so go nuts.

--
Russ Garrett
ru...@garrett.co.uk

[cepm...@yahoo.co.uk]

I agree with Jonty. The thread seems to have been turned into another
endless discussion of more and more complicated ways of acheiving what
should be a very simple task. The Dayglo cover was a serious idea for the
copy in the space itself, it would be very difficult too lose and the same
folder could be used to hold other essential data (local pizza menus
etc.)that are outside the remit of the wiki.


On Thu, 01 Nov 2012 13:06:55 -0000, Jonty Wareing <jo...@jonty.co.uk>
wrote:

[Tim Hardy]

Awesome, thanks Dave, Russ. That's the bulk of the implementation discussion done then.

Now for content. 

>> I'll take the form of editor-jonty soon and attack it. I might bung this

into an etherpad instance, as I find it aides collaboration when editing
large documents.

Etherpad is no longer hosted so I'm assuming you want to host your own. 

Since this takes time and I know you're busy, is there any reason why we can't just turn it into a shared google doc?

[Russ Garrett]

On 1 November 2012 13:59, Tim Hardy <johnny...@gmail.com> wrote:
> Etherpad is no longer hosted so I'm assuming you want to host your own.

http://piratepad.net/

--
Russ Garrett
ru...@garrett.co.uk

[Tim Hardy]

Cheers!

I've just copied and pasted Sam's text (minus illustrations) into a piratepad here:

http://piratepad.net/740SSaXpn3

Jonty, you can cross that one off the todo list :)

My lunch break is now over so I can't add anything more for now. 

[Ciarán Mooney]

Hi,

To the formatting team.

After having a read of the Piratepad (http://piratepad.net/740SSaXpn3)
instance of the text it's become apparent that the phrase "on the
wiki" and the like is a common resolution to a point raised.

I seem to remember that in the past people did not always find the
relevant information on the wiki (lasercutter info if I remember
correctly.)

Unfortunately the text-only nature of Piratepad doesn't allow me to
put footnotes in, but may I suggest that a little superscript is put
in at appropriate times, along with a footnote with either the full
URL or if that is too cumbersome some shortened URL.

Cheers,

Ciarán

[Tim Hardy]

Good point, Ciarán. Agreed. Thanks for all your edits.

Just had a quick stab at editing. Thanks to Ciarán, Crypt and Tom for their edits and suggestions and anyone else who wasn't logged in when I looked so I don't know your username.

I've rewritten the introduction from the perspective that the reader will either have just joined or is about to join the hackspace. Hopefully it flows a little better now too.

I've moved the rules. They're now immediately after the introduction.

I've cut back the information on events and Tuesday nights based on suggestions from Crypt.

I've incorporated Tom's changes making two issues prominent that have been discussed a lot recently: 

* non-members are encouraged to visit on Tuesdays but welcome at other times (although people might be too busy for tours) 

* people must not leave bikes in the space.

There's a bit at the end, "Keeping the Hackspace in Shape" which is important but risks making the hackspace look like a place of drudgery. 

I think it definitely should stay in but could anyone with photoshop/Gimp skills mock up a quick ""Ask not, what your hackspace can do for you. Ask what, you can do for your hackspace" jpg or something similar to make it seem a little less onerous? 

[Tim Hardy]

tl;dr 

Artag has cleaned up the "Keeping the Hackspace in Shape" section so it reads much better now. Thanks!

Latest revision here: http://piratepad.net/740SSaXpn3 

Lot of questions for people follow:

Akki, I think the current version meets what you said you wanted from a new member's manual but it needs a bit more. You wrote:

>>> Basically, we may need mini guides for each part of the space... Not hugely specific but if someone is interested in the workshop, you can give a more detailed run-down of how the workshop works (wood pile, cleaning up after yourself, using tools and putting them back, 3 in 1 and laser cutter trainings etc) vs another guide for the electronics bench (wire and components, soldering irons, heat gun, bring your own breadboard etc). I don't know if there's anything else in the space that'd need a specific mini guide though. 

I really like this idea. Any chance you could write a very brief section about workshop and electronics bench (using the other sections as a guide to length) for now? A full mini guide would be a separate project perhaps.

Oskar, you suggested something like:

Welcome. You are now a member.
>
>       Now you have to do this:
>               a) read the rules and your responsibilities and "when you are at the space" sections. If you don't agree, you can't come to the space.
>               b) join the mailing list by going to this url: quicklink
>               c) register on the wiki by going to this url: quicklink.
>               d) Add a page to the wiki about yourself by clicking here: quicklink
>               e) If you "do IRC", go here ....
>               f) Go to the space, apologise to person that lets you in, and follow this process to register your RFID card as per this process: quicklink

This is a great idea. Would you like to stick this immediately after the rules? Perhaps title it "You've Joined, What now?" then change the first words of (a) to "make sure you have read the rules and your ...." Thanks!

Dario, we have a new bed-time red for your seven year old ;) Sorry if I seemed aggressive earlier - I was frustrated by people being negative but that is no excuse. Would you mind reading the revised version and if you don't feel confident about rewriting sections you find dull yourself please at least point them out or explain what it is in more detail that you find soporific so we can fix it. Please use the chat on the pirate pad. Cheers!

tim_n, you said

>> Things I wanted to know as a member on arrival was: where the parking spaces and passes were, where the donation pots were, what rooms were what and what the rules were, where could I stick a bike (that was later) and stuff like wifi access, where to find more (like the wiki)

We don't have anything about donation pots in the doc at present - do you want to add that? "What rooms were what" will hopefully be covered by Akki's suggestion. The rest is in there now.

Wifi access I think is best kept on notices in the space since passwords are liable to change but perhaps others disagree?

Tom, I assume you were trolltom on the PiratePad so thanks for your great suggestions. If that wasn't you, can you please read and let us know what you'd like changed.

Jonty, is the guide still tl;dr or is it beginning to match what you expected of a new members' guide? What do you think is missing.

everyone, I've re-read the Nottingham guide. Ours is very different which is no bad thing but maybe people might like to read both that and the latest draft and pipe up about anything they think we're missing.

Links for convenience: 

Nottingham pdf http://wiki.nottinghack.org.uk/images/9/96/Nottingham-hackspace-manual-web-Nov2011.pdf 

London PiratePad: http://piratepad.net/740SSaXpn3 

[Clare Greenhalgh]

I have a suggestion that people need to say they have read the rules and will keep to them before becoming members. This would then make it much easier to deal with people who are breaking the rules. It may seem a little harsh, but it will reduce the amount of bikeshedding to a huge degree....

If people don't say they agree to the rules then they cannot become members. If they agree to keep to them then we do not need to make sure the directors give warnings etc before enforcing them. 

I really want the Space to be somewhere people want to come, want to be members and also have members who care for the Space itself. This is the one thing that is currently lacking (I think).

The amount of storage space we have gets less as each member joins, and we need to be sure that people understand about the amount they are able to store there without getting previous permission (not just informing!) the list.

Maybe this diverts a little from the guide to the space, but I think if one is getting created (including the rules) then people need to stick to it.

Just an idea...

Noko

[Akki]

https://london.hackspace.org.uk/signup.php

"

Join the London Hackspace

To become a member of the London Hackspace, we need a few details from you.

By joining the London Hackspace you're becoming a member of London Hackspace Ltd., and you agree to be bound by our constitution. You also agree to follow the rules of the space."

[Jasper Wallace]

On Thu, 1 Nov 2012, Tim Hardy wrote:

>
> Wifi access I think is best kept on notices in the space since passwords are liable to change but perhaps others disagree?

The wifi password isn't likely to change anytime soon, but encouraging
people to read posters is no bad thing - they may contain more up to date
into than the handbook.

--
[http://pointless.net/] [0x2ECA0975]

[Tim Hardy]

Oskar, I've added the section you suggested while adding a new reference to Adopt a Spanner

Dave, is no one adds anything to this thread, please feel free to start marking it up in LaTeX when it is convenient for you to do so.

In the absence of any response from Dario, Akki, tim_n, Tom, Jonty I think we can assume that the draft is acceptable as it is and doesn't need major changes or additions.

On Wednesday, 24 October 2012 20:16:44 UTC+1, Tim Hardy wrote:

This thread is primarily to discuss what the contents of a new member manual should be, an idea arising from a long discussion about membership of the space. 

Jonty:

> Ideally a new member manual that can be issued along with this email. 
  A PDF is fine, but hard-copies in the space would be lovely. 
  Nottinghack have a beautiful one if you'd like an example of this. 

A copy of The Nottinghack manual is here: http://wiki.nottinghack.org.uk/images/9/96/Nottingham-hackspace-manual-web-Nov2011.pdf .

Akki also started this ages ago with the aim that it'd be on an A4 sheet of paper, easily printable from lovelace with a link on the desktop. 

 http://wiki.london.hackspace.org.uk/view/New_members_guide

If you felt lost when you first joined please use this thread to point out what you found most confusing at first (eg did you know about registering an RFID card).

If you have very strong feelings about what needs to be in the document, please jump in as well.