I'm a Node Module Maintainer (And so can you!)

[basicallydan]

This is an idea for a fairly simple sort of tutorial on creating, releasing, maintaining, versioning, getting input for, etc, etc an open-source node module. Including:

• Some good practices when versioning, releasing, and documenting your open-source code
• Some NPM tips
• How to make your code inclusive
• Some GitHub tips

Just to show that I have at least some of the experience necessary for this, I currently am actively maintaining two packages and I've put a couple of others onto NPM: https://www.npmjs.org/~basicallydan and I've picked up a few things along the way.

If this sounds like it's too simple for LNUG, please let me know - I've only been to one event so far, and it seems to me like there's a fairly wide variety of experience levels at the usergroup so I'm sure some people would benefit.

Thoughts?

Preferred Month: February 2015

[orliesaurus]

We welcome talk aimed at all levels :)

[basicallydan]

@orliesaurus Cool :) So, any thoughts? Useful? Not useful? Needs more work?

[orliesaurus]

As an audience person I m expecting:

• Comparison of good vs bad practices
• cheat sheet style tips style with examples

[basicallydan]

That's pretty much what I had in mind. Though the first bit might be a bit
more of a tutorial in this sort of format:

1. You have a great node module you wanna share with the world!
2. I show you some good node-style API tips (e.g. expose a CLI and a JS API)
3. I show you how to publish it
4. Some ideas on how to keep it up to date and how to interact with your
   community
5. How to make sure new versions are properly published

Numbers 3-5 will include cheatsheet style things :)

--Dan
danhough.com http://www.danhough.com - @basicallydan
http://twitter.com/basicallydan

On 24 October 2014 18:08, orliesaurus notifications@github.com wrote:

As an audience person I m expecting:

• Comparison of good vs bad practices
• cheat sheet style tips style with exmaples ?

—
Reply to this email directly or view it on GitHub
#13 (comment).

[admataz]

sounds good to me - this stuff is so important and it's great to have a checklist and guidance - add some opinion, a war story and a joke or two andI think you have us a good talk .

[iancrowther]

+1

[basicallydan]

@admataz Good advice, thanks! I guarantee you it'll be at least a bit opinionated, hard to avoid with a subject like this!

I'll get to work asap and try it out on some housemates. Cheers chaps!

[orliesaurus]

25th it is!

[basicallydan]

Hey @orliesaurus, @iancrowther, @admataz I've put the slides up here: http://basicallydan.github.io/node-maintainer-talk

If you happen to have the time and inclination to have a look before tomorrow I'd be very grateful, but no pressure of course. Quick summary:

1. Inclusive code - target everyone (JavaScript specific)
2. The art of a good README (open-source in general, but a bit of JS-specific stuff)
3. The importance of dependency management (JS-specific)
4. Good versioning for Node (JS-specific, but relevant to OSS in general)
5. Pre-publish checklist - npm test, npm shrinkwrap, npm version and npm publish (JS-specific)
6. Interacting with your community (OSS in general)

Naturally it's a bit late to make any drastic changes, but if you have any thoughts I'd appreciate it. Thank you :)

[jkbits1]

@basicallydan I'm not on your list 😄, (and usually I'm commenting from a slightly different perspective) but the slides look good (and are very useful for me at the moment). Looking forward to your talk.

[admataz]

Hi @basicallydan - I've had a read through - and I really like the approach to the topic, and the content you've covered. I wouldn't change a thing about that. Very relevant and useful.

My 2p on the actual presentation - this is not essential, but if you can find the time to reduce the text in your slides to a single one or two points per slide (the main heading, basically) - and leave the detailed text to what you say verbally - I think it will make your talk stronger. Your audience attention won't be in a competition in keeping up with what you're saying, and what you've written and displayed. And if they are just reading along with what you are saying, their attention could drift . Keep that detail as a script for your own reference while you speak, and let your personality come through in the presentation/talk. If you want to provide the written detail/transcript, I'd say make it available as a gist/blog entry or something.

Looking forward to hearing it!

[basicallydan]

@jkbits1 Haha sorry dude, didn't see you there! Thanks for the feedback though, that's great!

@admataz Fantastic feedback - thanks! Some of the slides are a bit wordy, I agree. You should've seen them before I cut them down already! If you think it's still too wordy though that's good enough for me, I'll see what I can do at lunchtime tomorrow.

In case you're curious, look in the repo at my notes - while a bit out of date, this is what I'm using as my "detail", and coincidentally, as I was writing it, it felt like it could be a blog post so maybe I'll do that.

Anyway, thanks. Should be an excellent slide deck by tomorrow night!

[rosskukulinski]

@basicallydan love it! (and I agree with @admataz's points)