the last week before the NYC FRC regional postponement

I’m on the planning committee and co-volunteer coordinator for the NYC FRC regional. Like many members of the FIRST community, we were closely monitoring the situation. I mainly got my information from:

  • The NY Robotics Slack channel
  • A NYC planning committee mailing list.
  • Chief Delphi

In the Slack channel, one of the mentors on another team thanked me for my transparency. Now that I have time again :(, writing up a little more about the experience. This is a subset of what happened over the past week. I only shared things I feel comfortable nobody would have a problem with (without my having to ask for oks)

The timeline

Note: This is a very tri-state area view of the world. I’m well aware other events were cancelled.

  • March 6th – Central NY cancelled, a MAR event got cancelled during load in.
  • March 7th – Tech Valley cancelled
  • March 8th – Hofstra University (home of both Long Island regionals) announced first case
  • March 9th – Both Long Island regionals cancelled
  • March 11th – Hudson Valley suspended
  • March 12th – Entire season suspended – from FIRST HQ

The event

There was a lot of discussion about what to do – can we accommodate more teams, what if teams cancel, etc. While I heard about these a bit, they aren’t things I was responsible for.

Volunteer Coordinator

As volunteer coordinator, I had to be prepared in case we had the event with any number of volunteers dropping out at any time. I also wanted to be ready with an email to go out to the volunteers in case the event was cancelled. Highlights of this included:

  • Asked a CSA to cross train as a ref so we had an extra person who passed the test.
  • After the Long Island event was cancelled, emailed all their robot inspectors to see if anyone wanted to come to NYC instead. (I got two more robot inspectors from this)
  • With my co-volunteer coordinator, create a contingency/resiliency plan for every single key volunteer role. (It was helpful knowing where our areas of risk lie for next time regardless).
  • Came up with a plan for the expected smaller number of corporate volunteers and replacing non-key volunteers. [spoiler: part of it involved asking people in the stands to volunteer (or be drafted). If any team had more than 7 students in the stands, they were going to be helping!]
  • Wrote an email to our volunteers to send out if/when the regional got cancelled/suspended. FIRST HQ then came up with language so I wound up using mostly that and adding one sentence.

Safety glasses

The last number of years, I’ve been the supervisor of safety glasses and crowd control. This year, I was going to be one of the safety managers. So I was watching the safety glass situation as well. (My co-volunteer coordinator does most of the onsite/day of VC work). The problem being that we aren’t supposed to touch our faces so putting on safety glasses someone else wore (even after sanitizing) isn’t the safest of ideas. Kinda problematic for the safety glass station to cause a safety issue.

Options

  • No safety glasses lending at all. Teams bring their own or don’t come in the pits.
  • Give away free safety glasses. [I was worried if we went this route, we’d run out quickly because of the “free safety glasses” perception.
  • Ask Google to donate thousands of their promotional safety glasses.
  • Charge $1-$2 to buy safety glasses. Not a revenue based activity, but enough that people won’t ask unless they actually need them.

Communications

Early on, I wrote some text to send to any volunteers who asked about the event. My co-vc reviewed. I wanted to make sure it was a nice reply and didn’t accidentally make a statement on behalf of FIRST. I went with:

Good question. As of right now, we are planning on having the NYC FRC regional. As we see in the news, things are changing rapidly and we are actively monitoring the situation along with FIRST. As in past years, we will send all volunteers a reminder email 1-2 weeks before the event.

I was thinking that if I emailed this to anyone, it would get posted on Chief Delphi where everyone and their 8 friends would analyze it. The first person who asked me this did not post it. The second person who asked me actually asked on Chief Delphi. I replied with this text their so we cut out the middle man!

I was also active in communicating with any volunteers with concerns. Finally, I was active on the NY Robotics Slack. Back to that transparency thing, I think the key things I posted were:

  • It was the venues not the planning committees that were ending events. (Someone posted that they were expecting to hear something after the planning committees met)
  • We had a contingency plan for volunteers, especially if the corporate volunteers couldn’t attend.
  • That there are parties outside of FIRST that could have an effect. (The city banning large gatherings or the NYC school system banning clubs/field trips)

And finally, a note of appreciation for planning committees around the world

To those running FIRST robotics competitions, conferences or any large event, a big thank you. It’s really hard to make decisions:

  1. If you cancel early and didn’t need to -> people unhappy
  2. If you cancel the last minute/during -> people unhappy
  3. If you have the event and someone gets sick -> people really unhappy.
  4. If you have it and it isn’t smooth -> people unhappy.
  5. If you have it and it works out -> people happy.

There’s a lot of ways to fail here. And the only path to success if one that you don’t have a lot of control over!

[2020 devnexus] open development when you’re not in charge

Bob Paulin @bobpaulin

For more, see table of contents


Open Development

  • Code, processes of contribution available to whole organization.
  • Each project might have some extra governance
  • Developers can see, contribute and work with any code.

InnerSource

  • Communities not product teams
  • Communication is transparent
  • Code/doc/issues accessible to everyone
  • Code not usually externally available (outside company)

Apache Way

  • Community over code – can’t do something that helps one person, but is bad for the community
  • Consensus decision making
  • Open communications – message lists for all projects. “If it’s not on the list, it didn’t happen”
  • Earned authority – earned/voted on
  • Community of pears
  • Responsible oversight

More on Apache

  • Hard to kill an Apache project. Struts is still cutting releases. People are still maintaining it because important to someone.
  • When community goes away, project goes to attic

Open Development at work

  • Consultants – there to advise
  • “You can make buffalo go anywhere, just so long as they want to go there”. “You can keep buffalo out of anywhere, just so long as they don’t want to go there” – from “Secrets of Consulting” – recommends book for getting things gone
  • People will go to great lengths to avoid pain. They need to understand how open development reduces their pain

Stories

  • Tribal knowledge – once a month man comes down from the mountain and explains how things work to people
    • localized knowledge
    • can go with benevolent dictator on project
    • passed down mouth to mouth
    • only know if have relationship or proximity to person
    • document for different zip codes – needs to be clear to everyone. only use acronyms can google
    • document for dummies – should be clear to entry level developers
    • curse of knowledge – you’ve forgotten what is hard
  • Man behind the mirror decision making – architect went to talk to everyone. All felt good after meeting. Months later, realized things weren’t working together. Contradictions, misunderstandings
    • Set decision making to INFO – anyone can read decisions
    • People get upset/feel excluded when planning happens via direct message
    • People make decisions in meetings without realizing it was a decision
    • Appoint a decision crier – someone raise hands and says sounds like a decision and notes should write it down. Also helpful to have a secretary who should write things down.
  • Micro manager – can’t expect others to step up if still doing everything
    • Encouraged measured risk taking – let people take risks so can feel comfortable. Ex: can commit, but say something. Still don’t want it to go to production. Focus on learning over veto
    • Self driving car approach – still need to pay attention to wheel. Find bugs by finding mistakes people are continually making
    • Build reputation of new leaders – others start become accountable and show they can do it
    • Have to let make mistakes. Ok to commit something not perfect.
  • Bike shed to oblivion – people get passionate when arguing about something important (to them). What color should the bike shed be.
    • Enabling constructive dissent – community, consensus, earned authority
    • Elephant rules – acknowledge the undercurrents. What is actual reason for dissent. Knowing whether comes from gut feeling. Acknowledge what is problem and what is relevant
    • Build failure hedge fund – sometimes things go wrong. Determine if can learn from them or will ruin company? If the later, veto. Normal to fail from time to time

My take

Good end of the day. Some “obvious” and some to experiment with. Nice inspirational talk. I like the mapping of “general” principles to Apache principles.

[2020 devnexus] Developers Need to Take Notice – Malicious Attacks On Open Source Are Getting Worse

Speaker: Derek Weeks @weekstweets

Deck: https://speakerdeck.com/derekeweeks/devnexus-presentation-derek-weeks

For more, see table of contents


Fun

  • XKCD – reinvent the wheel – “We don’t want to reinvent the wheel, so every day we google image search “wheel” and whatever object comes up, that’s what we attach to our vehicles. Sure external dependencies carry risks, but so far, they’ve all been pretty good wheels”

Notes

  • If just moving fast, have a problem
  • DevOps teams use more open source
  • 70% deploy at least once a week
  • Challenge: be faster than evil
  • In past 5 years, breaches increased 70%
  • Can’t predict when vulnerability will come up. Have to use without knowing what will happen.

Attacks

  • Equifax is old news by now. Had opportunity to patch
  • Adversaries can also contribute to open source. ex: npm event-stream attack on CoPay
  • 2019 – Gems bootstrap-saas – added backdoor
  • Typo squatting
  • Backdoors
  • Happening to Docker, Python, Ruby, NPM, etc

Supply Chain

  • 2019 Software Supply Chain Report
    • suppliers (open source)
    • warehouses, (component repos)
    • manufacturers (softare dev teams)
    • finished goods (software applications)
  • Maven Central had over 200B downloads in 2019 alone. Almost 10% had known vulnerabilities they day they were downloaded.
  • JavaScript hit 10B package downloads in 2019 alone. Just over 51% had known vulnerabilities they day they were downloaded.
  • 85% of app is sourced from external suppliers

Enterprise vs Open Source

  • Multiple deploys per day vs versioned releases
  • Consistent Dev team vs fluid group of developers
  • Predictable/well resources vs variable resources
  • Deploymen tvs release frequency
  • Organizational performance vs popularity
  • Mean time to restore vs time to remediate vulnerabilities

Is it true?

  • TRUE: Projects that release frequently have better outcomes – more popular, attack more developers and higher level of support from foundations. Also, avoids problem of having to wait for all the transitive dependencies to be in a version we are using.
  • TRUE: Projects that update dependencies more frequently are general more secure
  • FALSE: Projects with fewer dependencies will stay more up to date. Interestingly, smaller teams tend to have less dependencies. Not clear if correlation or causationl
  • FALSE: More popular projects will be better about staying up to date

Behavioral clusters

  • Small teams; excellent time to update
  • Large teams; excellent time to update, often foundation supported, popular
  • Laggards – release slowly, more likely to be commercially supported
  • Features first – release frequently, but poor time to update
  • Caution – good time to update, but seldom completely up to date

Developers

  • 38% schedule dependency updates
  • 46% strive to use latest version
  • 50% have process to add new dependency
  • 30% have process to proactively remove problematic or unused dependency
  • 37% have automated tool to track, managed and/or ensure policy compliance of dependencies

If only do one thing

  • If stay on latest version, by default more secure and less security issues.

My take

Good talk. Especially once the projector issues were fixed. I lik the graphs and data behind the main points. I’ve seen similar presentations, but the newer parts/stats were still good to hear.