Agenda brainstorm about summit HOT 22 CLOSED

/cc @nodejs/addon-api, @nodejs/benchmarking, @nodejs/build, @nodejs/collaborators, @nodejs/crypto, @nodejs/docker, @nodejs/evangelism, @nodejs/hardware, @nodejs/internationalization, @nodejs/post-mortem, @nodejs/streams, @nodejs/tracing, @nodejs/tsc, @nodejs/website, @nodejs/membership

from summit.

Native addons / node-gyp probably needs to be a topic of some sort. (NAN and Hardware WGs will def be interested)

Constructive discussion

Sounds like a Diversity / Onboarding this as well, should be good!

TSC Meeting

Aren't we only like missing Ben and Brian? Sounds like we could have one in person.

from summit.

Awww... I love to participate in this and I am missing it. 😢 Do we have live streaming or something?

from summit.

cc @nodejs/diversity

Regarding hardware, @Fishrock123 beat me to it! Native modules/NAN are a big focus for us, along with getting the necessary support in libuv and node core so that node-serialport can be pure JS (see libuv/libuv#379).

from summit.

Awww... I love to participate in this and I am missing it. Do we have live streaming or something?

👍

from summit.

We also have plenty of opportunity for social items so we should absolutely include ideas about that as well (SF locals?)

+1 for social items to get to known one another. I'm staying in SF until Sunday if someone wants to link up during and after the summit.

from summit.

@rvagg I can't confirm we can still use it right now, but if y'all are ok with going offsite to record NodeUp, New Relic's SF office has a recording room. Maybe @groundwater could confirm that it is ok to use for NodeUp.

from summit.

I think that @nodejs/build @nodejs/lts @nodejs/smoke-test all should get together to come up with a way to better test highly popular community modules and their compatibility with newer versions of node. Smoke Test is just starting to work on this but it would be very important to the LTS and Build groups.

An example of why this is important is that the memcache module was broken for a bit because the underlying hashring module it relied on stopped building after an io.js release. The common data stores drivers (mongo, redis, postgres, memcache, etc), most common frameworks (express, restify, hapi), and probably common util libraries (underscore/lodash, async, gulp, grunt, etc) should all at least receive a heads up when a new version of node is coming that will break them.

I understand that build infrastructure isn't free, people's time is very limited, etc. But, if we want node to continue getting adopted by businesses, then we need to be able to really assert our stability. This doesn't mean changes that break modules like express should be rejected, just that express should get a heads up and it should probably thought about more critically if it is going to break existing versions of express.

from summit.

For people needing something to do on the Thursday night of the summit and terrified of the prospect of it being something that doesn't have to do with Node, there's this: http://www.meetup.com/sfnode/events/223133402/

from summit.

+1 on @wraithan's get-everyone-on-the-same-page-about-smoke-testing-with-npm. I know there's been some progress/discussion over in smoke-test the last few days, but there are still some unanswered questions. A face-to-face meeting seems like a unique opportunity to do a point-in-time document of what we know, what we plan on trying, and what is still up in the air. I'm happy to be the note-taker.

from summit.

I posted some ideas at nodejs/node#2213 (comment) which I'll summarize below.

Relating to some of the a higher level themes which I think would overlap the scopes of the website/marketing/evangelism/translation groups I think it would be good to have discussions (big or small) on a few topics:

• How public outreach can best be leveraged to help keep our existing users in the loop with all that is going on (and excite new users). A lot can still be done to communicate the changes our new governance structure has introduced.
• How to better develop and scale up a wider volunteer base. How do we keep them engaged moving forward? How do we connect volunteer resources to WGs?
• I'd also like us to try to identify possible needs shared amongst the efforts of the TSC and WGs. (How are they communicating to the outside world? Can we make that easier or more consistent? How can we better help our working groups succeed in general?)

from summit.

Obviously the Tracing WG would like to bring up the tracing situation, and I'd like to see some discussion on debugging/tooling support.

More discussion on how to open up internals knowledge would be good too. There's been a bit of progress from the Docs WG on that, but it'd be good to keep things moving there.

from summit.

Ok, I'm going to try and distill some of the thoughts here in to sessions and goals that we can use in the other thread.

• Session 1 (Intros and Best Practices)
  • Each person introduces themselves: 2 minute limit.
    • Name
    • Working Groups and projects you're involved in.
    • A point of collaboration or process that has worked very well in a project or WG you're in.
    • A point of collaboration or process that didn't work at all in a project or WG you're in.
  • Map projects, WGs, and points of collaboration.
  • Create "Best Practices" draft document for projects and Working Groups.
• Session 2 (Automation and CI)
  • Create a list of all current automation and the working groups that manage them.
  • Map automation to processes from various working groups (what is tied to build? what is tied to PR? what is tied to a website commit?)
  • Create a list of future automation.
  • Create a prioritized list of current and future automation and assign/plan each high value item.
• Session 3 (What is Node.js?)
  • A discussion of what "the node platform" is.
    • Produce a map of platform areas and APIs packages and applications depend on.
  • A discussion of what the "Node API" should be.
    • Separate the API in to platform areas.
    • Create parallel roadmaps for each to arrive at an API definition.
• Session 4 (TBD)
• Session 5 (Broadening the Collaborator Base)
  • A holistic session to address increasing the number of contributors and broadening the demographics of those participants.
  • Set target goals for end-of-year participation metrics.
  • Develop guidelines for diversity, accessibility and international participation. These guidelines should be specific, as in "do this" "do not do this" rather than subjective. The purpose of these guidelines is to provide guidance to future contribution policies and outreach programs.
  • Map the current new contributors experience.
  • Create a prioritized list of changes to existing processes.
  • Create an outreach plan for achieving participation goals.
• Session 6 (Future)
• Social Activities
  • WaffleJS Wednesday Evening
  • NodeUp Live! (someone will have to take point finding a venue for this)
  • Evenings at The Yard at Mission Rock
    • Large flexible space everyone can hang at.
    • Optional wine and beer served from a truck.
    • Food trucks, tables, lots of open social space that isn't too loud to talk.
    • Outside, enjoy the San Francisco August weather :)

from summit.

It would be nice if some board members could be around for getting to know the community and vice versa. Wouldn't have to be for the entire conference, just a few hours or a session maybe. @rvagg /@mikeal agree?

from summit.

WaffleJS Wednesday Evening

Isn't that on the 5th, the day before?

from summit.

Isn't that on the 5th, the day before?

What better way to kick off the summit? 😀

from summit.

It would be nice if some board members could be around

We can invite them over for lunch one day or for one of the evenings. I'm not sure how many are local though, maybe only a few.

from summit.

We can invite them over for lunch one day or for one of the evenings. I'm not sure how many are local though, maybe only a few.

People can be busy so it's probably best to check sooner than later. :)

from summit.

Proposal for a split session (1/hr w/ another 1/hr back-to-back) for Session 4.

• Session 4.1 (Node Fails)
  • What happens when failures happen in node?
  • Categorize and Map the variety of failures to their current and possible solutions (promise catches, asyncwrap, tracing, post mortem)
  • Draft parallel roadmaps for each solution.
• Session 4.2 (The v8 problem)
  • Create a list of all the ways in which we are tied to v8 noting which change/break between releases and how.
  • Create a list of issues we encounter when updating v8 and prioritize by severity.
  • Propose solutions to each issue and prioritize.

from summit.

People can be busy so it's probably best to check sooner than later. :)

I'll let the board know that this is happening along with the dates in Monday's meeting.

from summit.

Just a heads up, @zkat and I can only attend on Thursday, so can we schedule all the diversity related discussions for Thursday?

from summit.

@mikeal ping about the above ^

from summit.