From 7322ad43daaaeedc31dba562501692d566c8b6b4 Mon Sep 17 00:00:00 2001 From: Chris Williams Date: Fri, 24 Apr 2015 18:15:50 -0400 Subject: [PATCH] Solving for issue #34 --- meetings/2014-11-06/minutes.md | 29 +--- meetings/2014-11-20/minutes.md | 29 +--- meetings/2014-12-04/minutes.md | 217 +++++++++++++---------------- meetings/2014-12-19/minutes.md | 245 ++++++++++++++++----------------- meetings/2015-01-14/minutes.md | 233 ++++++++++++++----------------- meetings/2015-01-29/minutes.md | 231 ++++++++++++++----------------- meetings/2015-02-24/minutes.md | 185 +++++++++++-------------- meetings/2015-03-09/minutes.md | 203 ++++++++++++--------------- meetings/2015-03-23/minutes.md | 215 +++++++++++++---------------- meetings/2015-04-06/minutes.md | 98 ++++++------- 10 files changed, 731 insertions(+), 954 deletions(-) diff --git a/meetings/2014-11-06/minutes.md b/meetings/2014-11-06/minutes.md index f2fda14..36eed4f 100644 --- a/meetings/2014-11-06/minutes.md +++ b/meetings/2014-11-06/minutes.md @@ -80,31 +80,4 @@ Working group for trademark and website # Next Meeting -Please join our next meeting, Nov 20, 2014 at 2:00 PM EST / 11:00 AM PST at [https://global.gotomeeting.com/join/532589549](https://global.gotomeeting.com/join/532589549) or please dial-in in using your telephone. - -``` -United States: +1 (646) 982-0002 -Australia: +61 2 8355 1023 -Austria: +43 (0) 7 2088 0034 -Belgium: +32 (0) 38 08 1855 -Canada: +1 (647) 497-9350 -Denmark: +45 (0) 69 91 80 05 -Finland: +358 (0) 931 58 1746 -France: +33 (0) 182 880 455 -Germany: +49 (0) 692 5736 7313 -Ireland: +353 (0) 15 290 180 -Italy: +39 0 699 36 98 80 -Netherlands: +31 (0) 708 912 514 -New Zealand: +64 (0) 9 909 7882 -Norway: +47 21 03 58 95 -Spain: +34 931 81 6668 -Sweden: +46 (0) 852 503 498 -Switzerland: +41 (0) 435 0006 96 -United Kingdom: +44 (0) 330 221 0085 - - -Access Code: 532-589-549 -Audio PIN: Shown after joining the meeting - -Meeting ID: 532-589-549 -``` +Please join our next meeting, Nov 20, 2014 at 2:00 PM EST / 11:00 AM PST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file diff --git a/meetings/2014-11-20/minutes.md b/meetings/2014-11-20/minutes.md index 142d8de..e97cf07 100644 --- a/meetings/2014-11-20/minutes.md +++ b/meetings/2014-11-20/minutes.md @@ -64,31 +64,4 @@ The following working groups were identified to tackle specific core issues: # Next Meeting -Please join our next meeting, Dec 4, 2014 at 4:00 PM EST / 1:00 PM PST at [https://global.gotomeeting.com/join/273347861](https://global.gotomeeting.com/join/273347861) or please dial-in in using your telephone. - -``` -United States: +1 (626) 521-0010 -Austria: +43 (0) 7 2088 1033 -Belgium: +32 (0) 28 08 4296 -Canada: +1 (647) 497-9371 -Denmark: +45 (0) 69 91 89 21 -Finland: +358 (0) 942 41 5770 -France: +33 (0) 170 950 585 -Germany: +49 (0) 692 5736 7205 -Ireland: +353 (0) 19 030 050 -Italy: +39 0 693 38 75 50 -Netherlands: +31 (0) 208 080 208 -New Zealand: +64 (0) 9 925 0481 -Norway: +47 21 04 29 12 -Spain: +34 911 82 9890 -Sweden: +46 (0) 852 500 179 -Switzerland: +41 (0) 435 0167 65 -United Kingdom: +44 (0) 330 221 0096 - -Access Code: 273-347-861 -Audio PIN: Shown after joining the meeting - -Meeting ID: 273-347-861 - -``` - +Please join our next meeting, Nov 20, 2014 at 2:00 PM EST / 11:00 AM PST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file diff --git a/meetings/2014-12-04/minutes.md b/meetings/2014-12-04/minutes.md index 8654167..0785145 100644 --- a/meetings/2014-12-04/minutes.md +++ b/meetings/2014-12-04/minutes.md @@ -1,171 +1,144 @@ -# December 04, 2014 +# December 04, 2014 ## Attendees -Chris Williams (CW) -Bert Belder (BB) -Chris Saint-Amant (CS) -Cian O'Maiden (CO) -Danese Cooper (DC) -Erik Toth (ET) -Issac Roth (IR) -Kevin Decker (KD) -Scott Hammond (SH) -Todd Moore (TM) -Dan Shaw (DS) -Isaac Schlueter (IS) -TJ Fontaine (TF) -Trevor Norris (TN) -Gianugo Rabellino (GR) -Mark Carrol (MC) +Chris Williams (CW) +Bert Belder (BB) +Chris Saint-Amant (CS) +Cian O'Maiden (CO) +Danese Cooper (DC) +Erik Toth (ET) +Issac Roth (IR) +Kevin Decker (KD) +Scott Hammond (SH) +Todd Moore (TM) +Dan Shaw (DS) +Isaac Schlueter (IS) +TJ Fontaine (TF) +Trevor Norris (TN) +Gianugo Rabellino (GR) +Mark Carrol (MC) Manish ? -## Public Recap +## Public Recap ### Trademark and Website WG (Scott Hammond) -**SH:** Some overlap with compliance group. Recommend not to share the trademark yet until certification is fleshed out. Want to hear from the community as to how people would like to use the trademark. WG discussed liberal or “stingy” use of trademark. No resolution but will discuss further, however discussion resulted in possible multi-mark solution, one representing API compliance or certification. Agreed *TM* will setup conversation with trademark attorney. *DS* will research current usage of trademark. Discussed modifying current website to downplay Joyent and expand content such as ads or meetup information. Also discussed establishment and enforcement of policy (ET: website content?) guidelines. Followup meeting to be scheduled. +**SH:** Some overlap with compliance group. Recommend not to share the trademark yet until certification is fleshed out. Want to hear from the community as to how people would like to use the trademark. WG discussed liberal or “stingy” use of trademark. No resolution but will discuss further, however discussion resulted in possible multi-mark solution, one representing API compliance or certification. Agreed *TM* will setup conversation with trademark attorney. *DS* will research current usage of trademark. Discussed modifying current website to downplay Joyent and expand content such as ads or meetup information. Also discussed establishment and enforcement of policy (ET: website content?) guidelines. Followup meeting to be scheduled. ### Advisory Board WG (Dan Shaw) **CS:** Set 2 main objectives: 1) replace existing Advisory Board through transparent, public process and 2) refine scope of AB responsibilities. Expect that scope will be reduced over time. Reiterate 4 groups: core team, Joyent as steward, Advisory Board and user community. Responsibilities do not include technical direction. Support community growth aside from technical contributions. TC owns governance model but AB provides feedback on governance in regard to non-technical areas. Proposed AB selection process includes criteria for core team members, but still requires refinement. Major goal is to improve representation from broader community of Node.js members. Users who want to have input into technical direction should defer to TC, not Advisory Board. Open questions: 1) Scope of responsibilities between TC and AB, 2) Joyent’s role on AB -**DS:** Will be meeting again before the holiday’s to move discussion forward. +**DS:** Will be meeting again before the holiday’s to move discussion forward. ### Technical Committee/Governance WG (Isaac Schlueter) -**IS:** Discussed proposed changes. *TJ* opposed to voting mechanism, preferring consensus. Concerned the edge cases result in bullying of minority. Danese suggested Apache model. Four participants in favor of voting, but no resolution reached. Back and forth on contribution policy and participants. Isaac in favor of open/open, Bert suggested TC vote for commit bit. TC has ownership of governance, so can be changed but with strict consensus. Also has chat history from conversation. -**TF:** Erik proposed strawman to adopt in short-term to iterate. He conducts meetings as Danese describes, so next WG conversation will reflect that more clearly and will look into Apache process. -**SH:** Please keep to quick summary. +**IS:** Discussed proposed changes. *TJ* opposed to voting mechanism, preferring consensus. Concerned the edge cases result in bullying of minority. Danese suggested Apache model. Four participants in favor of voting, but no resolution reached. Back and forth on contribution policy and participants. Isaac in favor of open/open, Bert suggested TC vote for commit bit. TC has ownership of governance, so can be changed but with strict consensus. Also has chat history from conversation. +**TF:** Erik proposed strawman to adopt in short-term to iterate. He conducts meetings as Danese describes, so next WG conversation will reflect that more clearly and will look into Apache process. +**SH:** Please keep to quick summary. ### Compliance/Certification WG (Dan Shaw) -**DS:** Meeting just happened so still compiling notes. Identified potential strategies at varying levels of effort. One is to define Node.js API compliance test suite vs. create canonical JS implementation that every entity should use to be “Node.js Compliant.” Approaches aren’t mutually exclusive and could be combined. Coordination needs to happen between trademark group and possibly new ™ aside from Node.js for use by companies to indicate their compliance. Indemnification of party providing compliance will be policed by market, not policing body. Input from Danese on the history of Java as an example, and during that process Sun tried to oppress ecosystem, creating tension. Worked to fix collaboration instead of improving technology. Should compel complying companies to publish compliance test data. Open questions include ownership, technical problems including targeting/tracking Node.js now or in the future? Action item is to review IronRuby and IronPython community for examples. +**DS:** Meeting just happened so still compiling notes. Identified potential strategies at varying levels of effort. One is to define Node.js API compliance test suite vs. create canonical JS implementation that every entity should use to be “Node.js Compliant.” Approaches aren’t mutually exclusive and could be combined. Coordination needs to happen between trademark group and possibly new ™ aside from Node.js for use by companies to indicate their compliance. Indemnification of party providing compliance will be policed by market, not policing body. Input from Danese on the history of Java as an example, and during that process Sun tried to oppress ecosystem, creating tension. Worked to fix collaboration instead of improving technology. Should compel complying companies to publish compliance test data. Open questions include ownership, technical problems including targeting/tracking Node.js now or in the future? Action item is to review IronRuby and IronPython community for examples. -## Review of Action Items (Chris Williams, et. al.) +## Review of Action Items (Chris Williams, et. al.) -### GitHub Process (TJ Fontaine) +### GitHub Process (TJ Fontaine) No additional updates. ### Code of Conduct WG (Todd Moore) -**TM:** No bandwidth to run this WG. -**TF:** Would be happy to drive this WG. -**TM:** We need to schedule meetings, pulling together existing proposal. Start limited and as expand if necessary. Looking to other examples and organizations to lay groundwork. +**TM:** No bandwidth to run this WG. +**TF:** Would be happy to drive this WG. +**TM:** We need to schedule meetings, pulling together existing proposal. Start limited and as expand if necessary. Looking to other examples and organizations to lay groundwork. ### Trademark and Website WG (Scott Hammond) -No additional updates. +No additional updates. ### Advisory Board WG (Dan Shaw) -No additional updates. +No additional updates. ### Technical Committee/Governance WG (Isaac Schlueter) -**IS:** Only additional comment is that feeling like there is much focus on minor details. Voting has been pragmatic in the past and vote happened because group decided it was best way forward. Bikeshedding over voting, but agree that TC owns process so voting could be added later. Confusion/lack of alignment: in principle is the TC the committers or could there be TC members who are not GH committers, etc? Could be value in having someone such as community manager, TC39 member, V8 team member on TC as example of non-committers who could add value. Also, should a LARGE group of committers, so having all committers be on TC might become untenable: committer group much larger than TC. -**TF:** Agreed we want involvement from V8 or other external technical people. People who make decision must be internal/committers. Not opposed to non-technical decision makers, however example given in meeting (Isaac continue to have commit bit due to ownership/ knowledge of subsystem). More discussion around structure of getting people the commit bit. -**IS:** People want to contribute without getting involved in TC or help make decisions. Benefit of open/open is that barrier(?) can be removed. -**TN:** Doesn’t want anyone NOT writing or maintaining code making decision on technical direction. They should not be helping make decisions. -**CS:** Not a matter of telling, but guiding direction is a matter of leadership; committing code or otherwise. -**TN:** Concern that non-technical contributors have little accountability because that can’t own the implementation. -**IS (?):** Makes sense to have more committers than TC. At least want insight and guidance from non-committers. Should be more committers than TC members; will mandate better documentation and communication. -**TN:** Don’t care how many people have commit bit. Who signs off on important patches? Domain experts like Fedor should sign off? What is the process behind deciding and landing on patches. -**IS:** As long as TC owns release process risk of mayhem is low. Patches can be reverted. -**DC:** You’re talking about lazy consensus. Assumed that all patches can be reverted. -**TF:** We’re talking more about workflow than changing how Node fundamentally works. Mechanism is that subsystem experts can integrate change. Anyone can review any pull request and after a while team can delegate trust to participants and ultimately even though they didn’t have a commit bit, could be brought in based on decision of the current committers. -**CW:** Checkpoint. -**SH:** Sounds like group agrees on consensus model. Let’s agree on big stuff and refine. -**IS:** Important thing is to establish something and change as necessary. -**CS:** It’s important to think of TC as leadership. Commit bit doesn’t make you a great leader, so keep in mind when choosing TC participants: may not be actively writing Node.js code. Leaders maybe be needed to execute against roadmap. -**CW:** Will continue discussion in WG. -**BB:** Should add *TN *to WG +**IS:** Only additional comment is that feeling like there is much focus on minor details. Voting has been pragmatic in the past and vote happened because group decided it was best way forward. Bikeshedding over voting, but agree that TC owns process so voting could be added later. Confusion/lack of alignment: in principle is the TC the committers or could there be TC members who are not GH committers, etc? Could be value in having someone such as community manager, TC39 member, V8 team member on TC as example of non-committers who could add value. Also, should a LARGE group of committers, so having all committers be on TC might become untenable: committer group much larger than TC. +**TF:** Agreed we want involvement from V8 or other external technical people. People who make decision must be internal/committers. Not opposed to non-technical decision makers, however example given in meeting (Isaac continue to have commit bit due to ownership/ knowledge of subsystem). More discussion around structure of getting people the commit bit. +**IS:** People want to contribute without getting involved in TC or help make decisions. Benefit of open/open is that barrier(?) can be removed. +**TN:** Doesn’t want anyone NOT writing or maintaining code making decision on technical direction. They should not be helping make decisions. +**CS:** Not a matter of telling, but guiding direction is a matter of leadership; committing code or otherwise. +**TN:** Concern that non-technical contributors have little accountability because that can’t own the implementation. +**IS (?):** Makes sense to have more committers than TC. At least want insight and guidance from non-committers. Should be more committers than TC members; will mandate better documentation and communication. +**TN:** Don’t care how many people have commit bit. Who signs off on important patches? Domain experts like Fedor should sign off? What is the process behind deciding and landing on patches. +**IS:** As long as TC owns release process risk of mayhem is low. Patches can be reverted. +**DC:** You’re talking about lazy consensus. Assumed that all patches can be reverted. +**TF:** We’re talking more about workflow than changing how Node fundamentally works. Mechanism is that subsystem experts can integrate change. Anyone can review any pull request and after a while team can delegate trust to participants and ultimately even though they didn’t have a commit bit, could be brought in based on decision of the current committers. +**CW:** Checkpoint. +**SH:** Sounds like group agrees on consensus model. Let’s agree on big stuff and refine. +**IS:** Important thing is to establish something and change as necessary. +**CS:** It’s important to think of TC as leadership. Commit bit doesn’t make you a great leader, so keep in mind when choosing TC participants: may not be actively writing Node.js code. Leaders maybe be needed to execute against roadmap. +**CW:** Will continue discussion in WG. +**BB:** Should add *TN *to WG ### Compliance/Certification WG (Dan Shaw) -No additional updates +No additional updates -## New Business +## New Business ### io.js Fork (Scott Hammond) -**SH:** Want to understand fork intent, philosophy and relationship to Node.js. -**IS:** io.js was Fedor feeling frustrated that node-foward/node was kept private (potentially due to risk of lawsuit), so name was changed and repo opened. Community rallied around it. Intent is same as node-forward to iterate on problems and solutions, ultimately merging back with joyent/node. Success depends on progress in AB and WGs and no hostility involved. Fork of joyent/node in same way as isaacs/node -**IR:** Sugar-coating. Undertone is that node-forward was altruistic, io.js has feeling of being subversive. People on AB were involved in node-forward but have less impact on io.js. -**IS:** Disagree. node-forward was not strictly about technical progress, but organizational progress. -**IR:** node-forward was created consensus-seeking, but io.js was unilateral. It colored the perception of the community. -**IS:** That’s describing *IS*, *BB*, and *IR* feeling, but the community doesn’t see it that way. Same people, same committee, same process, aims and objectives. Not every journalist is telling that story, but that it’s hostile. Not everyone involved in io.js is hostile. Conversation was started in August and now it’s December with little progress, understandably. -**DC:** Keep in mind Joyent leadership changed. -**SH:** I needed to build trust. -**IS:** The community actively did not trust joyent prior to *SH* arrival. Joyent position was: no changes. Not putting it on *SH*. -**SH:** Patience appreciated. -**IR:** Agreed that external perception may not have changed much. Pointing out that io.js is driven by people not at this meeting and has life of it’s own. More divergent faction than we’ve had yet and increases pressure to come up with solution that works for everybody. -**IS:** Unilateral move by Fedor and would have advised him against. -**DS:** Look at the AB as here to protect business value of Node, but io.js release pent up need of people who want to contribute to contribute. Should be wake-up call to AB to accelerate and merge streams. -**IS:** A little bit of fire under us to deliver on promise of AB. Don’t think we need to change course at this time due to io.js. Looks better for Joyent if it were able to be called “node.” io.js TC needs to come to shared understanding of messaging. No known disagreement with this sentiment amongst io.js. Should the diverge it’s not optimal. -**TM:** That would be bad for everyone, we should converge. -**CS:** Perception is very different from what *IS* described is the internal sentiment. Don’t see any help from the io.js side so mitigate perception issues as pertaining to Wired article. io.js should articulate path to re-merging, including expectations of Joyent. Be clear of road toward reconciliation, if that’s the true intent and desire. Possibly identifying it as an interim effort. -**IS:** There a couple non-temporary ways to collaborate: 1) Move code/binary kernel to io.js, with node wrapping io.js, 2) pull patches from io.js. These are non-hostile and non-competitive. Premature to commit to saying it’s temporary. -**TM:** We are making good progress; what is it that makes it possible to bring the forks back together again. -**CS:** Saying a long-term divergence is possible is difficult reconcile with AB. What’s rationale should issues get resolved. -**IS:** This is *if* the issues can’t be resolved. -**CS:** This needs to be clarified with general public that a long-term fork is only possible if issues aren’t reconciled. -**IS:** Preparing a message to clarify. There are multiple options, but don’t think anyone prefers a name change. Everyone already says “Node”. Having to say JS on the server other than Node is damaging and competition will be damaging. Could be a symbiotic relationship, but too early to tell. If issues can be resolved no reason for io.js to continue to exist. -**CS:** Good to hear and want to ensure that explanation is crisp to community. -**IS:** To be clear, I’m annoyed Fedor did this unilaterally. Agree that continuing to call it io.js is non-optimal. Would have been ideal to announce with publication of fork. -**DS:** IS covered the io.js messaging, but there’s a need for the AB to respond. -**DC:** A unified message from AB is necessary. -**DS:** Should message that the needs have been identified and we’re accelerating work toward resolving issues. -**CS:** Could the two groups put out messaging together showing unity? -**SH:** The reason behind the AB was to address conflicts head-on. We are all better off getting a slice of watermelon vs a whole grape, so we need to align around what we want Node to be. This includes community, healthy ecosystem etc. Obvious contention but this group was formed to figure it out. Sounds like resolution or progress wasn’t quick enough. Are we still interested in resolving these issues and is it still the correct course of action to prevent forking and bifurcation of the community? I feel like we finally reached a point where we were establishing trust and I’m committed to this path recognizing there is more to do here. Would like to see a true io.js messsage. -**IS:** What’s happening on social media is the community rushing to fill a vacuum. -**IR:** *SH* is coming from a position of thinking Joyent is in charge. -**IS:** I’m in the middle of multiple groups so a unique position. io.js needs to put together messaging and say what’s actually going on. A joint message is a bad idea. It makes it seem that io.js is connected with the AB. Part of motivation for io.js was for TC to do things that was not beholden to Joyent. If it appears otherwise it could be disruptive to community, some of whom don’t trust Joyent. Should say that core contributors are still working with Joyent to come to resolution. Also saying that io.js is working in public with goal to rejoin with Joyent. -**TM:** AB should say we’re working and committed to same goals as io.js and willing to work together with them. -**SH:** I have reached out to Fedor to understand. Have not heard back, but would like conversation with him. Not an issue of me feeling I’m in charge, but instead having a consistent message that we are working with community and what we’re doing is in the best interest of the direction of the project. +**SH:** Want to understand fork intent, philosophy and relationship to Node.js. +**IS:** io.js was Fedor feeling frustrated that node-foward/node was kept private (potentially due to risk of lawsuit), so name was changed and repo opened. Community rallied around it. Intent is same as node-forward to iterate on problems and solutions, ultimately merging back with joyent/node. Success depends on progress in AB and WGs and no hostility involved. Fork of joyent/node in same way as isaacs/node +**IR:** Sugar-coating. Undertone is that node-forward was altruistic, io.js has feeling of being subversive. People on AB were involved in node-forward but have less impact on io.js. +**IS:** Disagree. node-forward was not strictly about technical progress, but organizational progress. +**IR:** node-forward was created consensus-seeking, but io.js was unilateral. It colored the perception of the community. +**IS:** That’s describing *IS*, *BB*, and *IR* feeling, but the community doesn’t see it that way. Same people, same committee, same process, aims and objectives. Not every journalist is telling that story, but that it’s hostile. Not everyone involved in io.js is hostile. Conversation was started in August and now it’s December with little progress, understandably. +**DC:** Keep in mind Joyent leadership changed. +**SH:** I needed to build trust. +**IS:** The community actively did not trust joyent prior to *SH* arrival. Joyent position was: no changes. Not putting it on *SH*. +**SH:** Patience appreciated. +**IR:** Agreed that external perception may not have changed much. Pointing out that io.js is driven by people not at this meeting and has life of it’s own. More divergent faction than we’ve had yet and increases pressure to come up with solution that works for everybody. +**IS:** Unilateral move by Fedor and would have advised him against. +**DS:** Look at the AB as here to protect business value of Node, but io.js release pent up need of people who want to contribute to contribute. Should be wake-up call to AB to accelerate and merge streams. +**IS:** A little bit of fire under us to deliver on promise of AB. Don’t think we need to change course at this time due to io.js. Looks better for Joyent if it were able to be called “node.” io.js TC needs to come to shared understanding of messaging. No known disagreement with this sentiment amongst io.js. Should the diverge it’s not optimal. +**TM:** That would be bad for everyone, we should converge. +**CS:** Perception is very different from what *IS* described is the internal sentiment. Don’t see any help from the io.js side so mitigate perception issues as pertaining to Wired article. io.js should articulate path to re-merging, including expectations of Joyent. Be clear of road toward reconciliation, if that’s the true intent and desire. Possibly identifying it as an interim effort. +**IS:** There a couple non-temporary ways to collaborate: 1) Move code/binary kernel to io.js, with node wrapping io.js, 2) pull patches from io.js. These are non-hostile and non-competitive. Premature to commit to saying it’s temporary. +**TM:** We are making good progress; what is it that makes it possible to bring the forks back together again. +**CS:** Saying a long-term divergence is possible is difficult reconcile with AB. What’s rationale should issues get resolved. +**IS:** This is *if* the issues can’t be resolved. +**CS:** This needs to be clarified with general public that a long-term fork is only possible if issues aren’t reconciled. +**IS:** Preparing a message to clarify. There are multiple options, but don’t think anyone prefers a name change. Everyone already says “Node”. Having to say JS on the server other than Node is damaging and competition will be damaging. Could be a symbiotic relationship, but too early to tell. If issues can be resolved no reason for io.js to continue to exist. +**CS:** Good to hear and want to ensure that explanation is crisp to community. +**IS:** To be clear, I’m annoyed Fedor did this unilaterally. Agree that continuing to call it io.js is non-optimal. Would have been ideal to announce with publication of fork. +**DS:** IS covered the io.js messaging, but there’s a need for the AB to respond. +**DC:** A unified message from AB is necessary. +**DS:** Should message that the needs have been identified and we’re accelerating work toward resolving issues. +**CS:** Could the two groups put out messaging together showing unity? +**SH:** The reason behind the AB was to address conflicts head-on. We are all better off getting a slice of watermelon vs a whole grape, so we need to align around what we want Node to be. This includes community, healthy ecosystem etc. Obvious contention but this group was formed to figure it out. Sounds like resolution or progress wasn’t quick enough. Are we still interested in resolving these issues and is it still the correct course of action to prevent forking and bifurcation of the community? I feel like we finally reached a point where we were establishing trust and I’m committed to this path recognizing there is more to do here. Would like to see a true io.js messsage. +**IS:** What’s happening on social media is the community rushing to fill a vacuum. +**IR:** *SH* is coming from a position of thinking Joyent is in charge. +**IS:** I’m in the middle of multiple groups so a unique position. io.js needs to put together messaging and say what’s actually going on. A joint message is a bad idea. It makes it seem that io.js is connected with the AB. Part of motivation for io.js was for TC to do things that was not beholden to Joyent. If it appears otherwise it could be disruptive to community, some of whom don’t trust Joyent. Should say that core contributors are still working with Joyent to come to resolution. Also saying that io.js is working in public with goal to rejoin with Joyent. +**TM:** AB should say we’re working and committed to same goals as io.js and willing to work together with them. +**SH:** I have reached out to Fedor to understand. Have not heard back, but would like conversation with him. Not an issue of me feeling I’m in charge, but instead having a consistent message that we are working with community and what we’re doing is in the best interest of the direction of the project. ### Non-Corporate Ownership (Issac Roth) -**IR:** Is Joyent open to the idea of putting the website and trademark into non-corporate ownership? The fact this hasn’t been addressed is coming up as a reason why the AB is a stalling tactic or way to retain control rather than moving to true community governance. Resolution on this issue will build confidence from community. -**SH:** Trying to create a vibrant ecosystem for everyone. Trying to build point of view around foundations and what it looks like. Is there an effective model to do that? Hopefully has been consistent around messaging, actions, business model and product strategy as a mechanism to build trust. Try to build right governance model to give control to technical group and remain committed. Looking at foundation yields unanimous advice that the contention needs to be fixed and project healthy BEFORE moving to foundation, and as such has been working under that mode. That approach afford time to continue to learn pros and cons for different constituents. I am at a point where I am open to that and I’m committed to doing what’s right for Node. Gathered info from IBM and Linux foundation, Apache model or rolling own for flexibility. Ask that everyone understand objective. Has anxiety around foundation, particularly from cloud experience and snuffing out of small vendors. Impacted people see some foundations as serving only interests of large companies. What we do has to make sense for everyone on AB, but also everyone who ISN’T on AB. Want to do right thing for Node but needs to understand tradeoffs of Node, but also tradeoffs for Joyent. Accountable to board of directors, too, so time is needed to evaluate. Not opposed to it, but in fact open to it. Just want to find model that foster vibrant open ecosystem and passionate developers. Actively investigating to understand. +**IR:** Is Joyent open to the idea of putting the website and trademark into non-corporate ownership? The fact this hasn’t been addressed is coming up as a reason why the AB is a stalling tactic or way to retain control rather than moving to true community governance. Resolution on this issue will build confidence from community. +**SH:** Trying to create a vibrant ecosystem for everyone. Trying to build point of view around foundations and what it looks like. Is there an effective model to do that? Hopefully has been consistent around messaging, actions, business model and product strategy as a mechanism to build trust. Try to build right governance model to give control to technical group and remain committed. Looking at foundation yields unanimous advice that the contention needs to be fixed and project healthy BEFORE moving to foundation, and as such has been working under that mode. That approach afford time to continue to learn pros and cons for different constituents. I am at a point where I am open to that and I’m committed to doing what’s right for Node. Gathered info from IBM and Linux foundation, Apache model or rolling own for flexibility. Ask that everyone understand objective. Has anxiety around foundation, particularly from cloud experience and snuffing out of small vendors. Impacted people see some foundations as serving only interests of large companies. What we do has to make sense for everyone on AB, but also everyone who ISN’T on AB. Want to do right thing for Node but needs to understand tradeoffs of Node, but also tradeoffs for Joyent. Accountable to board of directors, too, so time is needed to evaluate. Not opposed to it, but in fact open to it. Just want to find model that foster vibrant open ecosystem and passionate developers. Actively investigating to understand. -## Summary (Erik Toth) +## Summary (Erik Toth) -## Action Items +## Action Items ### AB Position on io.js -Will be drafted by SH. -**SH:** Should be hosted on Node.js. -**CS:** Should be reviewed by AB. -**IS:** More important for io.js to clarify and AB announcement should be short and sweet. +Will be drafted by SH. +**SH:** Should be hosted on Node.js. +**CS:** Should be reviewed by AB. +**IS:** More important for io.js to clarify and AB announcement should be short and sweet. ### CoC WG -TF will setup kickoff meeting and drive this WG. - - - - -# Next Meeting -Please join our next meeting, Friday Dec 19, 2014 at 12:00 PM EST / 9:00 AM PST at -[https://global.gotomeeting.com/join/866889469](https://global.gotomeeting.com/join/866889469) or please dial-in in using your telephone. +TF will setup kickoff meeting and drive this WG. -``` -United States: +1 (626) 521-0010 -Austria: +43 (0) 7 2088 1033 -Belgium: +32 (0) 28 08 4296 -Canada: +1 (647) 497-9371 -Denmark: +45 (0) 69 91 89 21 -Finland: +358 (0) 942 41 5770 -France: +33 (0) 170 950 585 -Germany: +49 (0) 692 5736 7205 -Ireland: +353 (0) 19 030 050 -Italy: +39 0 693 38 75 50 -Netherlands: +31 (0) 208 080 208 -New Zealand: +64 (0) 9 925 0481 -Norway: +47 21 04 29 12 -Spain: +34 911 82 9890 -Sweden: +46 (0) 852 500 179 -Switzerland: +41 (0) 435 0167 65 -United Kingdom: +44 (0) 330 221 0096 -Access Code: 866-889-469 -Audio PIN: Shown after joining the meeting -Meeting ID: 866-889-469 -``` +# Next Meeting +Please join our next meeting, Friday Dec 19, 2014 at 12:00 PM EST / 9:00 AM PST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file diff --git a/meetings/2014-12-19/minutes.md b/meetings/2014-12-19/minutes.md index 6e588c1..41e6b3b 100644 --- a/meetings/2014-12-19/minutes.md +++ b/meetings/2014-12-19/minutes.md @@ -1,19 +1,19 @@ # December 19, 2014 ## Attendees -Chris Williams (CW) -Kevin Decker (KD) -Erik Toth (ET) -TJ Fontaine (TF) -Scott Hammond (SH) -Dan Shaw (DS) -Todd Moore (TM) -Issac Roth (IR) -Chris Saint-Amant (CS) -Bert Belder (BB) -Trevor Norris (TN) -Gianugo Rabellino (GR) -Danese Cooper (DC) +Chris Williams (CW) +Kevin Decker (KD) +Erik Toth (ET) +TJ Fontaine (TF) +Scott Hammond (SH) +Dan Shaw (DS) +Todd Moore (TM) +Issac Roth (IR) +Chris Saint-Amant (CS) +Bert Belder (BB) +Trevor Norris (TN) +Gianugo Rabellino (GR) +Danese Cooper (DC) @@ -24,154 +24,141 @@ Danese Cooper (DC) **TF:** Tried to release 0.11.15 but blocked by fix to 0.10.35. Should be ready to move forward with 0.11.15 on Monday. No plans for new work for 0.11.15, so 0.12 release is on schedule, e.g. will await potential new issues and release 0.12 two weeks after 0.11.15 release. ### Code of Conduct WG Status (TF) -**TM:** No meeting. -**TF:** Unable to get a time scheduled, so no status update. +**TM:** No meeting. +**TF:** Unable to get a time scheduled, so no status update. ### Trademark and Website WG Status (SH) -**SH:** Recommend multi-trademark strategy with main trademark and derivative: API compliance certification and developer certification. Recommend there is no permissible use for trademark of tradeshow materials, merchandise, etc. Derivative trademarks can be user for their respective purposes. +**SH:** Recommend multi-trademark strategy with main trademark and derivative: API compliance certification and developer certification. Recommend there is no permissible use for trademark of tradeshow materials, merchandise, etc. Derivative trademarks can be user for their respective purposes. ### Advisory Board WG Status (DS) -**DS:** In the process of getting recommendations for community members tobe added to temporary Advisory Board. Will put to current AB for vote. Have feedback and candidates, but trying to find parties that are interested and available enough to engage. Raeched out to community members who have expressed concern about board, but need people who are available to engage. +**DS:** In the process of getting recommendations for community members tobe added to temporary Advisory Board. Will put to current AB for vote. Have feedback and candidates, but trying to find parties that are interested and available enough to engage. Raeched out to community members who have expressed concern about board, but need people who are available to engage. ### Technical Committee/Governance WG Status (BB) -**BB:** First meeting got stuck on voting vs consensus so other topics were discussed: coordination of work and roadmaps. Did not come to clear resolutions, but made progress for follow up meetings. +**BB:** First meeting got stuck on voting vs consensus so other topics were discussed: coordination of work and roadmaps. Did not come to clear resolutions, but made progress for follow up meetings. ### Compliance/Certification/API WG Status (DS) -**DS:** With 0.12 will be able to define API and assertion suite as API stands now. With that will be able to define what goes into 1.0, 2.0, etc versions of Node.js. Will facilitate setting up technical session at beginning of January to make progress on the technical side. +**DS:** With 0.12 will be able to define API and assertion suite as API stands now. With that will be able to define what goes into 1.0, 2.0, etc versions of Node.js. Will facilitate setting up technical session at beginning of January to make progress on the technical side. ## Review of Action Items (CW, et. al.) ### AB Position on io.js -**SH:** Posted in website and multiple conversations occurred (DS, IS, SH, etc). Appeared to be consistent messaging. +**SH:** Posted in website and multiple conversations occurred (DS, IS, SH, etc). Appeared to be consistent messaging. ### Kickoff of CoC WG -**TF:** Did not get kicked off. No available time between other WG meetings. -**CW:** Will this happen before new year? -**TF:** Not sure about new year, but possibly before next advisory board meeting. At this point won’t try to schedule before new year. +**TF:** Did not get kicked off. No available time between other WG meetings. +**CW:** Will this happen before new year? +**TF:** Not sure about new year, but possibly before next advisory board meeting. At this point won’t try to schedule before new year. ## New Business (Private) ### Trademark and Website WG Open Discussion (Scott Hammond) -**SH:** TM arranged for attorney to review and provide guidance and was very helpful. Out of the came to recommendations mentioned earlier advocating mulitmark strategy with umbrella and derivative marks for certifications. Individually has gone through published guidelines on the Node.js website as well as other project (jQuery, Docker, Mongo, etc). I board is comfortable with WG recommendation, an attorney will update and modify current guidelines to reflect the recommendation. Seeking feedback on recommendation from advisory board. -**TF:** Is there any notion of grandfathering or explicit uses that fall under “acceptable use”? A lot is looking forward, but what has been discussed for current users. -**SH:** Good point, have ot discussed but can for next meeting. -**DS:** Much conversation was around self-certification but didn’t spend a lot of time on the primary mark, but instead defining sub-marks. -**TF:** Would like clarification on what uses fall under which marks especially with current uses and assets. Will probably fall out with exercise of updating current guidelines. -**SH:** Any other comments or considerations? otherwise, next step will be to update trademark usage guidelines. Also talked about whether or not project should charge individuals and organizations for API compliance and certification. Some project do charge to fund development activities, but tend to penalize smaller players disproportionately, so concluded that fees should not be charged at this time. -**TF:** The idea was that result would be published and community would verify. Should result not be able to be independently verified, what would happen to existing certification holder? Is there recourse? -**DS:** Not clear what cheating would actually look like. -**TF:** Concern is that people are having bad experiences with distro that claims compatibility but does not actually conform. In the scenario where compatibility is broken, what is done in that circumstance. -**TM:** When you have a mark, anytime someone is out of compliance you address that with them and there is either a period of time to correct or they are asked to stop using the mark. -**SH:** Also discussed expanding role to cover governance for non-technical issues, such as disciplinary actions re: trademark, conferences, sanctioned summit or “trade show”. Also discussed working with NodeSummit organization to make progress in that direction, possibly looking to get involved more heavily in the upcoming NodeSummit. Other non-technical issues involved fundraising, etc. -**CW:** As a conf organizer, interested in the idea of anointing one conference and would this have geographical boundaries? One per country? Continent? -**SH:** Idea is to designate one singular summit but there could be room for regional ones, but this is from initial discussion. -**IR:** Discussion was that we wanted an annual conference, but recognized one already existed so rather than competing look to merge. Intention to create a new event out of both efforts. -**DS:** Especially with concern to timing of the upcoming event and ease of bootstrapping. -**IR:** There’s a disconnect, so need to understand anointing an existing thing or creation of a new one. -**DS:** Charles is open to expansion and exposure, but unsure that path of working with NodeSummit is the long term goal. Too early to tell. -**IR:** Tried to set up conversation with Charles prior to this meeting, but were unable to. -**DS:** Can we talk more about non-technical contributions of WG/AB? -**IR:** Should WGs be renamed or merged? -**TF:** Should the same CoC cover both technical contributions and conferences/non-technical issues? Needs to be discussed. -Proposal to keep the CoC working group separate from this expanded non-technical WG. -**BB:** Is there a draft or summary of direction so far as looking forward to Node 2.0 seems premature re: API compliance? -**DS:** Yes, will furnish notes and will call technical meeting which will include BB. -**TF:** More than anything we have a list of questions. Not trying to decide the mechanism, but putting together a skeleton/framework to bring to advisory board for certification. -**DS:** Re: Advisory Board WG will not define charter, but will make membership recommendations. -**IS:** Certification WG is a long term so will exist. Certification wants more responsibility. Allow CoC to run to completion and blend into non-technical WG. Trademark WG will also run to completion. End up with Certification, Technical and Non-Technical WG. -**SH:** TM has examples of community-involved WG? We want to hear customers/community loud and clear. -**TM:** Projects are more successful if community has view into board or foundation. Would ask users to form a WG that would officially funnel community feedback into board or foundation. These would be people who are trusted in the community to represent their interests. Found to be useful to engage the whole user base. -**DS:** Sounds like AB Charter WG could work with non-corporate contributing parties to get more involvement. -**TM:** Also can use surveys or other outreach mechanisms. +**SH:** TM arranged for attorney to review and provide guidance and was very helpful. Out of the came to recommendations mentioned earlier advocating mulitmark strategy with umbrella and derivative marks for certifications. Individually has gone through published guidelines on the Node.js website as well as other project (jQuery, Docker, Mongo, etc). I board is comfortable with WG recommendation, an attorney will update and modify current guidelines to reflect the recommendation. Seeking feedback on recommendation from advisory board. +**TF:** Is there any notion of grandfathering or explicit uses that fall under “acceptable use”? A lot is looking forward, but what has been discussed for current users. +**SH:** Good point, have ot discussed but can for next meeting. +**DS:** Much conversation was around self-certification but didn’t spend a lot of time on the primary mark, but instead defining sub-marks. +**TF:** Would like clarification on what uses fall under which marks especially with current uses and assets. Will probably fall out with exercise of updating current guidelines. +**SH:** Any other comments or considerations? otherwise, next step will be to update trademark usage guidelines. Also talked about whether or not project should charge individuals and organizations for API compliance and certification. Some project do charge to fund development activities, but tend to penalize smaller players disproportionately, so concluded that fees should not be charged at this time. +**TF:** The idea was that result would be published and community would verify. Should result not be able to be independently verified, what would happen to existing certification holder? Is there recourse? +**DS:** Not clear what cheating would actually look like. +**TF:** Concern is that people are having bad experiences with distro that claims compatibility but does not actually conform. In the scenario where compatibility is broken, what is done in that circumstance. +**TM:** When you have a mark, anytime someone is out of compliance you address that with them and there is either a period of time to correct or they are asked to stop using the mark. +**SH:** Also discussed expanding role to cover governance for non-technical issues, such as disciplinary actions re: trademark, conferences, sanctioned summit or “trade show”. Also discussed working with NodeSummit organization to make progress in that direction, possibly looking to get involved more heavily in the upcoming NodeSummit. Other non-technical issues involved fundraising, etc. +**CW:** As a conf organizer, interested in the idea of anointing one conference and would this have geographical boundaries? One per country? Continent? +**SH:** Idea is to designate one singular summit but there could be room for regional ones, but this is from initial discussion. +**IR:** Discussion was that we wanted an annual conference, but recognized one already existed so rather than competing look to merge. Intention to create a new event out of both efforts. +**DS:** Especially with concern to timing of the upcoming event and ease of bootstrapping. +**IR:** There’s a disconnect, so need to understand anointing an existing thing or creation of a new one. +**DS:** Charles is open to expansion and exposure, but unsure that path of working with NodeSummit is the long term goal. Too early to tell. +**IR:** Tried to set up conversation with Charles prior to this meeting, but were unable to. +**DS:** Can we talk more about non-technical contributions of WG/AB? +**IR:** Should WGs be renamed or merged? +**TF:** Should the same CoC cover both technical contributions and conferences/non-technical issues? Needs to be discussed. +Proposal to keep the CoC working group separate from this expanded non-technical WG. +**BB:** Is there a draft or summary of direction so far as looking forward to Node 2.0 seems premature re: API compliance? +**DS:** Yes, will furnish notes and will call technical meeting which will include BB. +**TF:** More than anything we have a list of questions. Not trying to decide the mechanism, but putting together a skeleton/framework to bring to advisory board for certification. +**DS:** Re: Advisory Board WG will not define charter, but will make membership recommendations. +**IS:** Certification WG is a long term so will exist. Certification wants more responsibility. Allow CoC to run to completion and blend into non-technical WG. Trademark WG will also run to completion. End up with Certification, Technical and Non-Technical WG. +**SH:** TM has examples of community-involved WG? We want to hear customers/community loud and clear. +**TM:** Projects are more successful if community has view into board or foundation. Would ask users to form a WG that would officially funnel community feedback into board or foundation. These would be people who are trusted in the community to represent their interests. Found to be useful to engage the whole user base. +**DS:** Sounds like AB Charter WG could work with non-corporate contributing parties to get more involvement. +**TM:** Also can use surveys or other outreach mechanisms. ### Scheduling -**DC:** Could we find a person to lead scheduling of WG meeting as then can have better oversight of schedules across WGs. -**CW:** Goal is to schedule out AB meetings far in advance. -**TF:** Propose longer time between AB meetings such that WG have more opportunity to work. -**IR:** Feel like WG are making progress. -**DC:** it’s important to keep community engaged, so frequency helps that. -**TF:** Have WG schedule their own time and publish proposals, information. -**IR:** Propose monthly cadence for AB and wrap up WG in next 2 meetings. -**TF:** In the interim provide an executive summary in GitHub of WG meetings. -**DC:** Yes, just don’t want the appearance that the AB went dark. -**SH:** Possibly keep current cadence (every other week) but schedule shorter meetings: 1 hour. -**CW:** Yes, 2 week cadence after new year. When would be best to start new year. -**SH:** Probably second week of new year. -**DC:** Agreed. -**CW:** Please participate in doodles as quickly as possible. -**SH:** 15 minutes public and 45 minutes private. +**DC:** Could we find a person to lead scheduling of WG meeting as then can have better oversight of schedules across WGs. +**CW:** Goal is to schedule out AB meetings far in advance. +**TF:** Propose longer time between AB meetings such that WG have more opportunity to work. +**IR:** Feel like WG are making progress. +**DC:** it’s important to keep community engaged, so frequency helps that. +**TF:** Have WG schedule their own time and publish proposals, information. +**IR:** Propose monthly cadence for AB and wrap up WG in next 2 meetings. +**TF:** In the interim provide an executive summary in GitHub of WG meetings. +**DC:** Yes, just don’t want the appearance that the AB went dark. +**SH:** Possibly keep current cadence (every other week) but schedule shorter meetings: 1 hour. +**CW:** Yes, 2 week cadence after new year. When would be best to start new year. +**SH:** Probably second week of new year. +**DC:** Agreed. +**CW:** Please participate in doodles as quickly as possible. +**SH:** 15 minutes public and 45 minutes private. ## Node 0.12 -**IR:** Early January release and io.js is second week of Jan. This isn’t inline for the good of the greater community. -**TF:** They are different. Different version for v8 for example. Node.js team is reticent to upgrade v8 this late in the game. Please for io.js was to release on Fedor’s birthday, but not sure how to reconcile. -**BB:** looks like AB is going somewhere, so long term io.js and node need to become one project again. Does anyone have a feeling for a timeline of AB decisions to go into effect? -**SH:** Which things in particular are you interested in? -**BB:** Project governance, new charter or foundation. Not saying it has to be in place before projects can merge but there are few concrete achievements out of the AB. Formally Node is still being run that same as always, so a timeline for change would enable process of messaging and thinking about merge. -**SH:** Re: governance sounds like group agreed to consensus-seeking and openness. -**TF:** Yes, core team has recorded meetings, just needs to publish. -**SH:** Moving on those things now. Around governance if there are other things you want to see the WG is in place. If there are things they need to act on sooner let’s go do them. Recommendation would be that people who are already on project team continue working and open to additional people. if necessary, expand project team to merge with io.js if there is a contributor delta. We can do that now. Make decisions and act now. -**BB:** We’re not in complete agreement, specifically around voting. Assuming this is possible to work out, the question is what will happen to the work done so far on io.js? Will every change need to be discussed again? Will Ben be working on Node? Will build system be moved over? On io.js there’s no one owner so Bert will have to make case to convince group. Need concrete change to point to if he hopes to make that case to the team. Very much in favor of working toward that. -**SH:** Great to hear. Sounds like there are specific issues that need to be resolved to lets get on the phone and make decisions and take concrete steps to accomplish them. I trust if we walk through this that the intentions are to work on one, community-driven Node.js project. -**BB:** There was a lot of additional interest in io.js, so what is communicated to new participants. -**TM:** We want all that energy in one place, so if there’s a discrete list of items needed to do that let’s go work on that. -**IR:** Maybe a new tooling/build system WG needs to be formed. In other projects control over the build system is a big deal. Point of security and trust and needs to be thoughtfully governed. -**TM:** It’s build and test, especially when moving toward compatibility tests. -**TF:** Agree we need to solve this, but does this affect the release proximity problem? -**SH:** Let’s find a way to have the groups work together soon. -**IR:** Concerned the io.js team will not reconcile with Node.js until they know its in a community-owned place. -**TM:** Would it help to be more public? -**BB:** It doesn’t need to be completely in place, but it needs to be clearly laid out. -**TM:** Maybe a blog post? -**BB:** From a practical perspective I want to merge projects now. See that Node.js is making progress and it’s possible. Would prefer not to have parallel efforts. Will enumerate list. -**SH:** Can we target a date for a call to work through path to resolve issues. -**BB:** Will probably be early January. -**SH:** Please send list of attendees so we can get the group together ASAP. -**IR:** Does build system require WG? DS has worked toward it a lot. -**DS:** Don’t want to slow it down via political process. -**TF:** Definitely room for improvement but what we have works. -**IR:** We need a neutral community build infra. -**SH:** I don’t care what’s used as long as it fulfills technical needs and works toward community owned. -**TF:** One concern is the parts of the system that require Joyent owned private keys. Those pieces need to be more secure and represent trust in builds. -**DC:** Sounds like one of the topics that needs to be hashed out as we design home for Node.js that is amenable to both sides. Need to focus on list of needs rather than bikeshed on individual topics. Agrees that build system is a need; are there other topics? -**BB:** Yes, additional things are role of project leadership/TC. Do they define roadmap? Even sidestepping voting vs consensus would be good to define technical roles and figure out how to define roadmap, scheduling releases, meeting deadlines, etc. Does not want to throw away all work io.js has done toward these goals. Would like node to use community maintained build system. -**DS:** Is is possible to gap between build and release? Need broader build coverage and testing, but then there’s blessed Node.js release. -**TF:** So long as supported platform matrix doesn’t change. -**DS:** One goal is to improve matrix. -**TF:** Want to clarify build vs release. There’s a wider desire for expanded support matrix. The blocker is not necessarily the build infra, but the expertise to validate against new platforms. A broader conversation needs to be had, but not concerned with the actual location of build infra. -**BB:** Agree and understand with matrix. io.js is not merely about supporting more platforms, that’s a minor point. It’s more important for making developers more effective. Also, will supply a group of people to work on this so TF isn’t solely responsible. -**TF:** Definitely want that help, no argument on me there. -**SH:** Sounds like BB will pull together list of issues along with participants to resolve them. +**IR:** Early January release and io.js is second week of Jan. This isn’t inline for the good of the greater community. +**TF:** They are different. Different version for v8 for example. Node.js team is reticent to upgrade v8 this late in the game. Please for io.js was to release on Fedor’s birthday, but not sure how to reconcile. +**BB:** looks like AB is going somewhere, so long term io.js and node need to become one project again. Does anyone have a feeling for a timeline of AB decisions to go into effect? +**SH:** Which things in particular are you interested in? +**BB:** Project governance, new charter or foundation. Not saying it has to be in place before projects can merge but there are few concrete achievements out of the AB. Formally Node is still being run that same as always, so a timeline for change would enable process of messaging and thinking about merge. +**SH:** Re: governance sounds like group agreed to consensus-seeking and openness. +**TF:** Yes, core team has recorded meetings, just needs to publish. +**SH:** Moving on those things now. Around governance if there are other things you want to see the WG is in place. If there are things they need to act on sooner let’s go do them. Recommendation would be that people who are already on project team continue working and open to additional people. if necessary, expand project team to merge with io.js if there is a contributor delta. We can do that now. Make decisions and act now. +**BB:** We’re not in complete agreement, specifically around voting. Assuming this is possible to work out, the question is what will happen to the work done so far on io.js? Will every change need to be discussed again? Will Ben be working on Node? Will build system be moved over? On io.js there’s no one owner so Bert will have to make case to convince group. Need concrete change to point to if he hopes to make that case to the team. Very much in favor of working toward that. +**SH:** Great to hear. Sounds like there are specific issues that need to be resolved to lets get on the phone and make decisions and take concrete steps to accomplish them. I trust if we walk through this that the intentions are to work on one, community-driven Node.js project. +**BB:** There was a lot of additional interest in io.js, so what is communicated to new participants. +**TM:** We want all that energy in one place, so if there’s a discrete list of items needed to do that let’s go work on that. +**IR:** Maybe a new tooling/build system WG needs to be formed. In other projects control over the build system is a big deal. Point of security and trust and needs to be thoughtfully governed. +**TM:** It’s build and test, especially when moving toward compatibility tests. +**TF:** Agree we need to solve this, but does this affect the release proximity problem? +**SH:** Let’s find a way to have the groups work together soon. +**IR:** Concerned the io.js team will not reconcile with Node.js until they know its in a community-owned place. +**TM:** Would it help to be more public? +**BB:** It doesn’t need to be completely in place, but it needs to be clearly laid out. +**TM:** Maybe a blog post? +**BB:** From a practical perspective I want to merge projects now. See that Node.js is making progress and it’s possible. Would prefer not to have parallel efforts. Will enumerate list. +**SH:** Can we target a date for a call to work through path to resolve issues. +**BB:** Will probably be early January. +**SH:** Please send list of attendees so we can get the group together ASAP. +**IR:** Does build system require WG? DS has worked toward it a lot. +**DS:** Don’t want to slow it down via political process. +**TF:** Definitely room for improvement but what we have works. +**IR:** We need a neutral community build infra. +**SH:** I don’t care what’s used as long as it fulfills technical needs and works toward community owned. +**TF:** One concern is the parts of the system that require Joyent owned private keys. Those pieces need to be more secure and represent trust in builds. +**DC:** Sounds like one of the topics that needs to be hashed out as we design home for Node.js that is amenable to both sides. Need to focus on list of needs rather than bikeshed on individual topics. Agrees that build system is a need; are there other topics? +**BB:** Yes, additional things are role of project leadership/TC. Do they define roadmap? Even sidestepping voting vs consensus would be good to define technical roles and figure out how to define roadmap, scheduling releases, meeting deadlines, etc. Does not want to throw away all work io.js has done toward these goals. Would like node to use community maintained build system. +**DS:** Is is possible to gap between build and release? Need broader build coverage and testing, but then there’s blessed Node.js release. +**TF:** So long as supported platform matrix doesn’t change. +**DS:** One goal is to improve matrix. +**TF:** Want to clarify build vs release. There’s a wider desire for expanded support matrix. The blocker is not necessarily the build infra, but the expertise to validate against new platforms. A broader conversation needs to be had, but not concerned with the actual location of build infra. +**BB:** Agree and understand with matrix. io.js is not merely about supporting more platforms, that’s a minor point. It’s more important for making developers more effective. Also, will supply a group of people to work on this so TF isn’t solely responsible. +**TF:** Definitely want that help, no argument on me there. +**SH:** Sounds like BB will pull together list of issues along with participants to resolve them. ### Additional Needs (SH) -**SH:** What else should we be working on? -**DS:** Step up effort for community involvement. -**BB:** Engagement from other groups like TC39. +**SH:** What else should we be working on? +**DS:** Step up effort for community involvement. +**BB:** Engagement from other groups like TC39. ## New Action Items -Use GitHub to solicit questions for the next Advisory Board Meeting. -Schedule next meeting (most likely 3 weeks out). 2 week cadence, shorter meetings. (CW) -Merge meeting minutes PR (TF: Anyone can merge and core team will update website.) -Enumerate specific issues to be resolved to establish best chance of io.js and node to unify into a single project (BB) +Use GitHub to solicit questions for the next Advisory Board Meeting. +Schedule next meeting (most likely 3 weeks out). 2 week cadence, shorter meetings. (CW) +Merge meeting minutes PR (TF: Anyone can merge and core team will update website.) +Enumerate specific issues to be resolved to establish best chance of io.js and node to unify into a single project (BB) ## Next Meeting -Please join our next meeting, Wednesday Jan 14, 2015 at 4:00 PM EST / 1:00 AM PST at -[https://global.gotomeeting.com/join/524998381](https://global.gotomeeting.com/join/524998381) or please dial-in in using your telephone. - -``` -Please join my meeting from your computer, tablet or smartphone. -https://global.gotomeeting.com/join/524998381 - -You can also dial in using your phone. -United States (Long distance): +1 (646) 749-3122 -Access Code: 524-998-381 -More phone numbers: https://global.gotomeeting.com/524998381/numbersdisplay.html - - -``` +Please join our next meeting, Wednesday Jan 14, 2015 at 4:00 PM EST / 1:00 AM PST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file diff --git a/meetings/2015-01-14/minutes.md b/meetings/2015-01-14/minutes.md index 276dc67..0b904be 100644 --- a/meetings/2015-01-14/minutes.md +++ b/meetings/2015-01-14/minutes.md @@ -1,161 +1,134 @@ # January 14, 2015 ## Attendees -Chris Williams (CW) -Erik Toth (ET) -TJ Fontaine (TF) -Scott Hammond (SH) -Todd Moore (TM) -Dan Shaw (DS) -Isaac Schlueter (IS) -TJ Fontaine (TF) -Chris Saint-Amant (CS) -Danese Cooper (DC) -Cian O'Maiden (CO) -Gianugo Rabellino (GR) -Bert Belder (BB) -Issac Roth (IR) -Trevor Norris (TN) +Chris Williams (CW) +Erik Toth (ET) +TJ Fontaine (TF) +Scott Hammond (SH) +Todd Moore (TM) +Dan Shaw (DS) +Isaac Schlueter (IS) +TJ Fontaine (TF) +Chris Saint-Amant (CS) +Danese Cooper (DC) +Cian O'Maiden (CO) +Gianugo Rabellino (GR) +Bert Belder (BB) +Issac Roth (IR) +Trevor Norris (TN) ## Public Recap ### Review Previous Meeting Minutes (CW) -[2014-12-19 Meeting Minutes](https://github.com/joyent/nodejs-advisory-board/blob/baf4891436da11ed681d21464a267b9a2a8f9ad5/meetings/2014-12-19/minutes.md) +[2014-12-19 Meeting Minutes](https://github.com/joyent/nodejs-advisory-board/blob/baf4891436da11ed681d21464a267b9a2a8f9ad5/meetings/2014-12-19/minutes.md) ### Node 0.12 Status (TF) -**TF:** Julian posted project plan. Continuing to work through finishing last PRs. 0.10.36/0.11.15 released this week. -**DS:** Can it be cross-posted? -**TF:** Moved to generic google groups list. Just need to make it public. +**TF:** Julian posted project plan. Continuing to work through finishing last PRs. 0.10.36/0.11.15 released this week. +**DS:** Can it be cross-posted? +**TF:** Moved to generic google groups list. Just need to make it public. -### Review of Open Action Items (CW, et. al.) -**SH:** Trademark, IP and Website group met. Recommendations got no additional feedback, so next step is to update existing guidelines and codify recommendations. ALso discussed working closer with NodeSummit. Spoke with Charles. Good alignment among groups to drive participation and sessions at upcoming NodeSummit. -**DS:** Allocated time on Monday at NodeSummit. -**DS:** Technical kickoff for compliance hoped to kick off in January, but wasn’t able to make it happen. -**SH:** Is there a Doodle poll? -**DS:** Not yet. Will do. Will follow up. Both NodeSource and StrongLoop are ready to move forward. +### Review of Open Action Items (CW, et. al.) +**SH:** Trademark, IP and Website group met. Recommendations got no additional feedback, so next step is to update existing guidelines and codify recommendations. ALso discussed working closer with NodeSummit. Spoke with Charles. Good alignment among groups to drive participation and sessions at upcoming NodeSummit. +**DS:** Allocated time on Monday at NodeSummit. +**DS:** Technical kickoff for compliance hoped to kick off in January, but wasn’t able to make it happen. +**SH:** Is there a Doodle poll? +**DS:** Not yet. Will do. Will follow up. Both NodeSource and StrongLoop are ready to move forward. ### Open Public Discussion -No topics raised. +No topics raised. ## New Business (Private) -### Review of Open Action Items (CW, et. al.) +### Review of Open Action Items (CW, et. al.) #### NodeSummit Planning -**DC:** CSA asked what other open source organizations do -**IR:** Is the idea for that to be monday? -**DC:** No, panel is meant to be during regular run. IIRC Monday was more about tutorials. We had asked for real meeting of board and were told that would work. -**IR:** Seems like there are a lot of thing on hold or anticipating formation of future entity. Is that actually happening and can people help out? -**DC:** There is action that’s under way. There’s some well-understood steps. -**SH:** Will cover shortly as separate agenda item. -**DS:** We have a boardroom reserved on Monday and separate space on the afternoon of February 9. -**CS:** Isn’t NodeSummit 10th and 11th? -**DS:** It is but the day before is allocated for hardware workshoppy things, node school workshop, vendor workshops. Public boardroom slot is available to us. -**CS:** When will Monday schedule be posted? For workshops, etc? -**SH:** We should anticipate a larger group (more than 40 people) and schedule for Tuesday. -**TJ:** as far as the agenda, that is up to nodesummit should be this week. -**DS:** going into tuesday and wednesday will be hard as there will be events from 9-5. there is space carved out for the board to do boardy things. Monday is for watching people talk. -**SH:** Do we want to have people watch the board have a meeting. -**DC:** I think it’s an artificial distinction. Everyone knows these things require certain work. We should be grownups and talk about it aspirationally if we must. -**SH:** My sense is that this will probably be people wanting details. We need to figure out the right way to go answer those. -**DS:** I believe there is stage time for answering questions. Not watching the board, but QA/panel. -**IS:** Won’t be another chance until NodeConf. -**SH:** As long as there is time, we want to do that, we want to get feedback and engage. -**DS:** I’m happy to take an action item , but I know Charles is blocking off time for TBD things to have on stage Tuesday or Wednesday. +**DC:** CSA asked what other open source organizations do +**IR:** Is the idea for that to be monday? +**DC:** No, panel is meant to be during regular run. IIRC Monday was more about tutorials. We had asked for real meeting of board and were told that would work. +**IR:** Seems like there are a lot of thing on hold or anticipating formation of future entity. Is that actually happening and can people help out? +**DC:** There is action that’s under way. There’s some well-understood steps. +**SH:** Will cover shortly as separate agenda item. +**DS:** We have a boardroom reserved on Monday and separate space on the afternoon of February 9. +**CS:** Isn’t NodeSummit 10th and 11th? +**DS:** It is but the day before is allocated for hardware workshoppy things, node school workshop, vendor workshops. Public boardroom slot is available to us. +**CS:** When will Monday schedule be posted? For workshops, etc? +**SH:** We should anticipate a larger group (more than 40 people) and schedule for Tuesday. +**TJ:** as far as the agenda, that is up to nodesummit should be this week. +**DS:** going into tuesday and wednesday will be hard as there will be events from 9-5. there is space carved out for the board to do boardy things. Monday is for watching people talk. +**SH:** Do we want to have people watch the board have a meeting. +**DC:** I think it’s an artificial distinction. Everyone knows these things require certain work. We should be grownups and talk about it aspirationally if we must. +**SH:** My sense is that this will probably be people wanting details. We need to figure out the right way to go answer those. +**DS:** I believe there is stage time for answering questions. Not watching the board, but QA/panel. +**IS:** Won’t be another chance until NodeConf. +**SH:** As long as there is time, we want to do that, we want to get feedback and engage. +**DS:** I’m happy to take an action item , but I know Charles is blocking off time for TBD things to have on stage Tuesday or Wednesday. ### Organization (SH, JZ) -_Deck Presented by SH_ -_Slide 2_ -**SH:** Quick update on organization and solicit feedback. Want to ensure this is drive by and for community and articulating correct mission statement and architecting with what we need. At 0.9 release of MOU. -**TM:** Need to get something out this week. -**SH:** Slides are for internal consumption for now pending feedback from AB. -**CW:** Probably want to avoid discussing “merit” without specific details as to how it’s defined. -**DC:** Can it be “technical contribution”? -**SH:** Changed! So the idea is to have it driven by community who all want to promote increased adoption and development of Node.js. First pass of mission statement. Feedback welcome. -_Slide 3_ -**IS:** Please send to group. Will process it and provide feedback. -**CS:** Or add to Google doc for commenting. -**SH:** Will throw in Google Docs. -**DS:** Has anyone done a scan for “Node” the trademark? -**BB:** Reads that it’s about things related to Node.js, but not Node.js itself. -**CS:** There’s some value in that subjectivity. There’s clear stewardship in Node.js itself, but expanding to community/ecosystem is helpful. That general motivation could be a healthy thing. -**IS:** I strongly disagree with this. We’re not outfitted to support or know about everything that is being done with Node. The purpose isn’t specific libaries, it’s to ensure node is great and support and empower those working in it. -**CA:** You could also argue that it’s a strong core but that’s subjective depending on who’s using it for what. -**SH:** Initially we want to focus on Node.js. Then are there related projects we should pull under the umbrella? -**IS:** We don’t want to limit ourselves, but it could be reworded. “Node.js and associated projects.” -**TF:** I’ve talked to module owners who are looking to transfer ownership. -**IS:** Are the technical folks eager to own other people’s code. -**SH:** If a project is added it must have a lead and be staffed. -**IS:** I think “Node.js and related projects” leaves that door open, but leaves escape hatch for denying unrelated works. -**CS:** That’s at the discretion of the technical committee and board. -**TM:** And there are those who may have legal questions and need someone to talk to. -**IS:** For example, code that parses Excel files. -**TM:** We shouldn’t have to rewrite mission statement later. Make it broad enough to cover these cases. -**CS:** That was my original point; keep it broad. -**SH:** Had conversations with TN, TF, and BB regarding services or staffing. Want to make sure those are captured such that we can put the funding to good use. -_Slide 4_ -**TN:** What does the certification program entail? -**IR:** There’s a dedicated WG -**JZ:** 2 hours hands on, proctored exam. -**TN:** Please excuse my anti-academic-ness. I suck at testing, so the idea of testing doesn’t still well. -**DC:** Not actually how it works. Self-administered, automated thing to ensure you’re not breaking things. -**TM:** For people taking Node and using it at work to show their management. -**DS:** Not for you, Trevor. -**TN:** I’m in a unique position, but there are many like me who do not learn in this way. -**SH:** You aren’t unique in that way. There are a lot of devs who have taken a different path. Maybe we need to find a way to accommodate different paths to get there. -**IR:** Before we discussed leaving these details out initially. -**TM:** Really just a range of possibilities. -**JZ:** It’s not a small investment, but really an aspirational goal. Incentivises people to increase their skills. There will be different ways for devs to prove their worth. -**DS:** Companies will determine the worth. -**IR:** We do this already. Some care, some don’t -**SH:** Will post for comments, but please review soon. We do want to accommodate whole community so if things needs to be added, we’ll do it. A mentoring program was suggested, so that should be added. -**DS:** I would like to kick that (mentorship) off on that Monday (NodeSummit). +_Deck Presented by SH_ +_Slide 2_ +**SH:** Quick update on organization and solicit feedback. Want to ensure this is drive by and for community and articulating correct mission statement and architecting with what we need. At 0.9 release of MOU. +**TM:** Need to get something out this week. +**SH:** Slides are for internal consumption for now pending feedback from AB. +**CW:** Probably want to avoid discussing “merit” without specific details as to how it’s defined. +**DC:** Can it be “technical contribution”? +**SH:** Changed! So the idea is to have it driven by community who all want to promote increased adoption and development of Node.js. First pass of mission statement. Feedback welcome. +_Slide 3_ +**IS:** Please send to group. Will process it and provide feedback. +**CS:** Or add to Google doc for commenting. +**SH:** Will throw in Google Docs. +**DS:** Has anyone done a scan for “Node” the trademark? +**BB:** Reads that it’s about things related to Node.js, but not Node.js itself. +**CS:** There’s some value in that subjectivity. There’s clear stewardship in Node.js itself, but expanding to community/ecosystem is helpful. That general motivation could be a healthy thing. +**IS:** I strongly disagree with this. We’re not outfitted to support or know about everything that is being done with Node. The purpose isn’t specific libaries, it’s to ensure node is great and support and empower those working in it. +**CA:** You could also argue that it’s a strong core but that’s subjective depending on who’s using it for what. +**SH:** Initially we want to focus on Node.js. Then are there related projects we should pull under the umbrella? +**IS:** We don’t want to limit ourselves, but it could be reworded. “Node.js and associated projects.” +**TF:** I’ve talked to module owners who are looking to transfer ownership. +**IS:** Are the technical folks eager to own other people’s code. +**SH:** If a project is added it must have a lead and be staffed. +**IS:** I think “Node.js and related projects” leaves that door open, but leaves escape hatch for denying unrelated works. +**CS:** That’s at the discretion of the technical committee and board. +**TM:** And there are those who may have legal questions and need someone to talk to. +**IS:** For example, code that parses Excel files. +**TM:** We shouldn’t have to rewrite mission statement later. Make it broad enough to cover these cases. +**CS:** That was my original point; keep it broad. +**SH:** Had conversations with TN, TF, and BB regarding services or staffing. Want to make sure those are captured such that we can put the funding to good use. +_Slide 4_ +**TN:** What does the certification program entail? +**IR:** There’s a dedicated WG +**JZ:** 2 hours hands on, proctored exam. +**TN:** Please excuse my anti-academic-ness. I suck at testing, so the idea of testing doesn’t still well. +**DC:** Not actually how it works. Self-administered, automated thing to ensure you’re not breaking things. +**TM:** For people taking Node and using it at work to show their management. +**DS:** Not for you, Trevor. +**TN:** I’m in a unique position, but there are many like me who do not learn in this way. +**SH:** You aren’t unique in that way. There are a lot of devs who have taken a different path. Maybe we need to find a way to accommodate different paths to get there. +**IR:** Before we discussed leaving these details out initially. +**TM:** Really just a range of possibilities. +**JZ:** It’s not a small investment, but really an aspirational goal. Incentivises people to increase their skills. There will be different ways for devs to prove their worth. +**DS:** Companies will determine the worth. +**IR:** We do this already. Some care, some don’t +**SH:** Will post for comments, but please review soon. We do want to accommodate whole community so if things needs to be added, we’ll do it. A mentoring program was suggested, so that should be added. +**DS:** I would like to kick that (mentorship) off on that Monday (NodeSummit). ### Path to Merge io.js and Node.js (SH, BB, TF) -**TF:** BB and I discussed prior to Christmas. -**BB:** I don’t have notes available, but highlights are potential issues in Node.js program operation, how can the team be organized better, and how to define roadmap. As for this discussion, merging would be possible or at least the projects could work together in a structured way. BB and IS consistently say they expect the projects to unify, but the other contributors don’t believe the AB will produce anything good so they see it as theoretical. That said WRT NodeSummit there should be a concrete plan. Should current node contributors contribute to iojs with the expectation that iojs get folded back into node.js. Operationally iojs is working better. When the change actually happens, rename or better definition could happen. -**TF:** One goal is to define roadmap, so best thing is to have the roadmap conversation. If there are things in existing projects that have proven ideas that fit the roadmap, they should be integrated back into Node.js. There have been multiple ideas for workshop time, but maybe roadmap talk would be more interesting than board meeting, ultimately leading to a technical summit. -**DS:** I don’t think those things are mutually exclusive. -**IS:** If we’re talking about merging iojs into Node, it’s pretty straighforward. Fix governance, foundation, and releases then they could merge. Those take time and that’s understood. Been forthcoming that the hope and intention is to merge project. -**IR:** Sounds like TJ was suggesting a community forum and technical discussion around merge and roadmap. -**TF:** It’s a broader conversation. +**TF:** BB and I discussed prior to Christmas. +**BB:** I don’t have notes available, but highlights are potential issues in Node.js program operation, how can the team be organized better, and how to define roadmap. As for this discussion, merging would be possible or at least the projects could work together in a structured way. BB and IS consistently say they expect the projects to unify, but the other contributors don’t believe the AB will produce anything good so they see it as theoretical. That said WRT NodeSummit there should be a concrete plan. Should current node contributors contribute to iojs with the expectation that iojs get folded back into node.js. Operationally iojs is working better. When the change actually happens, rename or better definition could happen. +**TF:** One goal is to define roadmap, so best thing is to have the roadmap conversation. If there are things in existing projects that have proven ideas that fit the roadmap, they should be integrated back into Node.js. There have been multiple ideas for workshop time, but maybe roadmap talk would be more interesting than board meeting, ultimately leading to a technical summit. +**DS:** I don’t think those things are mutually exclusive. +**IS:** If we’re talking about merging iojs into Node, it’s pretty straighforward. Fix governance, foundation, and releases then they could merge. Those take time and that’s understood. Been forthcoming that the hope and intention is to merge project. +**IR:** Sounds like TJ was suggesting a community forum and technical discussion around merge and roadmap. +**TF:** It’s a broader conversation. ## New Action Items -**SH:** Post Discussion Deck to Google Docs -**TJ:** Short-term WG for completing discussion on iojs/Node.js merge. +**SH:** Post Discussion Deck to Google Docs +**TJ:** Short-term WG for completing discussion on iojs/Node.js merge. ## Next Meeting -Please join our next meeting, Thursday Jan 29, 2015 at 12:00 PM PST / 3:00 PM EST at https://global.gotomeeting.com/join/524998381 or please dial-in in using your telephone. - - -``` -United States: +1 (626) 521-0010 -Austria: +43 (0) 7 2088 1033 -Belgium: +32 (0) 28 08 4296 -Canada: +1 (647) 497-9371 -Denmark: +45 (0) 69 91 89 21 -Finland: +358 (0) 942 41 5770 -France: +33 (0) 170 950 585 -Germany: +49 (0) 692 5736 7205 -Ireland: +353 (0) 19 030 050 -Italy: +39 0 693 38 75 50 -Netherlands: +31 (0) 208 080 208 -New Zealand: +64 (0) 9 925 0481 -Norway: +47 21 04 29 12 -Spain: +34 911 82 9890 -Sweden: +46 (0) 852 500 179 -Switzerland: +41 (0) 435 0167 65 -United Kingdom: +44 (0) 330 221 0096 - -Access Code: 273-347-861 -Audio PIN: Shown after joining the meeting - -Meeting ID: 273-347-861 - -``` +Please join our next meeting, Thursday Jan 29, 2015 at 12:00 PM PST / 3:00 PM EST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file diff --git a/meetings/2015-01-29/minutes.md b/meetings/2015-01-29/minutes.md index d39740c..05faa3c 100644 --- a/meetings/2015-01-29/minutes.md +++ b/meetings/2015-01-29/minutes.md @@ -1,20 +1,20 @@ # Joyent Node.js Advisory Board Meeting Minutes - January 29, 2015 ## Attendees -Chris Williams (CW) -Erik Toth (ET) -Todd Moore (TM) -Kevin Decker (KD) -Cian O'Maiden (CO) -Issac Roth (IR) -Scott Hammond (SH) -Danese Cooper (DC) -TJ Fontaine (TF) -Dan Shaw (DS) -Jim Zemlin (JZ) -Bert Belder (BB) -Isaac Schlueter (IS) -Chris Saint-Amant (CS) +Chris Williams (CW) +Erik Toth (ET) +Todd Moore (TM) +Kevin Decker (KD) +Cian O'Maiden (CO) +Issac Roth (IR) +Scott Hammond (SH) +Danese Cooper (DC) +TJ Fontaine (TF) +Dan Shaw (DS) +Jim Zemlin (JZ) +Bert Belder (BB) +Isaac Schlueter (IS) +Chris Saint-Amant (CS) ## Public Recap @@ -23,23 +23,23 @@ Chris Saint-Amant (CS) [2014-01-14 Meeting Minutes](https://github.com/joyent/nodejs-advisory-board/blob/779fb1076ae9e47f8dcdc03de31cde5a11018451/meetings/2015-01-14/minutes.md) -### Review of Open Action Items (CW, et. al.) -**TF:** 0.10.36/0.11.15 was released. 0.11.16 out Tuesday or Wednesday next week. -**TF:** NodeSummit WG to meet Monday before NodeSummit (“Day Zero”) -**DS:** Is there a public way to track Technical WG progress? -**TF:** Going to open invite to AB members. If there are proposed community members, they would be added as well as a dial-in for others. Will be boardroom setting for next meeting. -**SH:** Does that makes sense to post on Node.js website? -**TF:** Depends on what’s covered. If it’s a WG not sure if it would be public as _result_ of WG is generally what’s made public. There are key people that need to be there, however. Assume public output would be notes/minutes from WG meeting. +### Review of Open Action Items (CW, et. al.) +**TF:** 0.10.36/0.11.15 was released. 0.11.16 out Tuesday or Wednesday next week. +**TF:** NodeSummit WG to meet Monday before NodeSummit (“Day Zero”) +**DS:** Is there a public way to track Technical WG progress? +**TF:** Going to open invite to AB members. If there are proposed community members, they would be added as well as a dial-in for others. Will be boardroom setting for next meeting. +**SH:** Does that makes sense to post on Node.js website? +**TF:** Depends on what’s covered. If it’s a WG not sure if it would be public as _result_ of WG is generally what’s made public. There are key people that need to be there, however. Assume public output would be notes/minutes from WG meeting. ### Open Public Discussion -No topics raised. +No topics raised. ## New Business (Private) -### Review of Open Action Items (CW, et. al.) +### Review of Open Action Items (CW, et. al.) @@ -54,116 +54,89 @@ Day 2 (2/11): 4:40-end Available as needed. Usually allocated to a forward looki Photo of board room: https://www.dropbox.com/s/3jd9sbo75ib3gce/IMG_2209.JPG?dl=0 ``` -**DS:** TJ discussed boardroom on Monday and there’s also room available for non-TC activity. Will provide a photo of space to set expectations of the venue/accommodations. Not a lot of space for spectators and probably max ~20 people. Will be cozy. Additionally, main days (Tuesday and Wednesday) around 4pm the schedule has allocated space for any announcements and flexibility. Space can be filled if no announcements are prepared. Second day is allocated for looking toward future of Node.js. -**SH:** Previously we discussed to technical session: 1 closed and 1 open. -**TF:** That’s what I was anticipating. Not intended to be public but an internal WG conversation. -**IS:** Yeah, we’re not ready for that. -**DC:** I was asked to form a panel to discuss. -**IR:** If we had a public meeting it would be io.js and Node.js would have to meet at least once prior to then. -**DS:** I would like to see these groups aligned before NodeSummit. If we align _at_ NodeSummit it’s too late in the game. -**IS:** Don’t want to do that negotiation at NodeSummit. -**IR:** People expect to see what’s happening. -**IS:** I agree that 3 months is excessive. we have a private meeting beforehand in the io.js and node-forward meetings so we can make sure everyone is on the same page. -**IR:** The suggestion was that there was _no_ public session. -**IS:** Want people to feel like we’re at least be open with them. -**IR:** We need something technical public that day. -**IS:** that is a good goal, but not sure exactly what that looks like. Scott where are you with being able to talk about a foundation. The last thing I want to do is have a talk about things and then bite our tongues about the foundation. -**SH:** Our target is still to publicly announce with timing being day one, going public that morning. -**DS:** Day 1 is Tuesday. -**SH:** Public announcement that morning and that afternoon we have that hour slot during the day to walk through more details in the public forum, backing up from that have the initial group signed up for the first part of the working group. Enough time for people’s PR machines to warm up. I think we have some pre-briefings this coming week, that is the track/process we are tracking on. Things look ok for hitting that. I’d like to get a session this week with team from IO and give them an update for what we are doing just make sure they know what is happening and agreement for everyone from that group. -**IS:** The best folks are probably IS, BB, and Mikeal Rogers. -**SH:** Fedor seems to be an important person we will get the meeting scheduled this week. Lets make sure anyone writing code is included, asked about TN specifically SH to take point for that. Would like AB members to segue recommendations/output from WG to foundation. If each can make a slide from each WG about the purpose and output in how they have helped in the advisory and recommendations. Fold it in so we can have a meaningful and productive presentation of how the AB has helped. -**DS:** We’ve talked around bringing io.js and node.js, but in the formation of foundation, how important is io.js to the future? -**SH:** My _sense_ is that is has been run around the ideals as described by Bert initially. I think a lot of what io.js represents is an important part of what the foundation represents and is an implementation of what the community wants to see, so it’s important. The ideals align (community, transparent, process), so it’s the next logical progression. Core team has been doing some of that, but perhaps not as much as io.js, but we’re aligned on those objectives. A part where there has been a difference in opinion is the tension between experimenting with latest tech vs delivering quality, production-grade system. An important topic will be how we can accomplish both. Every engineering team I’ve been a part of has had that, and there has to be a way to accommodate experimentation, so how do you weave that into your stable release cadence? -**IS:** I have an answer to that. (to be continued…) -**SH:** There’s a tension there that _has_ to be resolved. Another tension that needs to be addressed is around balancing date-driven deliverables vs functionality-driven, vs quality-driven. I think there’s a process for that in Node.js, but I don’t know how that’s addressed in io.js. We need to listen to, and learn from, the community. -**DC:** I think this is part of why they want the panel they wanted (NodeSummit). -**IS:** In particular the Node.js/io.js community has found an answer to some of these problems. Re: experimental vs prod grade, the answer was unstable and stable release trains. That was difficult to manage once the project reached a certain size. As a result stable trails experimental in certain areas, make it _less_ stable. In io.js this is just becoming a real issue. Started by calling it “unstable” and now getting to a stable and supported v8. -**IS:** We hope between their bleeding edge and unstable, we also can use that same process, we are keeping a bleeding edge following the bleeding edge of V8. A Stable with a v8 that is somewhere between stable and unstable and legacy builds. -**SH:** So 3 release trains. -**IS:** As far as being driven by the 3 priorities (date, quality,features) , you need to balance all 3 at all times. There’s a lot of value to be had in regular, stable releases. Even if it’s just doc updates, the train goes regularly. Balancing functionality with quality, we focus on quality full-time. Also embrace semver as the community. Also, the TC/WG model is similar as AB and it’s working well. -**TM:** One issues is that for those trying to follow along face incompatibilities between forks. -**TF:** Good point. Back to the original question is that the idea of the foundation is the future of node. If/when the 2 project reconcile, there’s a world there multiple distributions exist; hence the compliance/compatibility mark. While there’s a moment today, it will most likely happen in the future. The foundation is there to pave the way forward to handle that gracefully. -**IS:** It’s also a reaction to community needs. -**TM:** We need both bleeding edge and control over compatible releases, so users can have certainty and predictability. -**TF:** We’d have something more akin to the linux kernel with pristine upstream and multiple channels allowing to experimentation and different levels of expected quality. -**IS:** We’re talking a little cross-purpose. There are other forks, but node and io are fundamentally the same people and code. Foundation will benefit from getting those people doing the work back under the node umbrella and having the added institutional experience of those people focused in one place. -**TM:** I think we are saying the same, -**IS:** It is an open source acqui-hire -**TM:** The notion still may exist that we’ll have a bleeding edge as things come back together. -**IS:** Chris Dickinson came up with a good 3-prong release train. Essentially, follow what Chrome does. -**TM:** Yeah, that’s a decent model. -**DS:** Having that participation from google is something we haven’t had before, now they are showing up that we have io.js and it is phenomenal. -**IS:** They’re interested in Chrome, but the Angular, V8 and Chrome are aligned on the future of node and web browsers. e.g. the streams WG is trying to get closer to the other stream WG, etc. -**DS:** I would love to see those efforts accelerate. Should be a foundational part of the foundation and not an afterthought. If we have a reset and restart this process, it would be detrimental losing the effort put into making AB and WG meaningful. -**SH:** re: merger idea, you want to find things that work well and double-down; shedding things that don’t work well. That’s something that needs to be talked through so it’s not a hard reset. The easy part here is that the majority people are working on both. -**IS:** Actually, it’s a minority as there are more people contributing to io that haven’t contributed to node before. -**SH:** Great, then let’s energize the community to continue to grow participants. -**JZ:** Getting the io.js folks back into the node community will generate a lot of excitement. Strong excitement to get both parties unified. -**CW:** As an outside observer, my biggest concern is that it’s discussed a reconciliation and that not enough groundwork has been laid to really effectively get this done prior to NodeSummit. -**IS:** Two things need to happen: IP into Foundation and keeping Governance successes of io.js (without hard reset). Will be blocker for new community members if that doesn’t happen. Have discussed with io.js core team (being careful to keep it from public sphere). I don’t know if everyone is completely on board with reconciliation. There are a lot of hard feelings on a personal level between past and present participant. It can be overcome, just needs to be acknowledged that it’s a problem that needs to be overcome. The details of what that negotiation looks like is pretty straightforward. Not controversial, just need to get to the point of discussing it publicly. -**CW:** I was more referencing the broader community outside from tight-knit TC. -**IS:** Less discussion there. Still frustration regarding lack-of diversity. There’s a lot of community members excited about the new brand, but the thing to keep in mind is that we’re hearing from the top 0.1% of node users, the majority waiting it out to see where the chips land. That’s where the majority of node developers really are. The biggest users are at large enterprises, so it’s hard to get too much of a read from those folks based on a few dozen people on GitHub, but we’re trying to push at those edges. The outreach that I’ve done to companies that use node reveal that they don’t care. -**JZ:** The key is that if the 2 communities unify everyone will come along. Everyone can be reached wil a well-funded jointly-maintained foundation. -**IS:** It’s the continuation of the process, so for most people they never left. Is there anyone that want to add more color. -**IR:** On the user side we’re hearing feedback about it being confusing as to where the multiple project fit. Whatever strategies are decided for branching, etc, they need to be documented and published. -**TM:** Many groups inspect the OSS they’re using and they don’t like their teams running out to use something that has not been vetted, so they ask their devs to not use io.js. There has been some high-level user concern. -**IS:** Shift in branding cause anxiety, so the fix will be to bring the brand together. -**DC:** Tim O’reilly asked me if Node.js was dying. -**CW:** The main root of my question is that the cat is out of the bag wrt forking, so are there people who vehemently oppose reintegration for the codebases. -**TF:** We need to be prepared for that, but the foundation needs to solidify what it means to be node-compatible. The foundation needs to be bigger than this moment. -**CW:** Totally agree. Are there things that can be done to prepare _now_ to anticipate and address this, preventing a problem. -**BB:** There are more people working on io.js and it works. in practical terms people using io.js are concerned that if they go back to Node.js will it still be the same-old Node.js. What you could do is get the two teams talking and working together to instill confidence that coming together won’t be a setback. -**IS:** The message needs to be one of continuity and that the future is Better Together™. We’re currently limited WRT what can be discussed with community members to start to test the waters. -**SH:** Would be good to discuss the specific examples of what’s working for each group, so why don’t we adopt and go for the agreed upon items. -**BB:** The goal is good, but the way it’s expressed is bad. Most folks really feel that io.js is doing way better than node.js, so it would be better to say: “we’ll take the io.js model, but these things need more discussion.” -**IS:** This is why you have marketers. Saying the right things, just using the wrong words. Have to be sensitive to the fact that people may emotionally react. -**TM:** We’ve used an FAQ to do this in past. Need to agree on phrasing, terminology, and tone. -**DS:** Would we be comfortable having io.js TC members involved in that? Since they haven’t seen the inner workings would like to see them engaged early. -**IS:** Would be great to get FAQ in front of Mikeal and Rod Vagg. -**CW:** Joyent should make the announcement, but should we provide an allowance to include more people in this discussion prior to the announcement. -**TM:** Since we’re informing more people next week, can we discuss with more people. -**CW:** Open up discussion in a controlled way. -**JZ:** Can’t we do this/hash it out next week. -**SH:** Yeah, we’re in agreement, so let’s have a session next week with an expanded group. -**TM:** Can you set up FAQ WG -**JW:** Yes, but it needs to have both TCs come together. +**DS:** TJ discussed boardroom on Monday and there’s also room available for non-TC activity. Will provide a photo of space to set expectations of the venue/accommodations. Not a lot of space for spectators and probably max ~20 people. Will be cozy. Additionally, main days (Tuesday and Wednesday) around 4pm the schedule has allocated space for any announcements and flexibility. Space can be filled if no announcements are prepared. Second day is allocated for looking toward future of Node.js. +**SH:** Previously we discussed to technical session: 1 closed and 1 open. +**TF:** That’s what I was anticipating. Not intended to be public but an internal WG conversation. +**IS:** Yeah, we’re not ready for that. +**DC:** I was asked to form a panel to discuss. +**IR:** If we had a public meeting it would be io.js and Node.js would have to meet at least once prior to then. +**DS:** I would like to see these groups aligned before NodeSummit. If we align _at_ NodeSummit it’s too late in the game. +**IS:** Don’t want to do that negotiation at NodeSummit. +**IR:** People expect to see what’s happening. +**IS:** I agree that 3 months is excessive. we have a private meeting beforehand in the io.js and node-forward meetings so we can make sure everyone is on the same page. +**IR:** The suggestion was that there was _no_ public session. +**IS:** Want people to feel like we’re at least be open with them. +**IR:** We need something technical public that day. +**IS:** that is a good goal, but not sure exactly what that looks like. Scott where are you with being able to talk about a foundation. The last thing I want to do is have a talk about things and then bite our tongues about the foundation. +**SH:** Our target is still to publicly announce with timing being day one, going public that morning. +**DS:** Day 1 is Tuesday. +**SH:** Public announcement that morning and that afternoon we have that hour slot during the day to walk through more details in the public forum, backing up from that have the initial group signed up for the first part of the working group. Enough time for people’s PR machines to warm up. I think we have some pre-briefings this coming week, that is the track/process we are tracking on. Things look ok for hitting that. I’d like to get a session this week with team from IO and give them an update for what we are doing just make sure they know what is happening and agreement for everyone from that group. +**IS:** The best folks are probably IS, BB, and Mikeal Rogers. +**SH:** Fedor seems to be an important person we will get the meeting scheduled this week. Lets make sure anyone writing code is included, asked about TN specifically SH to take point for that. Would like AB members to segue recommendations/output from WG to foundation. If each can make a slide from each WG about the purpose and output in how they have helped in the advisory and recommendations. Fold it in so we can have a meaningful and productive presentation of how the AB has helped. +**DS:** We’ve talked around bringing io.js and node.js, but in the formation of foundation, how important is io.js to the future? +**SH:** My _sense_ is that is has been run around the ideals as described by Bert initially. I think a lot of what io.js represents is an important part of what the foundation represents and is an implementation of what the community wants to see, so it’s important. The ideals align (community, transparent, process), so it’s the next logical progression. Core team has been doing some of that, but perhaps not as much as io.js, but we’re aligned on those objectives. A part where there has been a difference in opinion is the tension between experimenting with latest tech vs delivering quality, production-grade system. An important topic will be how we can accomplish both. Every engineering team I’ve been a part of has had that, and there has to be a way to accommodate experimentation, so how do you weave that into your stable release cadence? +**IS:** I have an answer to that. (to be continued…) +**SH:** There’s a tension there that _has_ to be resolved. Another tension that needs to be addressed is around balancing date-driven deliverables vs functionality-driven, vs quality-driven. I think there’s a process for that in Node.js, but I don’t know how that’s addressed in io.js. We need to listen to, and learn from, the community. +**DC:** I think this is part of why they want the panel they wanted (NodeSummit). +**IS:** In particular the Node.js/io.js community has found an answer to some of these problems. Re: experimental vs prod grade, the answer was unstable and stable release trains. That was difficult to manage once the project reached a certain size. As a result stable trails experimental in certain areas, make it _less_ stable. In io.js this is just becoming a real issue. Started by calling it “unstable” and now getting to a stable and supported v8. +**IS:** We hope between their bleeding edge and unstable, we also can use that same process, we are keeping a bleeding edge following the bleeding edge of V8. A Stable with a v8 that is somewhere between stable and unstable and legacy builds. +**SH:** So 3 release trains. +**IS:** As far as being driven by the 3 priorities (date, quality,features) , you need to balance all 3 at all times. There’s a lot of value to be had in regular, stable releases. Even if it’s just doc updates, the train goes regularly. Balancing functionality with quality, we focus on quality full-time. Also embrace semver as the community. Also, the TC/WG model is similar as AB and it’s working well. +**TM:** One issues is that for those trying to follow along face incompatibilities between forks. +**TF:** Good point. Back to the original question is that the idea of the foundation is the future of node. If/when the 2 project reconcile, there’s a world there multiple distributions exist; hence the compliance/compatibility mark. While there’s a moment today, it will most likely happen in the future. The foundation is there to pave the way forward to handle that gracefully. +**IS:** It’s also a reaction to community needs. +**TM:** We need both bleeding edge and control over compatible releases, so users can have certainty and predictability. +**TF:** We’d have something more akin to the linux kernel with pristine upstream and multiple channels allowing to experimentation and different levels of expected quality. +**IS:** We’re talking a little cross-purpose. There are other forks, but node and io are fundamentally the same people and code. Foundation will benefit from getting those people doing the work back under the node umbrella and having the added institutional experience of those people focused in one place. +**TM:** I think we are saying the same, +**IS:** It is an open source acqui-hire +**TM:** The notion still may exist that we’ll have a bleeding edge as things come back together. +**IS:** Chris Dickinson came up with a good 3-prong release train. Essentially, follow what Chrome does. +**TM:** Yeah, that’s a decent model. +**DS:** Having that participation from google is something we haven’t had before, now they are showing up that we have io.js and it is phenomenal. +**IS:** They’re interested in Chrome, but the Angular, V8 and Chrome are aligned on the future of node and web browsers. e.g. the streams WG is trying to get closer to the other stream WG, etc. +**DS:** I would love to see those efforts accelerate. Should be a foundational part of the foundation and not an afterthought. If we have a reset and restart this process, it would be detrimental losing the effort put into making AB and WG meaningful. +**SH:** re: merger idea, you want to find things that work well and double-down; shedding things that don’t work well. That’s something that needs to be talked through so it’s not a hard reset. The easy part here is that the majority people are working on both. +**IS:** Actually, it’s a minority as there are more people contributing to io that haven’t contributed to node before. +**SH:** Great, then let’s energize the community to continue to grow participants. +**JZ:** Getting the io.js folks back into the node community will generate a lot of excitement. Strong excitement to get both parties unified. +**CW:** As an outside observer, my biggest concern is that it’s discussed a reconciliation and that not enough groundwork has been laid to really effectively get this done prior to NodeSummit. +**IS:** Two things need to happen: IP into Foundation and keeping Governance successes of io.js (without hard reset). Will be blocker for new community members if that doesn’t happen. Have discussed with io.js core team (being careful to keep it from public sphere). I don’t know if everyone is completely on board with reconciliation. There are a lot of hard feelings on a personal level between past and present participant. It can be overcome, just needs to be acknowledged that it’s a problem that needs to be overcome. The details of what that negotiation looks like is pretty straightforward. Not controversial, just need to get to the point of discussing it publicly. +**CW:** I was more referencing the broader community outside from tight-knit TC. +**IS:** Less discussion there. Still frustration regarding lack-of diversity. There’s a lot of community members excited about the new brand, but the thing to keep in mind is that we’re hearing from the top 0.1% of node users, the majority waiting it out to see where the chips land. That’s where the majority of node developers really are. The biggest users are at large enterprises, so it’s hard to get too much of a read from those folks based on a few dozen people on GitHub, but we’re trying to push at those edges. The outreach that I’ve done to companies that use node reveal that they don’t care. +**JZ:** The key is that if the 2 communities unify everyone will come along. Everyone can be reached wil a well-funded jointly-maintained foundation. +**IS:** It’s the continuation of the process, so for most people they never left. Is there anyone that want to add more color. +**IR:** On the user side we’re hearing feedback about it being confusing as to where the multiple project fit. Whatever strategies are decided for branching, etc, they need to be documented and published. +**TM:** Many groups inspect the OSS they’re using and they don’t like their teams running out to use something that has not been vetted, so they ask their devs to not use io.js. There has been some high-level user concern. +**IS:** Shift in branding cause anxiety, so the fix will be to bring the brand together. +**DC:** Tim O’reilly asked me if Node.js was dying. +**CW:** The main root of my question is that the cat is out of the bag wrt forking, so are there people who vehemently oppose reintegration for the codebases. +**TF:** We need to be prepared for that, but the foundation needs to solidify what it means to be node-compatible. The foundation needs to be bigger than this moment. +**CW:** Totally agree. Are there things that can be done to prepare _now_ to anticipate and address this, preventing a problem. +**BB:** There are more people working on io.js and it works. in practical terms people using io.js are concerned that if they go back to Node.js will it still be the same-old Node.js. What you could do is get the two teams talking and working together to instill confidence that coming together won’t be a setback. +**IS:** The message needs to be one of continuity and that the future is Better Together™. We’re currently limited WRT what can be discussed with community members to start to test the waters. +**SH:** Would be good to discuss the specific examples of what’s working for each group, so why don’t we adopt and go for the agreed upon items. +**BB:** The goal is good, but the way it’s expressed is bad. Most folks really feel that io.js is doing way better than node.js, so it would be better to say: “we’ll take the io.js model, but these things need more discussion.” +**IS:** This is why you have marketers. Saying the right things, just using the wrong words. Have to be sensitive to the fact that people may emotionally react. +**TM:** We’ve used an FAQ to do this in past. Need to agree on phrasing, terminology, and tone. +**DS:** Would we be comfortable having io.js TC members involved in that? Since they haven’t seen the inner workings would like to see them engaged early. +**IS:** Would be great to get FAQ in front of Mikeal and Rod Vagg. +**CW:** Joyent should make the announcement, but should we provide an allowance to include more people in this discussion prior to the announcement. +**TM:** Since we’re informing more people next week, can we discuss with more people. +**CW:** Open up discussion in a controlled way. +**JZ:** Can’t we do this/hash it out next week. +**SH:** Yeah, we’re in agreement, so let’s have a session next week with an expanded group. +**TM:** Can you set up FAQ WG +**JW:** Yes, but it needs to have both TCs come together. ## New Action Items -**SH:** Session with representatives from io.js to discuss announcement. Include: IS, BB, and Mikeal Rogers; maybe Fedor. (This turned into two discussions with io TC during the week prior to NodeSummit.) -**All WG Leaders:** Send detailed recommendations/output from each WG to SH to ensure it becomes input into the initial foundation. -**JZ (et al):** Produce and wordsmith FAQ. -**JZ:** Schedule session between io.js TC members and AB members. +**SH:** Session with representatives from io.js to discuss announcement. Include: IS, BB, and Mikeal Rogers; maybe Fedor. (This turned into two discussions with io TC during the week prior to NodeSummit.) +**All WG Leaders:** Send detailed recommendations/output from each WG to SH to ensure it becomes input into the initial foundation. +**JZ (et al):** Produce and wordsmith FAQ. +**JZ:** Schedule session between io.js TC members and AB members. ## Next Meeting -Please join our next meeting, Monday Feb 9, 2015 at 2:00 PM PST / 5:00 PM EST at https://global.gotomeeting.com/join/524998381 or please dial-in in using your telephone. - - -``` -United States: +1 (626) 521-0010 -Austria: +43 (0) 7 2088 1033 -Belgium: +32 (0) 28 08 4296 -Canada: +1 (647) 497-9371 -Denmark: +45 (0) 69 91 89 21 -Finland: +358 (0) 942 41 5770 -France: +33 (0) 170 950 585 -Germany: +49 (0) 692 5736 7205 -Ireland: +353 (0) 19 030 050 -Italy: +39 0 693 38 75 50 -Netherlands: +31 (0) 208 080 208 -New Zealand: +64 (0) 9 925 0481 -Norway: +47 21 04 29 12 -Spain: +34 911 82 9890 -Sweden: +46 (0) 852 500 179 -Switzerland: +41 (0) 435 0167 65 -United Kingdom: +44 (0) 330 221 0096 - -Access Code: 273-347-861 -Audio PIN: Shown after joining the meeting - -Meeting ID: 273-347-861 - -``` +Please join our next meeting, Monday Feb 9, 2015 at 2:00 PM PST / 5:00 PM EST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file diff --git a/meetings/2015-02-24/minutes.md b/meetings/2015-02-24/minutes.md index 7199ec8..ec0d918 100644 --- a/meetings/2015-02-24/minutes.md +++ b/meetings/2015-02-24/minutes.md @@ -1,120 +1,93 @@ -# Joyent Node.js Advisory Board Meeting Minutes - February 24, 2015 +# Joyent Node.js Advisory Board Meeting Minutes - February 24, 2015 -## Attendees -Chris Williams (CW) -Erik Toth (ET) -Todd Moore (TM) -Jim Zemlin (JZ) -Mike Dolan (MD) -Bert Belder (BB) -Scott Hammond (SH) -Isaac Schlueter (IS) -TJ Fontaine (TF) -Gianugo Rabellino (GR) -Chris Saint-Amant (CS) -Issac Roth (IR) +## Attendees +Chris Williams (CW) +Erik Toth (ET) +Todd Moore (TM) +Jim Zemlin (JZ) +Mike Dolan (MD) +Bert Belder (BB) +Scott Hammond (SH) +Isaac Schlueter (IS) +TJ Fontaine (TF) +Gianugo Rabellino (GR) +Chris Saint-Amant (CS) +Issac Roth (IR) -## Public Recap +## Public Recap -### Review Previous Meeting Minutes (ET) -[2015-01-29 Meeting Minutes](../2015-01-29/minutes.md) +### Review Previous Meeting Minutes (ET) +[2015-01-29 Meeting Minutes](../2015-01-29/minutes.md) ### Review of Open Action Items (CW, et. al.) -**SH:** Regarding trademark and website WG we developed recommendations for usage of the trademark. Feedback rolling into final recommendation and result published to the nodejs.org website. (If they aren’t published they will be.) Also, with regard to revamping the existing posted policies, those would be deferred to foundation to address. +**SH:** Regarding trademark and website WG we developed recommendations for usage of the trademark. Feedback rolling into final recommendation and result published to the nodejs.org website. (If they aren’t published they will be.) Also, with regard to revamping the existing posted policies, those would be deferred to foundation to address. ### Open Public Discussion -No discussion. +No discussion. -## New Business (Private) +## New Business (Private) ### Review of Open Action Items (CW, et. al.) -**TM:** Feedback on foundation has been positive. -**BB:** Two meetings before NodeSummit. Biggest roadblocks are governance model and which codebase to use as starting point for realigned foundation. -**SH:** We messaged that it would take a couple months to setup foundation (legal, business, technical tracks, etc). Was hoping to walk through the project plan in more detail during this meeting. JM and MD put together a plan that outlines details, timelines, etc. -**CS:** Just ensure there’s time enough for discussion. -**JZ:** Responsible for organizing, planning, and standing up foundation. -**JZ:** The Linux Foundation starts drafts for legal docs to start corporation, such as bylaws, incorporate as non-profit business, etc. That’s one “work track” led by MD and will largely be created with the team that signed the MOU. Not particularly controversial or complex. Similar docs are available on any Linux Foundation project; somewhat unique per project, but overall similar. Will set up mailing lists as well. WIll also set up a set of calls for each of the stakeholders. On the business side there are 2 constituents: underwriters and corresponding legal teams. The marketing track works with the leadership team to develop announcements, create web properties and current AB WGs will feed into this track. Final component is the technical track. On the technical track moving forward with developing governance, starting with input from AB WG. As BB suggested, there are still open questions, but it will be picking up where AB left off. TJ will be leading with JZ staff. I would suggest separating these technical discussion from normal operations of Node.js. In late April to early May, if everything is complete agreements will be signed, elections will take place, and the first board meeting will occur. -**GR:** This looks like it’s going to be operating in a closed-door fashion. This process needs to be more open and have conversations with community, io.js, press, etc. -**JZ:** Agreed, we want to address that early. Tried to get it down to 60 day timeframe. The legal review tends to take a fixed amount of time but will compress, if possible. -**GR:** Time isn’t the issue, openness is the issue. Keep everyone informed of the progress. -**JZ:** Agreed. Will update with periodic external updates. -**CS:** We should discuss what the leadership and technical meetings should look like. Governance seems to the be biggest sticking point, so what needs to be done tactically, what logistics are required, etc? -**JZ:** On the business side, I don’t think there’s controversy, but with regard to technical discussions I defer to community/stakeholders. We’re starting with the AB and existing project, but open to incorporating feedback. -**SH:** Maybe instead of March 12 as draft, if TF can draw up strawman from WG he can socialize prior and work through key points. -**TF:** Definitely. How much openness: posting notes or public discussion? -**GR:** Depends on topic. Should be as open as possible. Since governance is key, should be as open as possible. Don’t want to come up with something and then try to sell it, but develop in open. -**MD:** We’ve observed that these topics are better solved in smaller groups. Can that be done? -**JZ:** I think we can. The stakeholders are not shy. -**IR:** I think this group is shy on this topic (governance). We need to schedule working times. -**CS:** Ad-hoc communication hasn’t produced anything meaningful. Need to schedule half or full-day meeting with stronger facilitation. -**IS:** We have been at this same impasse since first AB meeting. We need to see very explicit clarity on what our goals are. Clear to me how both sides benefit so there’s no disagreement there, but when it comes down to tradeoffs we all talk past each other. -**JZ:** Can I suggest LF facilitates. CS is also in a position be pretty neutral to facilitate. At minimum I recommend getting everyone together on the 12th to hash things out. What else can we set up in the interim? MD and I are happy to facilitate. -**GR:** I can make time. -**IS:** The feedback I’ve heard (across orgs) is that people want an explicit statement that merging is a goal. Makes for a good story, but isn’t backed by the stability (of leadership) people want. It’s less important that we solve governance foremost, but establish shared goals and intent and understanding needs. -**CS:** Need to align on principles, etc. -**IS:** Not even talking “high level”. What does it look like if the projects were to merge? We need to align on that. What does success look like? Know where each other stands will help progress. -**IR:** I like the idea of issuing a public statement of intention and an outline of work toward that goal. Helps with community transparency. -**JZ:** I defer to all parties on this. I’m concerned with output. -**TM:** Idea of getting together with arbiter needs to happen. -**IS:** TM, do you think it’s reasonable to expect everyone dedicates time, or expect people to do their homework. -**TM:** Absolutely, we need people to come prepared. Need to document and score ideas prior to meeting. Work through pros and cons objectively. We’re trying to establish this for when things go bad. -**IR:** CS are you willing to facilitate this? -**CS:** Timing and bandwidth is the biggest challenge. I don’t want to be the bottleneck. -**JZ:** Certainly my staff can make the time. My concern is that my team isn’t deeply technical enough. -**SH:** This is not technical, it’s how we think the group should make decisions, defining goals, use-cases, customers, etc. -**MD:** Is that written down from previous AB work? -**SH:** We’ve had a lot of comments about it, but there’s been no statement. We’ve tried to be all-inclusive: ensure node can expand to all use-cases. If that’s what we want to do , how do we accomplish it, if not, how can we narrow scope? -**JZ:** Would you like us to facilitate drafting language around that? -**SH:** If you want to take a first pass, but we can add to it based on what we’ve seen from our experience. We can iterate through that. -**SH:** Should have this completed prior to the 12th. -**IS:** I have a rough draft of homework questions. -**JZ:** We understand the urgency, incremental steps, external updates, etc, so we will incorporate into plan. I’m hearing it really is technical governance where the work needs to happen. Once these docs are done we want to recruit members as a fundraising effort. -**IR:** Re: TC meetings, is there a person who will drive the meeting. -**SH:** We’re looking for a facilitator and heard MD will do that. -**JZ:** In lieu of CS we can offer MD. Bert offered to facilitate. We’re committed to something on the 12th, but might be good to get things going beforehand. -**CW:** What happens to the AB moving forward? Continue or dissolve in lieu of foundation. -**TM:** In my experience we move it forward, but focus on public engagement. I suggest we keep it moving, but dial back frequency and stay public about what’s happening. -**IR:** If we want to keep this going we need to define how AB will exist in the future, e.g. seats added or removed. We should have a meeting to discuss. -**CW:** Let’s use the time at the next meeting to focus on future of AB with 10 minute focus on foundation. - -### New Action Items -**MD:** Will add announcement checkpoints to plan to update external parties. -**BB, TF, MD:** Schedule Technical governance and reconciliation meeting. -**MD:** Facilitate/draft language around goals. -**IS:** Send out homework questions to stakeholders in technical discussion. -**CW:** Add discussion time re: AB future to schedule for next meeting. - - -## Next Meeting -Please join our next meeting, Monday March 9, 2015 at 2:00 PM PST / 5:00 PM EST at https://global.gotomeeting.com/join/524998381 or please dial-in in using your telephone. - - -``` -United States: +1 (626) 521-0010 -Austria: +43 (0) 7 2088 1033 -Belgium: +32 (0) 28 08 4296 -Canada: +1 (647) 497-9371 -Denmark: +45 (0) 69 91 89 21 -Finland: +358 (0) 942 41 5770 -France: +33 (0) 170 950 585 -Germany: +49 (0) 692 5736 7205 -Ireland: +353 (0) 19 030 050 -Italy: +39 0 693 38 75 50 -Netherlands: +31 (0) 208 080 208 -New Zealand: +64 (0) 9 925 0481 -Norway: +47 21 04 29 12 -Spain: +34 911 82 9890 -Sweden: +46 (0) 852 500 179 -Switzerland: +41 (0) 435 0167 65 -United Kingdom: +44 (0) 330 221 0096 - -Access Code: 273-347-861 -Audio PIN: Shown after joining the meeting - -Meeting ID: 273-347-861 - -``` +**TM:** Feedback on foundation has been positive. +**BB:** Two meetings before NodeSummit. Biggest roadblocks are governance model and which codebase to use as starting point for realigned foundation. +**SH:** We messaged that it would take a couple months to setup foundation (legal, business, technical tracks, etc). Was hoping to walk through the project plan in more detail during this meeting. JM and MD put together a plan that outlines details, timelines, etc. +**CS:** Just ensure there’s time enough for discussion. +**JZ:** Responsible for organizing, planning, and standing up foundation. +**JZ:** The Linux Foundation starts drafts for legal docs to start corporation, such as bylaws, incorporate as non-profit business, etc. That’s one “work track” led by MD and will largely be created with the team that signed the MOU. Not particularly controversial or complex. Similar docs are available on any Linux Foundation project; somewhat unique per project, but overall similar. Will set up mailing lists as well. WIll also set up a set of calls for each of the stakeholders. On the business side there are 2 constituents: underwriters and corresponding legal teams. The marketing track works with the leadership team to develop announcements, create web properties and current AB WGs will feed into this track. Final component is the technical track. On the technical track moving forward with developing governance, starting with input from AB WG. As BB suggested, there are still open questions, but it will be picking up where AB left off. TJ will be leading with JZ staff. I would suggest separating these technical discussion from normal operations of Node.js. In late April to early May, if everything is complete agreements will be signed, elections will take place, and the first board meeting will occur. +**GR:** This looks like it’s going to be operating in a closed-door fashion. This process needs to be more open and have conversations with community, io.js, press, etc. +**JZ:** Agreed, we want to address that early. Tried to get it down to 60 day timeframe. The legal review tends to take a fixed amount of time but will compress, if possible. +**GR:** Time isn’t the issue, openness is the issue. Keep everyone informed of the progress. +**JZ:** Agreed. Will update with periodic external updates. +**CS:** We should discuss what the leadership and technical meetings should look like. Governance seems to the be biggest sticking point, so what needs to be done tactically, what logistics are required, etc? +**JZ:** On the business side, I don’t think there’s controversy, but with regard to technical discussions I defer to community/stakeholders. We’re starting with the AB and existing project, but open to incorporating feedback. +**SH:** Maybe instead of March 12 as draft, if TF can draw up strawman from WG he can socialize prior and work through key points. +**TF:** Definitely. How much openness: posting notes or public discussion? +**GR:** Depends on topic. Should be as open as possible. Since governance is key, should be as open as possible. Don’t want to come up with something and then try to sell it, but develop in open. +**MD:** We’ve observed that these topics are better solved in smaller groups. Can that be done? +**JZ:** I think we can. The stakeholders are not shy. +**IR:** I think this group is shy on this topic (governance). We need to schedule working times. +**CS:** Ad-hoc communication hasn’t produced anything meaningful. Need to schedule half or full-day meeting with stronger facilitation. +**IS:** We have been at this same impasse since first AB meeting. We need to see very explicit clarity on what our goals are. Clear to me how both sides benefit so there’s no disagreement there, but when it comes down to tradeoffs we all talk past each other. +**JZ:** Can I suggest LF facilitates. CS is also in a position be pretty neutral to facilitate. At minimum I recommend getting everyone together on the 12th to hash things out. What else can we set up in the interim? MD and I are happy to facilitate. +**GR:** I can make time. +**IS:** The feedback I’ve heard (across orgs) is that people want an explicit statement that merging is a goal. Makes for a good story, but isn’t backed by the stability (of leadership) people want. It’s less important that we solve governance foremost, but establish shared goals and intent and understanding needs. +**CS:** Need to align on principles, etc. +**IS:** Not even talking “high level”. What does it look like if the projects were to merge? We need to align on that. What does success look like? Know where each other stands will help progress. +**IR:** I like the idea of issuing a public statement of intention and an outline of work toward that goal. Helps with community transparency. +**JZ:** I defer to all parties on this. I’m concerned with output. +**TM:** Idea of getting together with arbiter needs to happen. +**IS:** TM, do you think it’s reasonable to expect everyone dedicates time, or expect people to do their homework. +**TM:** Absolutely, we need people to come prepared. Need to document and score ideas prior to meeting. Work through pros and cons objectively. We’re trying to establish this for when things go bad. +**IR:** CS are you willing to facilitate this? +**CS:** Timing and bandwidth is the biggest challenge. I don’t want to be the bottleneck. +**JZ:** Certainly my staff can make the time. My concern is that my team isn’t deeply technical enough. +**SH:** This is not technical, it’s how we think the group should make decisions, defining goals, use-cases, customers, etc. +**MD:** Is that written down from previous AB work? +**SH:** We’ve had a lot of comments about it, but there’s been no statement. We’ve tried to be all-inclusive: ensure node can expand to all use-cases. If that’s what we want to do , how do we accomplish it, if not, how can we narrow scope? +**JZ:** Would you like us to facilitate drafting language around that? +**SH:** If you want to take a first pass, but we can add to it based on what we’ve seen from our experience. We can iterate through that. +**SH:** Should have this completed prior to the 12th. +**IS:** I have a rough draft of homework questions. +**JZ:** We understand the urgency, incremental steps, external updates, etc, so we will incorporate into plan. I’m hearing it really is technical governance where the work needs to happen. Once these docs are done we want to recruit members as a fundraising effort. +**IR:** Re: TC meetings, is there a person who will drive the meeting. +**SH:** We’re looking for a facilitator and heard MD will do that. +**JZ:** In lieu of CS we can offer MD. Bert offered to facilitate. We’re committed to something on the 12th, but might be good to get things going beforehand. +**CW:** What happens to the AB moving forward? Continue or dissolve in lieu of foundation. +**TM:** In my experience we move it forward, but focus on public engagement. I suggest we keep it moving, but dial back frequency and stay public about what’s happening. +**IR:** If we want to keep this going we need to define how AB will exist in the future, e.g. seats added or removed. We should have a meeting to discuss. +**CW:** Let’s use the time at the next meeting to focus on future of AB with 10 minute focus on foundation. + +### New Action Items +**MD:** Will add announcement checkpoints to plan to update external parties. +**BB, TF, MD:** Schedule Technical governance and reconciliation meeting. +**MD:** Facilitate/draft language around goals. +**IS:** Send out homework questions to stakeholders in technical discussion. +**CW:** Add discussion time re: AB future to schedule for next meeting. + + +## Next Meeting +Please join our next meeting, Monday March 9, 2015 at 2:00 PM PST / 5:00 PM EST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file diff --git a/meetings/2015-03-09/minutes.md b/meetings/2015-03-09/minutes.md index 66e909b..7efc2c5 100644 --- a/meetings/2015-03-09/minutes.md +++ b/meetings/2015-03-09/minutes.md @@ -1,144 +1,117 @@ # Joyent Node.js Advisory Board Meeting Minutes - March 09, 2015 ## Attendees -Chris Williams (CW) -Erik Toth (ET) -Cian O’Maidin (CO) -Todd Moore (TM) -Bert Belder (BB) -Issac Roth (IR) -Mike Dolan (MD) -Scott Hammond (SH) -Jim Zemlin (JZ) -Trevor Norris (TN) -Danese Cooper (DC) -Chris Saint-Amant (CS) -Dan Shaw (DS) -Isaac Schlueter (IS) -TJ Fontaine (TF) -Gianugo Rabellino (GR) +Chris Williams (CW) +Erik Toth (ET) +Cian O’Maidin (CO) +Todd Moore (TM) +Bert Belder (BB) +Issac Roth (IR) +Mike Dolan (MD) +Scott Hammond (SH) +Jim Zemlin (JZ) +Trevor Norris (TN) +Danese Cooper (DC) +Chris Saint-Amant (CS) +Dan Shaw (DS) +Isaac Schlueter (IS) +TJ Fontaine (TF) +Gianugo Rabellino (GR) ## Public Recap ### Review Previous Meeting Minutes (ET) -[2015-02-24 Meeting Minutes](https://github.com/joyent/nodejs-advisory-board/blob/3aa7494459c10b0d1095450837d8220aac24157d/meetings/2015-02-24/minutes.md) +[2015-02-24 Meeting Minutes](https://github.com/joyent/nodejs-advisory-board/blob/3aa7494459c10b0d1095450837d8220aac24157d/meetings/2015-02-24/minutes.md) -### Review of Open Action Items (CW, et. al.) -**JZ:** Re: reconciliation all input is considered. -**SH:** Have reviewed many comments and there was good content there. All comments are welcome and taken into consideration and I believe what we’re doing align with that. Many questions and comments were around technical governance. There has been some work to sketch out a draft that integrates much of the feedback. +### Review of Open Action Items (CW, et. al.) +**JZ:** Re: reconciliation all input is considered. +**SH:** Have reviewed many comments and there was good content there. All comments are welcome and taken into consideration and I believe what we’re doing align with that. Many questions and comments were around technical governance. There has been some work to sketch out a draft that integrates much of the feedback. ### Open Public Discussion -No discussion. +No discussion. ## New Business (Private) -### Review of Open Action Items (CW, et. al.) -n/a +### Review of Open Action Items (CW, et. al.) +n/a ### New Action Items #### Working Group Status (DC, et al) -**DS:** Everything seems to be in a holding pattern awaiting a clear sense of heading. Particularly interested in API Compatibility WG continuing. Would like to hear from TF as to update from several meetings that happened. If there is need or interest in moving that forward, would love to help. -**IR:** Also Community WG needs update. -**DS:** Waiting on resolution with BB. There are people that care, but don’t feel like this is effective forum. Those who have been reached out to who represent purely community interest have not wanted to be involved. Lack of participation in open discussion is telling. Can’t agree more that the value is there. -**IR:** Do people _really_ care then? They want unification but don’t attend, or do they trust they’re represented? -**DS:** They don’t feel represented. -**IS:** There are a lot of people who have completely lost trust in Joyent, Node.js and the people running the project. -**IR:** There may be some people like that, but surprised no one has showed up. -**SH:** There are a lot of people who care but do not show up because of how they’re treated. -**IS:** We’re talking about several groups with conflicting goals and priority. The people may just be willing to wait it out and see what happens. -**BB:** If you want people to show up, they have to come exactly in that 15 minute time slot. Maybe if we had more discussion on GitHub they would chime in. -**IR:** Is it necessary to keep this [community] WG working, or is it futile? -**IS:** What has the WG done? -**TM:** Obviously we want to include everyone. Anyone working with Node or io.js should come and express an opinion. -**BB:** This group is really uninteresting. If you have requests or conversation you can just go to io.js. We’re just a bunch of vendors and we just talk about a lot of high level stuff. -**SH:** We’re not here talking about technical issues, so that may be uninteresting. -**IR:** I think Andrew Stern from F5 would be interested in being engaged with this. -**TF:** I would like to include F5 on the API Compatibility WG. -**IR:** But there are other issues he would be interested in participating in. How do people like him participate? -**DS:** That’s not the stated goal of the Community WG. It was specifically for end users who had voiced frustration that they didn’t feel like they were a party to decision-making. Bringing in F5 does not accomplish that goal. Should we grow to include more entities? Sure. -**IS:** Do we have a list of 100 people who could be considered members of the community and have we contacted them? We have a WG but don’t know what actually happened. -**DS:** Great suggestion. Hypothetically, we reach out to these people: do we feel like we’re making valuable use of their time should they show up? -**IS:** Agree that inviting 100 people is a bad idea, but was kind of my point. This is not the right meeting and will not scale. If we can’t manage 100 people we can’t manage 100 sources of input. -**TM:** On the public side of the meeting even if we don’t attract people they are at least aware and see that people are working on something. Second, if people do come and come prepared with topics, we can extend the meeting. Unless we try and market we won’t know. Worth it on the public side to do a little marketing. -**DS:** I think this group needs that influence. The organic attempts to encourage participation haven’t panned out. io.js has specific invitations for contributions. On our end there’s not a clear benefit for participation. -**BB:** This meeting is about many different things. You would get more engagement if people were invited to participate with WGs. -**IR:** There needs to be a transition plan for this group [AB]. What does that look like? An important part is to include more people and could be a model for doing it in the new world. -**DS:** I think that’s something else (not Community WG) and there’s merit to it. -**DC:** There is a precedent in the gnome community that the TC did the work and pinged the AB to get information of the direction of business. Skeleton board was also on TC. Apache is different: TC runs project, board runs foundation so TC doesn’t have to worry about trademarks, legal, etc. Anyone can join board meetings and minutes are openly published. I don’t know which of those would make the TC happier in this case. -**TF:** Happy with separation between TC and AB. I would be a community representative to board. For example, have opinions on trademark, but don’t want to own it. -**JZ:** We already have a rough structure, e.g. Business Board of Directors. WRT advisory boards, we can do that. What’s the ask? -**DC:** There’s an expectation moving forward that the TC should be able to change things like trademarks, etc. -**BB:** Have to understand that io.js reconciliation plan was written without deep understanding of how a Foundation would operate. Have the expectation that someone with that information would provide feedback and guidance. Very interested in understanding how the proposal should change to reflect reality of Foundation. -**SH:** We have a plan to put together this foundation proposal. io.js proposal was put together assuming TC would create documents, but Linux Foundation is handling. -**JZ:** That’s correct. The docs are created, but reviewed and edited by stakeholders. Good question regarding AB. At some point business decisions are made by Board of Directors and technical decisions are made by TC. The Foundation has rights to marks, but TC owns API compatibility. -**TM:** I’ve experienced that they last a little while in parallel (BoD and AB) and eventually the AB goes away. Usually a community group provides feedback to board. -**JZ:** To be clear, my idea is that the AB structure will dissolve. There will be alternate places where everyone participates in the new structure. -**BB:** Totally agreed. Could be a group focused on vendors and TC would go to them for understanding their needs. +**DS:** Everything seems to be in a holding pattern awaiting a clear sense of heading. Particularly interested in API Compatibility WG continuing. Would like to hear from TF as to update from several meetings that happened. If there is need or interest in moving that forward, would love to help. +**IR:** Also Community WG needs update. +**DS:** Waiting on resolution with BB. There are people that care, but don’t feel like this is effective forum. Those who have been reached out to who represent purely community interest have not wanted to be involved. Lack of participation in open discussion is telling. Can’t agree more that the value is there. +**IR:** Do people _really_ care then? They want unification but don’t attend, or do they trust they’re represented? +**DS:** They don’t feel represented. +**IS:** There are a lot of people who have completely lost trust in Joyent, Node.js and the people running the project. +**IR:** There may be some people like that, but surprised no one has showed up. +**SH:** There are a lot of people who care but do not show up because of how they’re treated. +**IS:** We’re talking about several groups with conflicting goals and priority. The people may just be willing to wait it out and see what happens. +**BB:** If you want people to show up, they have to come exactly in that 15 minute time slot. Maybe if we had more discussion on GitHub they would chime in. +**IR:** Is it necessary to keep this [community] WG working, or is it futile? +**IS:** What has the WG done? +**TM:** Obviously we want to include everyone. Anyone working with Node or io.js should come and express an opinion. +**BB:** This group is really uninteresting. If you have requests or conversation you can just go to io.js. We’re just a bunch of vendors and we just talk about a lot of high level stuff. +**SH:** We’re not here talking about technical issues, so that may be uninteresting. +**IR:** I think Andrew Stern from F5 would be interested in being engaged with this. +**TF:** I would like to include F5 on the API Compatibility WG. +**IR:** But there are other issues he would be interested in participating in. How do people like him participate? +**DS:** That’s not the stated goal of the Community WG. It was specifically for end users who had voiced frustration that they didn’t feel like they were a party to decision-making. Bringing in F5 does not accomplish that goal. Should we grow to include more entities? Sure. +**IS:** Do we have a list of 100 people who could be considered members of the community and have we contacted them? We have a WG but don’t know what actually happened. +**DS:** Great suggestion. Hypothetically, we reach out to these people: do we feel like we’re making valuable use of their time should they show up? +**IS:** Agree that inviting 100 people is a bad idea, but was kind of my point. This is not the right meeting and will not scale. If we can’t manage 100 people we can’t manage 100 sources of input. +**TM:** On the public side of the meeting even if we don’t attract people they are at least aware and see that people are working on something. Second, if people do come and come prepared with topics, we can extend the meeting. Unless we try and market we won’t know. Worth it on the public side to do a little marketing. +**DS:** I think this group needs that influence. The organic attempts to encourage participation haven’t panned out. io.js has specific invitations for contributions. On our end there’s not a clear benefit for participation. +**BB:** This meeting is about many different things. You would get more engagement if people were invited to participate with WGs. +**IR:** There needs to be a transition plan for this group [AB]. What does that look like? An important part is to include more people and could be a model for doing it in the new world. +**DS:** I think that’s something else (not Community WG) and there’s merit to it. +**DC:** There is a precedent in the gnome community that the TC did the work and pinged the AB to get information of the direction of business. Skeleton board was also on TC. Apache is different: TC runs project, board runs foundation so TC doesn’t have to worry about trademarks, legal, etc. Anyone can join board meetings and minutes are openly published. I don’t know which of those would make the TC happier in this case. +**TF:** Happy with separation between TC and AB. I would be a community representative to board. For example, have opinions on trademark, but don’t want to own it. +**JZ:** We already have a rough structure, e.g. Business Board of Directors. WRT advisory boards, we can do that. What’s the ask? +**DC:** There’s an expectation moving forward that the TC should be able to change things like trademarks, etc. +**BB:** Have to understand that io.js reconciliation plan was written without deep understanding of how a Foundation would operate. Have the expectation that someone with that information would provide feedback and guidance. Very interested in understanding how the proposal should change to reflect reality of Foundation. +**SH:** We have a plan to put together this foundation proposal. io.js proposal was put together assuming TC would create documents, but Linux Foundation is handling. +**JZ:** That’s correct. The docs are created, but reviewed and edited by stakeholders. Good question regarding AB. At some point business decisions are made by Board of Directors and technical decisions are made by TC. The Foundation has rights to marks, but TC owns API compatibility. +**TM:** I’ve experienced that they last a little while in parallel (BoD and AB) and eventually the AB goes away. Usually a community group provides feedback to board. +**JZ:** To be clear, my idea is that the AB structure will dissolve. There will be alternate places where everyone participates in the new structure. +**BB:** Totally agreed. Could be a group focused on vendors and TC would go to them for understanding their needs. #### Status from Linux Foundation (MD) -**MD:** Reaching out to contacts to setup call for discussing drafts. Sent out drafts of bylaws. Working on technical discussions with BB and TF and have had a few calls. Hopefully will carry in to TC discussion. Drafted a blog post for communicating progress to community. +**MD:** Reaching out to contacts to setup call for discussing drafts. Sent out drafts of bylaws. Working on technical discussions with BB and TF and have had a few calls. Hopefully will carry in to TC discussion. Drafted a blog post for communicating progress to community. #### Node.js/io.js Reconciliation (BB) -**BB:** There is this feeling that the stakeholders (io.js and Node.js) should get together in a room and hash things out. The io.js team didn’t really feel like it - would prefer to do it online, so a draft was written and posted for community feedback. Hopefully helps everyone understand the io.js community position. I’ve been working with MD and TF to find a compromise, but that isn’t going anywhere mostly because it’s not clear what the Node.js group wants. TF will send proposal after this meeting, but I’m concerned that I’m not negotiating with a “Node.js” group, and instead with only TF. Looking for input from people on this call as to opinions on io.js proposal. -**TF:** To clarify, there is a draft that will be circulated after this meeting. The Node.js team will schedule a call this week to discuss and draft will be sent out. Working on creating Technical Governance for foundation and creating a solid path forward for Node. -**BB:** May I suggest that the proposal goes on the internet somewhere. -**GR:** Who is on the Node.js committee? -**BB:** Participants from Joyent, Microsoft, and IBM. [Additional names provided, but not recorded.] -**GR:** Would love to see progress. I think io.js proposal is a good starting point and would like to understand what is on the other side. Lets make sure that there’s a good timeline in mind. -**TF:** Draft will be sent around after this meeting. -**DS:** Any thoughts on current io.js proposal? -**DC:** Some items WRT trademarks are something I haven’t seen before. For example, TC doesn’t typically own or manage trademark. Board manages that and issues resolved through discussion. -**IS:** Can we get that feedback on the proposal such that we can iterate on it? -**DS:** Yeah, that’s an easy solve. -**SH:** I feel like the main issue is the TC decision. I would rather segregate this and let the Linux Foundation do their thing and have the TC conversation separately. -**JZ:** We’re down to a fairly narrow set of issues, so let’s stay focused on that. -**IR:** The response [Node.js proposal] should have been released prior to the meeting. -**TF:** The concern was that this meeting would get derailed on details of the proposals. -**IS:** So there are things that should belong on the business side. We have not aligned on issues, but said issues have not been identified. -**SH:** We need to have conversations between TF and BB to make progress. -**BB:** “Progress” is an open concept. MD tried to write down what TF wants. It was an attempt to identify what TF wants, but it sounds like the true proposal will be circulated. -**TF:** New document provides additional context. -**CW:** We need to identify ONE owner to drive this for the next meeting. -**JZ:** There is progress. Let’s not be so hard on each other. LF will continue to drive. We will continue to broker a convergence. Will refine external communication, but progress is being made. Let’s move forward with current plan. -**BB:** In order to get community support we have to do it in the open, meaning we open up the process, not the outcome. This is needed to build trust. -**JZ:** I agree. -**BB:** We need to discussion in the open and will cross-post in io.js. -**IS:** Any reconciliation announcement needs to have a link back to the discussion. +**BB:** There is this feeling that the stakeholders (io.js and Node.js) should get together in a room and hash things out. The io.js team didn’t really feel like it - would prefer to do it online, so a draft was written and posted for community feedback. Hopefully helps everyone understand the io.js community position. I’ve been working with MD and TF to find a compromise, but that isn’t going anywhere mostly because it’s not clear what the Node.js group wants. TF will send proposal after this meeting, but I’m concerned that I’m not negotiating with a “Node.js” group, and instead with only TF. Looking for input from people on this call as to opinions on io.js proposal. +**TF:** To clarify, there is a draft that will be circulated after this meeting. The Node.js team will schedule a call this week to discuss and draft will be sent out. Working on creating Technical Governance for foundation and creating a solid path forward for Node. +**BB:** May I suggest that the proposal goes on the internet somewhere. +**GR:** Who is on the Node.js committee? +**BB:** Participants from Joyent, Microsoft, and IBM. [Additional names provided, but not recorded.] +**GR:** Would love to see progress. I think io.js proposal is a good starting point and would like to understand what is on the other side. Lets make sure that there’s a good timeline in mind. +**TF:** Draft will be sent around after this meeting. +**DS:** Any thoughts on current io.js proposal? +**DC:** Some items WRT trademarks are something I haven’t seen before. For example, TC doesn’t typically own or manage trademark. Board manages that and issues resolved through discussion. +**IS:** Can we get that feedback on the proposal such that we can iterate on it? +**DS:** Yeah, that’s an easy solve. +**SH:** I feel like the main issue is the TC decision. I would rather segregate this and let the Linux Foundation do their thing and have the TC conversation separately. +**JZ:** We’re down to a fairly narrow set of issues, so let’s stay focused on that. +**IR:** The response [Node.js proposal] should have been released prior to the meeting. +**TF:** The concern was that this meeting would get derailed on details of the proposals. +**IS:** So there are things that should belong on the business side. We have not aligned on issues, but said issues have not been identified. +**SH:** We need to have conversations between TF and BB to make progress. +**BB:** “Progress” is an open concept. MD tried to write down what TF wants. It was an attempt to identify what TF wants, but it sounds like the true proposal will be circulated. +**TF:** New document provides additional context. +**CW:** We need to identify ONE owner to drive this for the next meeting. +**JZ:** There is progress. Let’s not be so hard on each other. LF will continue to drive. We will continue to broker a convergence. Will refine external communication, but progress is being made. Let’s move forward with current plan. +**BB:** In order to get community support we have to do it in the open, meaning we open up the process, not the outcome. This is needed to build trust. +**JZ:** I agree. +**BB:** We need to discussion in the open and will cross-post in io.js. +**IS:** Any reconciliation announcement needs to have a link back to the discussion. ## New Action Items -**TF:** Send Node.js Technical governance proposal out to interested parties. +**TF:** Send Node.js Technical governance proposal out to interested parties. ## Next Meeting -Please join our next meeting, Monday March 23, 2015 at 2:00 PM PST / 5:00 PM EST at https://global.gotomeeting.com/join/524998381 or please dial-in in using your telephone. - - -``` -United States: +1 (626) 521-0010 -Austria: +43 (0) 7 2088 1033 -Belgium: +32 (0) 28 08 4296 -Canada: +1 (647) 497-9371 -Denmark: +45 (0) 69 91 89 21 -Finland: +358 (0) 942 41 5770 -France: +33 (0) 170 950 585 -Germany: +49 (0) 692 5736 7205 -Ireland: +353 (0) 19 030 050 -Italy: +39 0 693 38 75 50 -Netherlands: +31 (0) 208 080 208 -New Zealand: +64 (0) 9 925 0481 -Norway: +47 21 04 29 12 -Spain: +34 911 82 9890 -Sweden: +46 (0) 852 500 179 -Switzerland: +41 (0) 435 0167 65 -United Kingdom: +44 (0) 330 221 0096 - -Access Code: 273-347-861 -Audio PIN: Shown after joining the meeting - -Meeting ID: 273-347-861 - -``` +Please join our next meeting, Monday March 23, 2015 at 2:00 PM PST / 5:00 PM EST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file diff --git a/meetings/2015-03-23/minutes.md b/meetings/2015-03-23/minutes.md index 235defc..1ebbe16 100644 --- a/meetings/2015-03-23/minutes.md +++ b/meetings/2015-03-23/minutes.md @@ -1,25 +1,25 @@ # Joyent Node.js Advisory Board Meeting Minutes - March 23, 2015 ## Attendees -Chris Williams (CW) -Erik Toth (ET) -Mike Dolan (MD) -Scott Hammond (SH) -Issac Roth (IR) +Chris Williams (CW) +Erik Toth (ET) +Mike Dolan (MD) +Scott Hammond (SH) +Issac Roth (IR) Isaac Schlueter (IS) -Dan Shaw (DS) -Bert Belder (BB) -TJ Fontaine (TF) -Danese Cooper (DC) -Gianugo Rabellino (GR) -Todd Moore (TM) -Jim Zemlin (JZ) -Scott Nicholas (SN) -Kevin Decker (KD) +Dan Shaw (DS) +Bert Belder (BB) +TJ Fontaine (TF) +Danese Cooper (DC) +Gianugo Rabellino (GR) +Todd Moore (TM) +Jim Zemlin (JZ) +Scott Nicholas (SN) +Kevin Decker (KD) ## Previous Attendees -Cian O’Maidin (CO) -Trevor Norris (TN) +Cian O’Maidin (CO) +Trevor Norris (TN) Chris Saint-Amant (CS) @@ -27,132 +27,105 @@ Chris Saint-Amant (CS) ## Public Recap ### Review Previous Meeting Minutes (CW) -[2015-03-09 Meeting Minutes](https://github.com/joyent/nodejs-advisory-board/blob/fbaaaf3c16b8d43bfe3f6af463a8e3fb345fb5b5/meetings/2015-03-09/minutes.md) +[2015-03-09 Meeting Minutes](https://github.com/joyent/nodejs-advisory-board/blob/fbaaaf3c16b8d43bfe3f6af463a8e3fb345fb5b5/meetings/2015-03-09/minutes.md) -### Review of Open Action Items (CW, et. al.) -**MD:** Have taken io.js governance documents and reviewed them, looking to ways to incorporate. Typically will set up TSC Charter, TSC Policy, and Project Lifecycle documents. Took template from previous project and integrated io.js proposal to bring it into existing framework, so organized differently from source docs. Also, items were added that were not addressed under io.js docs, such as community docs. Ready to publish for public comment on GitHub. Not just me, but many people have contributed, so thanks. +### Review of Open Action Items (CW, et. al.) +**MD:** Have taken io.js governance documents and reviewed them, looking to ways to incorporate. Typically will set up TSC Charter, TSC Policy, and Project Lifecycle documents. Took template from previous project and integrated io.js proposal to bring it into existing framework, so organized differently from source docs. Also, items were added that were not addressed under io.js docs, such as community docs. Ready to publish for public comment on GitHub. Not just me, but many people have contributed, so thanks. ### Open Public Discussion -**Travis:** Points from previous meeting WRT marketing are correct. Was difficult to find information about what’s going on. Would be nice to see something this fundamentally important more easy to find. -**CW:** Definitely agree and are working toward that. Any suggestions as to how to improve? -**Travis:** Would be easier to find on the Node.js website. You have to dig to find it and if this is the future direction it should be featured more prominently. -**TF:** We can definitely put it on the homepage and the site is open to contributions from the community. -**Chris:** Homepage seems to have out-of-date list to meeting notes. Maybe the process of posting or linking to notes needs to be automated. -**TF:** We can look into that. Right now the site is auto-generated but some parts are still manual. -**Chris:** As someone who writes Node.js exclusively it’s important for me to know what’s happening and unfortunately Google is the best place to find what I need. -**DC:** Agreed. We can do better. -**DS:** We’ve been looking for more people to engage with the Community WG. If Travis and Chris are interested, would love to have them get involved. -**BB:** Maybe we should get rid of the private section of the meeting, or minimize it. -**DS:** I support that, too. -**Chris:** The way to bring things to the AB was an email address deep in the charter. It might be good to surface that. -**CW:** The GH repo was another avenue to provide feedback. -**TM:** Should we be doing something on twitter, too? -**Chris:** Sure. -**SH:** We can tweet when new notes are posted, etc. +**Travis:** Points from previous meeting WRT marketing are correct. Was difficult to find information about what’s going on. Would be nice to see something this fundamentally important more easy to find. +**CW:** Definitely agree and are working toward that. Any suggestions as to how to improve? +**Travis:** Would be easier to find on the Node.js website. You have to dig to find it and if this is the future direction it should be featured more prominently. +**TF:** We can definitely put it on the homepage and the site is open to contributions from the community. +**Chris:** Homepage seems to have out-of-date list to meeting notes. Maybe the process of posting or linking to notes needs to be automated. +**TF:** We can look into that. Right now the site is auto-generated but some parts are still manual. +**Chris:** As someone who writes Node.js exclusively it’s important for me to know what’s happening and unfortunately Google is the best place to find what I need. +**DC:** Agreed. We can do better. +**DS:** We’ve been looking for more people to engage with the Community WG. If Travis and Chris are interested, would love to have them get involved. +**BB:** Maybe we should get rid of the private section of the meeting, or minimize it. +**DS:** I support that, too. +**Chris:** The way to bring things to the AB was an email address deep in the charter. It might be good to surface that. +**CW:** The GH repo was another avenue to provide feedback. +**TM:** Should we be doing something on twitter, too? +**Chris:** Sure. +**SH:** We can tweet when new notes are posted, etc. ## New Business (Private) -### Review of Open Action Items (CW, et. al.) +### Review of Open Action Items (CW, et. al.) ### Reconciliation Status -**TF:** Looking to get feedback from AB on documents that were emailed earlier, prior to releasing to public. -**BB:** There will be more input from TF, James Snell, etc but overall happy with progress that’s been made over the last 2 weeks. -**TM:** Thumbs is from IBM. -**GR:** Yep, we like it was well. -**MD:** Things have moved along over the last couple weeks, and not time to start thinking about things that not sure people have thought about: schedule, lifecycle, beyond next 6 months onto those who drive it 10+ years. Trying to get as much framework in place as possible. Need developer process for meetings, agenda, technology, etc. That won’t necessarily go in these docs and will let the developer community define. -**TM:** In terms of support infra, did you have any discussions on how repos will operate, infra for team communication, etc. or is what we’re doing (GitHub) adequate? Could GitHub provide any additional support? -**MD:** Have not discussed yet as we’ve focused on governance. Some teams don’t use GitHub so we’ve setup infra for them. -**TM:** It’s been raised to me that some groups do this differently, so merely asking. -**TF:** Some of this came up during the development of the provided documents, but we’re really trying to leave some of these decisions open for TSC and related projects to decide. Not all tools or infra may be applicable to all related projects. -**TM:** If you need the board’s help, there needs to be a mechanism for making that request. -**MD:** The chair of the TSC would be a board Director, so that person would raise these issues to the board for consideration. -**BB:** We’ve mostly been discussing governance, so more technical items (CI, for example) need to be figured out. We’re pushing the boundaries of GitHub a little bit. -**TF:** Yes, what has worked well for the core team may not be necessary for other projects. We would enable our own process internally potentially without making it public. -**JZ:** I have a staff that is more than happy to help tooling discussions. +**TF:** Looking to get feedback from AB on documents that were emailed earlier, prior to releasing to public. +**BB:** There will be more input from TF, James Snell, etc but overall happy with progress that’s been made over the last 2 weeks. +**TM:** Thumbs is from IBM. +**GR:** Yep, we like it was well. +**MD:** Things have moved along over the last couple weeks, and not time to start thinking about things that not sure people have thought about: schedule, lifecycle, beyond next 6 months onto those who drive it 10+ years. Trying to get as much framework in place as possible. Need developer process for meetings, agenda, technology, etc. That won’t necessarily go in these docs and will let the developer community define. +**TM:** In terms of support infra, did you have any discussions on how repos will operate, infra for team communication, etc. or is what we’re doing (GitHub) adequate? Could GitHub provide any additional support? +**MD:** Have not discussed yet as we’ve focused on governance. Some teams don’t use GitHub so we’ve setup infra for them. +**TM:** It’s been raised to me that some groups do this differently, so merely asking. +**TF:** Some of this came up during the development of the provided documents, but we’re really trying to leave some of these decisions open for TSC and related projects to decide. Not all tools or infra may be applicable to all related projects. +**TM:** If you need the board’s help, there needs to be a mechanism for making that request. +**MD:** The chair of the TSC would be a board Director, so that person would raise these issues to the board for consideration. +**BB:** We’ve mostly been discussing governance, so more technical items (CI, for example) need to be figured out. We’re pushing the boundaries of GitHub a little bit. +**TF:** Yes, what has worked well for the core team may not be necessary for other projects. We would enable our own process internally potentially without making it public. +**JZ:** I have a staff that is more than happy to help tooling discussions. **MD:** Many use git, jira, etc. -**JZ:** This community needs to balance velocity from GitHub... -**MD:** Yep, I changed references to git, as that may be more flexible for teams. -**DC:** Were there conversations WRT trademarks, etc? -**DS:** We had conversation but wasn’t actually in the proposed docs. -**BB:** io.js doesn’t really have a board so effectively TC controlled everything, but makes sense to keep those concerns separate. +**JZ:** This community needs to balance velocity from GitHub... +**MD:** Yep, I changed references to git, as that may be more flexible for teams. +**DC:** Were there conversations WRT trademarks, etc? +**DS:** We had conversation but wasn’t actually in the proposed docs. +**BB:** io.js doesn’t really have a board so effectively TC controlled everything, but makes sense to keep those concerns separate. ### Non-Node-Core/Incubation Projects (BB) -**BB:** MD proposed project lifecycle, including new projects with representation on TSC. This translates to things like libuv, http parser, and some node modules and we might want to accommodate these types of projects, growing the possible contributor base. socket.io, for example, may want a foundation for themselves. It doesn’t make sense to give _every_ one of these projects a seat on the TC, but could we accommodate them anyway? How might that work? -**DC:** There’s a ton of infra in Apache for this type of thing to ensure projects like this aren’t dropped and abandoned. The process for incubation needs to be well-defined. -**GR:** Going back to my Apache experience, I would suggest that it would be best to incubate the incubation. Wait until those projects come in and then think about it, but I don’t think there will be a big influx from day one. There will be a lot of resources necessary to support this and we don’t yet have those resources. -**TF:** We just want to know if we have the ability make this available to the community. For example, could I get non-profit status by joining such that I can accept donations, etc? Doing it under the Node umbrella would be beneficial for them. -**DC:** You do want to be able to be that umbrella. +**BB:** MD proposed project lifecycle, including new projects with representation on TSC. This translates to things like libuv, http parser, and some node modules and we might want to accommodate these types of projects, growing the possible contributor base. socket.io, for example, may want a foundation for themselves. It doesn’t make sense to give _every_ one of these projects a seat on the TC, but could we accommodate them anyway? How might that work? +**DC:** There’s a ton of infra in Apache for this type of thing to ensure projects like this aren’t dropped and abandoned. The process for incubation needs to be well-defined. +**GR:** Going back to my Apache experience, I would suggest that it would be best to incubate the incubation. Wait until those projects come in and then think about it, but I don’t think there will be a big influx from day one. There will be a lot of resources necessary to support this and we don’t yet have those resources. +**TF:** We just want to know if we have the ability make this available to the community. For example, could I get non-profit status by joining such that I can accept donations, etc? Doing it under the Node umbrella would be beneficial for them. +**DC:** You do want to be able to be that umbrella. **MD:** What TJ sent out earlier is the project lifecycle document and sets a lot of this up from previous attempts. We have a general construct, but needs this group’s input to shape it appropriately for Node.js. -**DC:** We’re saying, don’t write it yet, but instead wait until you have one to define what the process is. -**GR:** Don’t do anything to preclude getting there, but it’s not a priority right now. -**JZ:** Definitely, please at least check it out. -**DC:** I did read it but I saw a couple “and then a miracle occurred” items. Don’t over-define it yet. -**TF:** We are at that point right now, however, WRT libuv and http parser. -**BB:** It’s obvious that http parser must be in the foundation. WRT libuv, it makes sense as well. -**IS:** Its reasonable that you go have those conversations. -**BB:** Yeah, we want to share with libuv what they would get out of participating. -**TM:** There’s another goal: we don’t want them to be a single-maintainer project forever. We want to support them as much as we can. The question is: should they get a seat on the TC? We don’t want them to feel second-class, but will it scale? -**BB:** For these projects it makes sense to give them seats, but would a project like Hapi hypothetically get a seat or would there be 2 TCs, etc? -**DC:** There are already extensible bits to the Apache org. -**MD:** These are living documents, so it’s expected that they will be updated and revised over time. We plan to make sufficient investment that it will scale appropriately. If you want innovation you want it in the foundation, not outside, so you need to demonstrate value in participating in the foundation. +**DC:** We’re saying, don’t write it yet, but instead wait until you have one to define what the process is. +**GR:** Don’t do anything to preclude getting there, but it’s not a priority right now. +**JZ:** Definitely, please at least check it out. +**DC:** I did read it but I saw a couple “and then a miracle occurred” items. Don’t over-define it yet. +**TF:** We are at that point right now, however, WRT libuv and http parser. +**BB:** It’s obvious that http parser must be in the foundation. WRT libuv, it makes sense as well. +**IS:** Its reasonable that you go have those conversations. +**BB:** Yeah, we want to share with libuv what they would get out of participating. +**TM:** There’s another goal: we don’t want them to be a single-maintainer project forever. We want to support them as much as we can. The question is: should they get a seat on the TC? We don’t want them to feel second-class, but will it scale? +**BB:** For these projects it makes sense to give them seats, but would a project like Hapi hypothetically get a seat or would there be 2 TCs, etc? +**DC:** There are already extensible bits to the Apache org. +**MD:** These are living documents, so it’s expected that they will be updated and revised over time. We plan to make sufficient investment that it will scale appropriately. If you want innovation you want it in the foundation, not outside, so you need to demonstrate value in participating in the foundation. ### Discontinue Private Meeting (BB) -**BB:** Previously, there was some contention and we wanted to speak frankly. Now, this is info that everyone is interested in and there’s no reason to stay private. I think most of the topic happen on the public side, and could decide on the spot whether or not there are items worth discussing privately. -**CW:** I agree. In terms of outbound channels, I’d like to help drive more attention to this. If we’re going to go longer than 15 minutes we need to be more intentional. Can we use the Node.js twitter account to publicize this? -**TF:** Yep. -**CW:** DS, I’d like to work with you and what the Community WG is doing. +**BB:** Previously, there was some contention and we wanted to speak frankly. Now, this is info that everyone is interested in and there’s no reason to stay private. I think most of the topic happen on the public side, and could decide on the spot whether or not there are items worth discussing privately. +**CW:** I agree. In terms of outbound channels, I’d like to help drive more attention to this. If we’re going to go longer than 15 minutes we need to be more intentional. Can we use the Node.js twitter account to publicize this? +**TF:** Yep. +**CW:** DS, I’d like to work with you and what the Community WG is doing. **DC:** The public side will need to be managed carefully to keep things moving. -**BB:** Maybe we can have an IRC back channel for asking questions. -**TF:** I agree, especially since we can’t always depend on GoToMeeting. -**CW:** We could do IRC, Slack… -**TF:** We need to support as many people as possible. -**IS:** You need a dedicated advocate in whatever tool you have (IRC, slack, etc) to help manage the conversation. -**CW:** Is that a moderator, or an advocate separate/disjoint from moderator? -**IS:** A good moderator could possibly be both, but would be more effective that person is a distinct role. -**DC:** Wikipedia, for example, has 3 people managing this process. -**TF:** I’m not sure we’ll have the same visibility as Wikipedia. -**CW:** For next meeting we’ll do 45 public, 15 private. Who will be public-side advocate? Also, advocate must have traceback to conversation, not an advocate for themselves. Will schedule meetings on Monday afternoons through May. +**BB:** Maybe we can have an IRC back channel for asking questions. +**TF:** I agree, especially since we can’t always depend on GoToMeeting. +**CW:** We could do IRC, Slack… +**TF:** We need to support as many people as possible. +**IS:** You need a dedicated advocate in whatever tool you have (IRC, slack, etc) to help manage the conversation. +**CW:** Is that a moderator, or an advocate separate/disjoint from moderator? +**IS:** A good moderator could possibly be both, but would be more effective that person is a distinct role. +**DC:** Wikipedia, for example, has 3 people managing this process. +**TF:** I’m not sure we’ll have the same visibility as Wikipedia. +**CW:** For next meeting we’ll do 45 public, 15 private. Who will be public-side advocate? Also, advocate must have traceback to conversation, not an advocate for themselves. Will schedule meetings on Monday afternoons through May. -If you are interested in participating in API Compliance next steps please sign up for our kick off meeting: https://doodle.com/xr6farvn35cx6sg7 +If you are interested in participating in API Compliance next steps please sign up for our kick off meeting: https://doodle.com/xr6farvn35cx6sg7 ## New Action Items -- Make NAB information more visible on Node.js website (TF) -- Post draft governance documents to website/GitHub (MD, TF) -- Direct io.js participants to draft documents and promote review and discussion. (BB) -- Schedule 45 min public, 15 min private for upcoming meetings. (CW) -- Promotion of upcoming meetings. (CW, DS) -- Identify IRC advocate. (CW, et al) +- Make NAB information more visible on Node.js website (TF) +- Post draft governance documents to website/GitHub (MD, TF) +- Direct io.js participants to draft documents and promote review and discussion. (BB) +- Schedule 45 min public, 15 min private for upcoming meetings. (CW) +- Promotion of upcoming meetings. (CW, DS) +- Identify IRC advocate. (CW, et al) ## Next Meeting -Please join our next meeting, Monday April 6, 2015 at 2:00 PM PST / 5:00 PM EST at https://global.gotomeeting.com/join/524998381 or please dial-in in using your telephone. - - -``` -United States: +1 (626) 521-0010 -Austria: +43 (0) 7 2088 1033 -Belgium: +32 (0) 28 08 4296 -Canada: +1 (647) 497-9371 -Denmark: +45 (0) 69 91 89 21 -Finland: +358 (0) 942 41 5770 -France: +33 (0) 170 950 585 -Germany: +49 (0) 692 5736 7205 -Ireland: +353 (0) 19 030 050 -Italy: +39 0 693 38 75 50 -Netherlands: +31 (0) 208 080 208 -New Zealand: +64 (0) 9 925 0481 -Norway: +47 21 04 29 12 -Spain: +34 911 82 9890 -Sweden: +46 (0) 852 500 179 -Switzerland: +41 (0) 435 0167 65 -United Kingdom: +44 (0) 330 221 0096 - -Access Code: 273-347-861 -Audio PIN: Shown after joining the meeting - -Meeting ID: 273-347-861 - -``` +Please join our next meeting, Monday April 6, 2015 at 2:00 PM PST / 5:00 PM EST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file diff --git a/meetings/2015-04-06/minutes.md b/meetings/2015-04-06/minutes.md index e3e1e8c..494f314 100644 --- a/meetings/2015-04-06/minutes.md +++ b/meetings/2015-04-06/minutes.md @@ -2,65 +2,71 @@ ## Attendees -Chris Williams (CW) -Chris Saint-Amant (CS) -Bert Belder (BB) -Daniel Shaw (DS) -Scott Hammond (SH) -Mikeal Rogers (MR) -Mike Dolan (MD) -Danese Cooper (DC) -Todd Moore (TM) -Gianugo Rabellino (GR) -Trevor Norris (TN) -Issac Roth (IR) +Chris Williams (CW) +Chris Saint-Amant (CS) +Bert Belder (BB) +Daniel Shaw (DS) +Scott Hammond (SH) +Mikeal Rogers (MR) +Mike Dolan (MD) +Danese Cooper (DC) +Todd Moore (TM) +Gianugo Rabellino (GR) +Trevor Norris (TN) +Issac Roth (IR) ## Recap -**CW:** Review of the Action Items -**BB:** Posted to the IO.js +**CW:** Review of the Action Items +**BB:** Posted to the IO.js ## Reconciliation Status -**MD:** Last time we are trying to get a pull request into the advisory. There was a lot of discussion, mainly around the node and io.js communities and the project life cycle. MR has been driving a lot of the discussion around the reconciliation and merger. A lot of discussion about the working groups and -**MR:** Pull request #33 it is a full redo of the project lifecycle. Review details are current a TODO and figure out where the current working groups are going to go. Where the requirements sit for the working groups. +**MD:** Last time we are trying to get a pull request into the advisory. There was a lot of discussion, mainly around the node and io.js communities and the project life cycle. MR has been driving a lot of the discussion around the reconciliation and merger. A lot of discussion about the working groups and +**MR:** Pull request #33 it is a full redo of the project lifecycle. Review details are current a TODO and figure out where the current working groups are going to go. Where the requirements sit for the working groups. -**MD** provided a review of the various documents -**MR** provide a status on the reconciliation efforts and workflow +**MD** provided a review of the various documents +**MR** provide a status on the reconciliation efforts and workflow -**DS:** Seeking a timeline -**MD:** Early to mid may -**IR:** did the relevant things happen on the project and how are we tracking? -**MD:** Work streams that we are running are on track, everything has been pretty close or before the deadlines we have set up. +**DS:** Seeking a timeline +**MD:** Early to mid may +**IR:** did the relevant things happen on the project and how are we tracking? +**MD:** Work streams that we are running are on track, everything has been pretty close or before the deadlines we have set up. ## Public Questions -**Travis Odem:** Thanks for the website; would be nice to have it linked from the main website -**DS:** We tracked down who has commit rights to the website. SH to connect the advisory board for what we are seeking. +**Travis Odem:** Thanks for the website; would be nice to have it linked from the main website +**DS:** We tracked down who has commit rights to the website. SH to connect the advisory board for what we are seeking. ## io.js Discussion -**BB:** A discussion about https://github.com/iojs/io.js/issues/1336. and the tremendous back and forth Bert provides an outline of the discussion and the discussion -**SH:** There seemed to be a lot of the unknown and the endorsing a model that was resulting infrequent releases. A BDFL model, despite a lot of people talking to the contrary it is something we need to re-iterate what we are after here with the foundation. A couple key points we need to reiterate, MR made attempts, the Board and TSC the goal is the board work on business, financial, legal and the TSC be a self governing technical decision body of the project, the more we say that the better. Some people did weigh in on this but maybe not enough. There is a large amount of diversity from corporate to robotics/IoT to enterprise/Fortune 100 to others. There are different needs. Part of what the foundation can do is help to surface the needs of different members in the community. The needs of the various groups being met and heard. If the foundation is set up well, it should do all of that and balance those needs and also clearly try to set this up where the TSC can drive decisions. It does take some time to read through the docs and the intent is there. One of my concerns because of the discord, there are parts of this community and it does create risk and a lot of people of the community. Opens the potential for a lot of opportunity be displaced by other projects. Node has such a great ability to address it and work with it. -**IR:** I wonder if it could be done sooner, the optics of that look like only big companies are creating this foundation. due to a lot of people not “reading” it appears a lot of Io.js is community and node.js is corporate. Didn’t read or Didn’t trust are left seeing corporations only in node and io.js is not. There is a lot of corporations involved in both. Do we have a community representative on the board or other ways? Maybe move things around in the documentation. On the project plan there is election of silver sponsor, what are the details about it? -**MD:** In terms of the optics, we have a handful of companies with a significant amount of resource to help make this happen and two communities trying to come together. We should do something more. -**BB:** Maybe we could do an AMA and make themselves known and offer themselves as spokespeople. Can we make a video? -**IR:** What if we make it with everyone in here who have been working in good faith and present that we are working on this together. -**MR:** Fidelty’s representative is Travell Perkins, there is a video of him talking about this, we might want to tweet that up. -**TM:** We need a description about the end state of the foundation and the corporate folks to comment on the process. -**IR:** Can the linux foundation do something about other board members. And make them more personable/ faceful. -**MR:** Backing up, there is fear that is completely speculative and lot of it can be handled with more information. We have a document that separates the two, even if we publicize the board charter, the best thing we can get from this group of people that talks about how these kinds of boards operate. This is why we care about doing this kind of work and why you get involved and love what you do. Board description and split organization we have developed. -**DC:** I have a panel that we could use to publicize this stuff and making it well known. I have talked about giving away node t-shirts at both of our booths. Maybe there should be more of a way to increase the community feel. Action Item to make that more robust discussion on that. -**MD:** We can help with this and help with how to engage and where to engage. -**DS:** That ties into what I was going to ask the linux foundation, we are adopting this website that CW built and can put together, do we want to have a more blogging/contenty space on that or does the linux foundation want to do that with the NF is having set up. -**SH:** There is a path to make the website available. -**DS:** We need to develop a focal point and would be nice to have that come from the foundation site. -**SH:** There is a goal to make the website in the foundation. what if we formed a new working group. -**MR:** IO.js working group is very active and ideally we would have them come over and work with the node.js team. -**SH:** I will take that as an action item +**BB:** A discussion about https://github.com/iojs/io.js/issues/1336. and the tremendous back and forth Bert provides an outline of the discussion and the discussion +**SH:** There seemed to be a lot of the unknown and the endorsing a model that was resulting infrequent releases. A BDFL model, despite a lot of people talking to the contrary it is something we need to re-iterate what we are after here with the foundation. A couple key points we need to reiterate, MR made attempts, the Board and TSC the goal is the board work on business, financial, legal and the TSC be a self governing technical decision body of the project, the more we say that the better. Some people did weigh in on this but maybe not enough. There is a large amount of diversity from corporate to robotics/IoT to enterprise/Fortune 100 to others. There are different needs. Part of what the foundation can do is help to surface the needs of different members in the community. The needs of the various groups being met and heard. If the foundation is set up well, it should do all of that and balance those needs and also clearly try to set this up where the TSC can drive decisions. It does take some time to read through the docs and the intent is there. One of my concerns because of the discord, there are parts of this community and it does create risk and a lot of people of the community. Opens the potential for a lot of opportunity be displaced by other projects. Node has such a great ability to address it and work with it. +**IR:** I wonder if it could be done sooner, the optics of that look like only big companies are creating this foundation. due to a lot of people not “reading” it appears a lot of Io.js is community and node.js is corporate. Didn’t read or Didn’t trust are left seeing corporations only in node and io.js is not. There is a lot of corporations involved in both. Do we have a community representative on the board or other ways? Maybe move things around in the documentation. On the project plan there is election of silver sponsor, what are the details about it? +**MD:** In terms of the optics, we have a handful of companies with a significant amount of resource to help make this happen and two communities trying to come together. We should do something more. +**BB:** Maybe we could do an AMA and make themselves known and offer themselves as spokespeople. Can we make a video? +**IR:** What if we make it with everyone in here who have been working in good faith and present that we are working on this together. +**MR:** Fidelty’s representative is Travell Perkins, there is a video of him talking about this, we might want to tweet that up. +**TM:** We need a description about the end state of the foundation and the corporate folks to comment on the process. +**IR:** Can the linux foundation do something about other board members. And make them more personable/ faceful. +**MR:** Backing up, there is fear that is completely speculative and lot of it can be handled with more information. We have a document that separates the two, even if we publicize the board charter, the best thing we can get from this group of people that talks about how these kinds of boards operate. This is why we care about doing this kind of work and why you get involved and love what you do. Board description and split organization we have developed. +**DC:** I have a panel that we could use to publicize this stuff and making it well known. I have talked about giving away node t-shirts at both of our booths. Maybe there should be more of a way to increase the community feel. Action Item to make that more robust discussion on that. +**MD:** We can help with this and help with how to engage and where to engage. +**DS:** That ties into what I was going to ask the linux foundation, we are adopting this website that CW built and can put together, do we want to have a more blogging/contenty space on that or does the linux foundation want to do that with the NF is having set up. +**SH:** There is a path to make the website available. +**DS:** We need to develop a focal point and would be nice to have that come from the foundation site. +**SH:** There is a goal to make the website in the foundation. what if we formed a new working group. +**MR:** IO.js working group is very active and ideally we would have them come over and work with the node.js team. +**SH:** I will take that as an action item ## Enterprise versus Community -**BB:** Bridging enterprise and community. In IO.js they aren’t concerned with enterprisy. We have customers and they want this. Because the information has so many hops before it reaches the people who do the develop, it is often unclear. Maybe we could do a survey of CTOs/CIOs and that. -**TM:** normally this is done in the foundation that goes out and gathers this information, ideally we could do this in the charter and the bylaws. This is common. -**MR:** We did this for the io.js roadmap. +**BB:** Bridging enterprise and community. In IO.js they aren’t concerned with enterprisy. We have customers and they want this. Because the information has so many hops before it reaches the people who do the develop, it is often unclear. Maybe we could do a survey of CTOs/CIOs and that. +**TM:** normally this is done in the foundation that goes out and gathers this information, ideally we could do this in the charter and the bylaws. This is common. +**MR:** We did this for the io.js roadmap. ## New Action Items -**SH:** Connect up the io.js and node.js website working group to get more visibility about these going-on. +**SH:** Connect up the io.js and node.js website working group to get more visibility about these going-on. + + + + +## Next Meeting +Please join our next meeting, Friday April 24, 2015 at 3:00 PM PST / 6:00 PM EST connection information is available at [http://nodeadvisoryboard.com](http://nodeadvisoryboard.com). \ No newline at end of file