How make better Bay Area Node meetups?

yay-area-node-meetup-proposal.md

Goals

1. Capture some of the benefit of NodeConf, JSConf or RealTimeConf on a sustainable, regular basis.
2. Get enough of a quorum of Bay Area Node.js leadership involved to appeal to other people to attend and get involved themselves. This includes not just visible leadership, but valuable less-visible contributors like jlord, Dave Pacheco, Emily Tanaka-Delgado, and Daniel Erickson.
3. Provide an in-person forum to work through Node issues and improve and broaden the community.
4. Foster broader leadership by getting more people more involved.
5. Spread the organizational load among a wider crew of people so no one individual gets burnt out, more people get experience with running events, and we all are able to have fun.
6. If there is to be a bias when making speaker selections, have it be towards bringing in new speakers and creating a safe space for speakers to present new material.
7. Keep it fast-moving, entertaining, and concise -- have 2-hour (tops) meetups and then allow people to do social stuff thereafter.
8. See our Node friends outside of conferences and hackathons and make new Node friends.

Metrics

1. If this results in offshoot meetups that are Node equivalents of PyLadies or Black Girls Code, that is a strong signal of success.
2. Other meetups like NodeBots are complements, not competitors.
3. If people just show up, eat pizza / drink beer, listen to presentations, and leave, that's a strong signal of failure. The formula needs to be tweaked to get people interacting more.
4. A regular turnout of 30+ people, including a mixture of Node veterans and newbs, is the best signal of success. Letting the newbs see and participate in Node community shop talk is part of the point.

Strategies

1. New Relic handling soft logistics (space, food, presenters' tools)
2. New Relic / Joyent co-sponsorship (to make it easier to get Joyent peeps to show up)
3. combined Node Firm office hours and meetups
4. rotate organizational responsibilities among a crew of Node stakeholders
5. NodeUp Live
6. partnership with Hackbright Academy (or similar organizations)

Meetup topics

1. growing the Node community to be more inclusive
2. levelup hack frenzy!
3. kid-centered hack event for VoxelJS
4. "My favorite new module / technique / hardware thing / one weird tip." – not necessarily something you created yourself
5. Node vs ES6
6. streams2 -> streams3 (and beyond – the W3C JS streams API)
7. "How I wrote my own version of meatspac.es with WebRTC data channels, leveldown, and a pile of tiny streams modules." -- process and personal value over originality
8. real Node devops in practice (process management, deployment, cough performance monitoring cough, production troubleshooting)
9. A series of workshops on frameworks maintained by Bay Area developers, with an emphasis on practical use cases and retrospectives on what the devs have learned from building and maintaining them:
   1. Hapi
   2. Geddy
   3. Sails
   4. Restify
   5. StrongLoop LoopBack

Organization

1. Follow the lead of NodeConf 2013, NodeBots, and JSFest by using GitHub as an organizational tool.
2. Have a clear code of conduct (example) that is available in the GitHub repo, and have a clear process by which pull requests will be accepted and the policy can be discussed and modified by attendees and organizers.
3. Encourage people to submit topics or requests for talks as issues.
4. Encourage potential speakers to send pull requests to the repo with their proposals, and encourage people to workshop their ideas with each other. The orientation should be towards improving presentations for presentation rather than trying to meet a quality bar.
5. Reserve time for people to discuss and pitch their projects on an impromptu basis at every meetup.

Some thoughts from PDXNode:

1. Have a code of conduct from the outset; but communicate that it's owned by the community. It should be revisited over time.
2. Have a definition of what you're looking for from talks, and the process for having a talk accepted.
3. Be proactive about getting speakers -- especially new speakers. Have a path for them to progress; from lightning talks to full talks to (ideally, eventually) conference talks. Make it known that they don't necessarily need to be talking about something they wrote: we have a semi-recurring "node modules you should know" lightning talk segment at PDXNode where folk are encouraged to talk about neat modules that they've found or used.
4. Reach out to local JS code schools / have organizers and regulars TA there.
5. Having a site is (apparently!) not a prerequisite. That can come later. For that matter, pretty much every tech solution to organizational problems can come later -- concentrate on reaching out to people first, making them comfortable / building a community.
6. Borrow @hackygolucky.

Avoid well-trod Node 101 stuff to increase the likelihood that more experienced Noders will want to show up.

1. RE: the above, I'd defer this judgement until you have a couple of meetings and see what your audience is like. There's a lot of folks coming at Node from a lot of different directions. It's great to include these folk who may not know what streams are -- either they're new programmers or from a different language community, and it's great to accommodate new folks and grow the community.

Fellow PDXnode organizer here!

To add to @chrisdickinson ' s suggestions:

1. The Code of Conduct should be in place and owned by the community. It should be advertised by the organizers and on Github some other public forum to allow for community input and IDEALLY issues/pull request submissions.
2. Having a standard idea of talks you'd like to see and making a standard for it allows the group to communicate priorities and interests. Agreed that there -must- be a documented method for having a talk accepted. This seems like a lot of overhead, but results in managed expectations.
3. As part of gettings speakers, have a 'request a talk' list. This will help you guage what people are interested in and possibly missing from the group. Keep this list around! Having a built up list of possible speakers will save you a bunch of trouble in busy months.
4. The codeschool has been awesome so far! Engaged people excited to learn !!!JavaScript!!! It's amazing they exist. And they WANT to Node.(note: I think Hack Reactor out of SF covers Meteor. You should CHANGE THIS. PLEASE)
5. The website thing is embarassing but true. We're working on it! We're so busy. :-/
6. SF is pretty sweet. Especially Dolores Park. But <3 PDX. Always fancy a visit, however!

Lastly--also a comment on the Node101:
Leaning too far one way or another regarding experience levels will leave people out. Offering different types of meetups will allow for a wider net of people feeling welcome. Plus, node.js is awesome! Making it accessible is
a good thing and will make us better for it. Offering workshops will appeal to newer coders. They are willing to sit for a few hours and learn something new. More technical talks will draw experienced programmers. Hacknights can be inclusive to everyone, if advertised with a specific enough wording.

Thanks a bunch, @hackygolucky and @chrisdickinson!

1. A code of conduct is mandatory, and as this goes forward (if it does), we'll probably start with the GeekFeminism example policy (http://geekfeminism.wikia.com/index.php?title=Conference_anti-harassment_policy) and tailor it from there (like NodeConf / NodeBots / JSFest, we'll probably end up with a repo that people can send PRs to).
2. I like the idea of having clear standards about speaking and a transparent process for selecting speakers and presentations, but
3. this is very much about getting more people involved, both as speakers and as organizers. I want to get more people who aren't used to speaking in front of a supportive crowd. I like the idea of the lightning talk -> full talk -> conference presentation progression (mostly because it mirrors the path I've followed myself).
4. A big goal is to be able to support what Max Ogden is doing with nodeschool.io, and have some crossover between that and whatever regular thinger we end up with. One slight difference between SF and Portland is that there is already a pretty large front-end JS ecosystem here (meetups and more) that exists independently from Node. As much as possible, I want this to be complementary to what existing groups are doing, and avoid cannibalization. I suppose that's something for me to chew on.
5. If this does end up having a website, it will probably be along the lines of the magisterial site for dhtmlconf.com. Also, I've received some pretty explicit feedback to consider using something like tito instead of Meetup for coordination. I'd be happy to discuss the reasons why offline.
6. Of course any and all of PDX Noders are welcome at whatever we end up doing, in whatever capacity you want to participate. It's only fair after all the times you've let me barge into your events and start randomly babbling.

Regarding the Node 101 stuff, my intent is not to raise barriers to newbies or exclude the casual / curious, but to steer clear of dry tutorial material in favor of stuff that's a little more lively and informal. Like, instead of a basic domains tutorial (just f'rinstance), a talk about how somebody used domains to resolve some real operational issues. Or instead of talking about using Node to back a WebRTC app, show off an actual application you built. It's fine (and in fact preferable) to ground talks in an overview of what the modules / APIs are and how and why you might want to use them, but I think these kinds of things work better when the material is personalized or otherwise put in a more relatable context. NodeBots has been pretty great in this respect.

@hackygolucky

I think Hack Reactor out of SF covers Meteor. You should CHANGE THIS. PLEASE

Do you want to expand on this a little? I'm not sure what you mean. Hit me up via email if you prefer.

Riffing on "Promises by Promisers" and "CoffeeScript for CoffeeScripters" from NodeUp, I'd actually love to setup a "New to Node by New Noders".

My 2 cents:

Don't aim too high to start off with. Keep it small scale and aim for something you really want to do for an evening and see who shows up and take it from there.

I love everything written above. @dshaw, along those lines, @ceejbot gave a phenomenal talk at CascadiaJS aimed squarely at nodebots newcomers. It was seriously perfectly calibrated in scope.

I want to +1 the idea of creating a progression from lightning talk -> full preso -> conf talks, not because I think one is a prerequisite for the other, but because it makes it more approachable for people and helps people set attainable personal goals. @ceejbot's blog post mentioned toastmasters. Done right, a local community can be sort of a hacker toastmasters. One thing that toastmasters does is deliberately provide opportunity for feedback to presenters, so the presenters can grow. It also lets people cycle through various "leadership" positions, including MCing the meeting, so people can try out a variety of roles that they might be interested in growing in.

+1 @jden We did this for our buddy Nate Gaier so he could practice his talk and get feedback before he gave it at Node Summit in December. The group was very into helping him present it well.