Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building up the Electron Project: Team & Community Engineering

Bf47d3b9da3655bf19e815aaa5446d4a?s=47 Jessica
February 08, 2019

Building up the Electron Project: Team & Community Engineering

(Abstract)

This is a talk about how Electron went from atom-shell, a dependency of the text editor Atom with no plans of its own, to the widely adopted desktop framework running many of your favorite applications.

I'll share the process of getting internal buy-in for the project, road mapping, and getting the team started. I'll also talk about the importance of community engineering to the project. This includes technical decisions on the tooling to educate and support developers from different parts of the stack, create maintainable code for a small team, and excite a community around sharing their work.

Electron's initial unplanned position actually worked to its advantage after the team took shape and many of the experiences shared in this talk can be applied to the project you find yourself advocating for now (or later).

Bf47d3b9da3655bf19e815aaa5446d4a?s=128

Jessica

February 08, 2019
Tweet

More Decks by Jessica

Other Decks in Technology

Transcript

  1. Building up the Electron Project Jessica Lord JSConf Hawai’i 2019

    Team & Community Engineering
  2. she/her tw/jllord gh/jlord Jessica Lord

  3. Electron An open source library built at GitHub that combines

    Node.js and Chrome into one environment so that you can build desktop apps with HTML, CSS and JS/Node.
  4. atom-shell The year is 2015.

  5. Desktop Applications Could mean 3 teams, 3 apps each native

    to an OS. Or reach fewer users. Mac, Windows, Linux
  6. Atom GitHub’s text editor built with web technologies. HTML, JS,

    CSS Node.js
  7. CEF NW.js atom-shell

  8. None
  9. Finding atom-shell Some people had looked into the Atom org

    on GitHub to see what Atom was built on.
  10. VS Code Atom

  11. atom-shell becomes Electron An electron is a part of an

    atom!
  12. Me, in meetings

  13. “Electron is not important.”

  14. “No one will work on Electron.”

  15. “Use your weekends.”

  16. She Persisted Researched usage, the space, what was missing and

    made roadmaps.
  17. 40 More Hours for Electron! Began by spending my work

    weeks (on the Atom team) on Electron.
  18. None
  19. First Things First Documentation!!!

  20. Static Sites FTW They’re great. Please see JAMStack for more.

    JavaScript, APIs, Markup
  21. Documentation Body of docs exists, edit, standardize consistent language and

    markdown semantics.
  22. Single Source of Truth Docs live in the Electron repo,

    everyone gets a copy, they’re markdown. download, fork, clone
  23. None
  24. None
  25. None
  26. Stream docs from release tarball, parse and generate Jekyll front

    matter.
  27. Breadcrumb, Version, One-liner, Process

  28. From Markdown to Better A little bit of CSS to

    make notation more discernible and approachable.
  29. Improve readability with styles

  30. Don’t forsake the markdown

  31. An App of One’s Own Get people up and running

    quickly, comprehensibly and don’t give yourself a lot of extra work, either.
  32. Not Gonna Init Electron apps vary too much in scale

    and style to prescribe one way and it’s futile to try and maintain every permutation.
  33. None
  34. Electron Quick Start Clone, install and run for an Electron

    app. Hint at what’s possible but keep it familiar. HTML, CSS, Dev tools
  35. Dev tools, a couple API calls

  36. Developers, Developers, Developers Prioritize the education of devs who don’t

    yet realize what they can do.
  37. Electron API Demos App Electron app to show what you

    can do with Electron, sample code included; built to be opened up and examined.
  38. None
  39. Sample Code is the Code The demo app uses Node

    APIs to read its own files and web APIs to put them to the DOM in the app.
  40. ES6: just because you can doesn’t mean you should.

  41. Built to Open up Folder structure, naming conventions are all

    done so that new users exploring the insides can make sense of it.
  42. None
  43. Document structure and diagram of chain of events.

  44. Electron Community and Userland Electron needs the community and userland

    for support and is in a unique position to respond to the community.
  45. None
  46. 1.0 We’d launched the 1.0, grown to a team of

    4, had our own names and meetings!
  47. None
  48. Final Thoughts These are the slides near the end and

    are about what the point of all of this was.
  49. Community Engineering How people understand and experience a system. Putting

    new developers first.
  50. Electron’s situation was different Which was good. Unplanned, outside the

    view of dot com, was able to work on ideas (mostly) unchallenged and the project could respond to the community rather than internal forces.
  51. One Day, Electron will be gone As it should be.

    And hopefully one day our current ideas on documentation and talking about code will be gone, too.
  52. jlord.us/essential-electron

  53. Scale Down, People Up Don’t give yourself extra work! Things

    can probably be simpler than you think.
  54. Jessica Lord tw/jllord gh/jlord