Agenda brainstorm

[rvagg]

Let's try and get some ideas of what we want to try and cover @ the summit and then we can begin to organise them into a proper agenda along with some proper planning along the lines of what @groundwater is suggesting in #6.

We only have 2 days and lots of potential for bikeshedding, rabbit holing and general rambling so we'd better keep it tight. We also have plenty of opportunity for social items so we should absolutely include ideas about that as well (SF locals?).

Here's some suggestions to get started:

• Working group standup / State of the WG: I think we should have representatives from all of the main working groups present so perhaps we can have someone give a quick talk on (a) what the group does, (b) who is involved and (c) any interesting progress or state that can be reported. This is separate to specific agenda items that any group wants to put in.
  • Addon API
  • Benchmarking
  • Build
  • Diversity
  • Evangelism
  • Intl
  • API
  • Docker
  • Hardware
  • LTS
  • Membership (is this a WG?)
  • Post mortem
  • Smoke test (perhaps falls under Build?)
  • Streams
  • Tracing
  • Website
  • TSC (can much be said about this?)
• Introduction to the Foundation: what it is, how it works, who are the people involved, what it means for us
• The path to convergence: we are unlikely to have a converged release out so a discussion / presentation on how that's rolling out and will be handled wrt releases, branches, versioning, LTS, etc. would be helpful.
• Core community: Discussion about how we manage & expand the collaborator group, how we perform onboarding and how we expand the TSC, could also cover mentoring and other means of helping people up-skill.
• Next-Gen: What would a Node-from-scratch look like? The kind of stuff in https://github.com/nodejs/ng/issues - I wouldn't suggest we spend too much time on this rabbit hole as it's more about using the discussion to help inform our shared ideals about the platform, not necessarily about doing anything about the bluesky items.
• Constructive discussion: It's often been pointed out that we have a culture of heavy discussion, mainly in core, it's become how we get things done (and sometimes not done, and that's not necessarily a negative). But this has many drawbacks, including the way it marginalises those who are not as comfortable diving in to robust discussion (likely those on the fringes who won't be well represented at the summit) and those who simply don't have time to read so much text (most of us!). This should be something we could at least have a discussion (oh the irony!) about, to get a shared understanding of the pros and cons of what we do and perhaps find a path to improving.
• V8: Perhaps a discussion about how what happens in V8 upstream impacts us and how we can shield ourselves from the problems it causes while also benefiting from the work they do (a vague topic, but an interesting one for some perhaps?).
• TSC Meeting: We could punt the TSC meeting from the Wednesday to the Thursday and have a quick one, expanded to include anyone that wants to be involved in the discussion (would need to be careful to keep it within a reasonable time limit, also not suggesting that everyone who's there gets a vote).
• NodeUp Live: Assemble a panel towards the end of our time of people that have been most engaged and discuss what we've done (would need to coordinate on sound gear for this, I often take my own when doing this kind of thing domestic--could I get a contact at the venue to talk about what's available there?)

[rvagg]

/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

[Fishrock123]

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.

[thefourtheye]

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

[nebrius]

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 https://github.com/libuv/libuv/pull/379).

[mscdex]

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

:+1:

[Starefossen]

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.

[wraithan]

@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.

[wraithan]

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.

[Trott]

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/

[Trott]

+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.

[snostorm]

I posted some ideas at https://github.com/nodejs/io.js/issues/2213#issuecomment-124273228 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?)

[Qard]

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.

[mikeal]

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 :)

[piscisaureus]

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?

[Fishrock123]

WaffleJS Wednesday Evening

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

[nebrius]

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

What better way to kick off the summit? :grinning:

[mikeal]

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.

[Fishrock123]

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. :)

[mikeal]

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.

[mikeal]

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.

[nebrius]

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

[Fishrock123]

@mikeal ping about the above ^