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

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
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.
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
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.
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.
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.
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.
46. 1.0 We’d launched the 1.0, grown to a team of 4, had our own names and meetings!
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