Goals, Theme, and Format

[mikeal]

Wanted to kick off a conversation about the goals, theme and format this year:

• The theme this year is "Moduletopia"
• Core is over, long live npm. No content will be specifically about core, all content will involve modules.
• Doubling down on workshopper. Most of the sessions should use workshopper.
• Everyone must leave NodeConf knowing:
  • How to find the modules they need.
  • How to responsibly publish a module they write.
  • How to log and issue and fix a bug in an existing module.

Although the format will be similar to last year I have some changes/enhancements I'd like to make.:

• The first session will be 30 minutes longer than the rest. In the first 30 minutes everyone, in every session, will publish a module that is their name and does nothing but print their name. This will be pushed to GitHub and published to npm.
• Integrate some outside activities in to the programme. Rather than taking almost all of the last day as a break integrate those activities mid-day in to the programme.
• In one session compile a very long list of easily fixable bugs in other people's modules and write a program that randomly assigns them. This session will be incredibly hard to run but potentially one of the most rewarding.

Thoughts?

[rvagg]

This blows my mind: http://nodechecker.com/ more than 50% of modules in npm don't have tests, or at least don't have tests that nodechecker can identify and use. One of the major benefits of modularisation is the added ease of testing.

Not many people love writing tests but this is important for our community so it should be encouraged somehow.

[mikeal]

Yeah, @maxogden has a great list of best practices for published modules. We should make sure that all of those land in the module they publish in the first 30 minutes.

[mikeal]

@othiym23 this is the current thread you probably want to comment on.

[othiym23]

I've seen some discussion about the strengths and weaknesses of workshopper (I can name names if I need to ;) which lead me to believe that we may want to formulate the goal as saying that presentations should be interactive, rather than preselecting a tool.

I think it would be useful to at least bring into the discussion the idea of module ecosystems. Leveldb is the most obvious example right now, but browserify is another one. The way levelup has been bootstrapping a community around itself definitely had a big impact on how I thought about building out CLS.

I am totally in favor of the idea of more evenly interleaving breaks with workshops. An idea: everybody has 10-12 slots in their schedule, but only 8 of those have structured activities scheduled in them. This increases the workload on presenters, which is presumably offset by the increased emphasis on interactive presentations.

I am 100% in agreement with Rod about the desire to get people writing more tests. It would be awesome if the npm crew had got some of the kwalitee™-checking stuff @isaacs has been talking about adding to npm had landed by then, but whatevs, pounding into people's heads the importance of testing seems like a sound long-term investment in the community.

If we want people to take this stuff seriously, their intro module should probably be more than console.log("Forrest says howdy.")

There was a lot of discussion about new quasiconventional documentation. New Relic has made me keenly aware of the need for LICENSE and / or filling out the license stanza in package.json, the security panel stressed the importance of something like SECURITY.md for more significant modules, and of course GitHub already has hooks for integrating README.md and CONTRIBUTING.md into its display.

This might sound incredibly poochie, but I think it would be at least worth discussing how best to package modules for discoverability. A little "ha ha only serious" bit on module SEO?

If nothing else I suggest sticks, I'd LOVE to see material on how to file tickets, create pull requests, and otherwise collaborate. Out of NAKED SELF-INTEREST. I've get a ton of value out of issues and pull requests, but I've also gotten a lot of people who seemingly think they're helping me with incredibly vague and / or opinionated issues. This is definitely something that can be taught.

"Programme"? When do we break for high tea?

[mikeal]

workshopper

The important thing to me is that things are interactive and that the lesson can continue after they leave if they want to go at on their own at home. I like that the materials have a healthy life long after the conference both for new people and for those that were in the class. That said, workshopper may not always be the best tool in all of these cases.

Does anyone have ideas that could help us make the instructional aspects for interactive and downloadable as well? Stuff like "GitHub best practices" and "npm best practices" have a big instructional component, if we get creative we could expand workshopper's facilities in this area or write something new.

RE: breaks

The breaks need to be blocked out for the whole attendance, and presenters, or else they won't come at the right times. I have some experience with this :)

[justinabrahms]

One possibility around compiling a list of easily fixable bugs is to seed it with a few modules that are known to be defective. This allows you to ensure that classes of issues (no tests, no license) are targetable and still allows folks to try the pull request workflow.

One thing I'd personally be into is someone submitting a PR for a testing harness with 1 proof of concept test. The end result would be that I could take their patch, run npm test and would get 1 passing (or failing?) test. Bonus points if there is some level of shame involved around code coverage (eg: merely stating that I have 0% test coverage).

[mikeal]

@justinabrahms good point.

I was thinking of a "node patterns' workshop where we just drill best practices like having npm test and run targets.

It wouldn't be too hard to parse the modules in npm to find the ones that have tests but don't have a proper test target. @isaacs thoughts?

[hackygolucky]

Is Node.js Koans a thing? I know Workshopper and nodeschool.io have really dug into a koans style, but the emphasis on testing your Node code with koans would be pretty amazing. Most of the search results I find are pretty dated, not very in-depth, or focus on a pretty specific but common use case of express(which I don't personally find useful because I don't express).