Open Source Developer Interview: 05.16.2018

Conversation with Scratch project developer (5/16/18)

Highlights:

FRAMEWORK

• Their project is both internal and an open source project - it's unique (similar to US Forms System right now)
• If you have more than one repo, they would suggest a mono-repo (with sub-repos) - easier for cross-repo PRs
• Use internal people starting on team to determine how the hands-off repo onboarding works
• Consider providing a way for people to link back or mention US Forms System if they fork the repo - logo, tagline, link back, etc.

DOCUMENTATION AND STYLE

Communication / Documentation

• 'just the code isn't enough for people'
• Identify 'lowest common denominator' contributors, and build for that experience - for Scratch, these are kids (!)
• Important to communicate internal design decisions to the public (messaging to OS community)
• readme page should read like you dont know anything about project
• 'getting started' - make sure there's no other intervention required, it will work on Mac / Linux / Windows
• Document anything that is particular about how you want to do things - 'if you're going to be picky, tell people'

Ergonomics is even more important in OS

• Examples directory of how you might want to use components
• Provide documentation for commonly requested flows such as: -- Publishing your modified code to github pages (example) -- Building (they use NPM) -- Working on translations - being able to build new translations and updating them

WORKFLOW

Workflow Management

• They suggest we use templates (issues, features, etc)
• They don't accept orphan PRs (must be tied to an issue)
• 'Help Wanted' on anything that they will accept PRs for -- they are things that are well documented in how they should be done, self-contained. -- Mostly bugs. -- Avoid stuff that requires refactor of existing code.

PRs and Deployment

• Make reviewing easy
• Good foundational test for reviewing PRs
• Linting is good
• 'Nothing is more frustrating than having to ask people to remove white space'
• NPM-test + Travis runs when you open PR --> tells you immediately that it failed, and sends an email
• On github - you can require that the PR pass before being submitted
• Documentation around figuring out what went wrong

Team Management

• 'it takes so much time'
• They have one main triage person, then a separate point person on each repo to make sure someone responds in a 'timely way' so people feel like they're being listened to
• SLA for communication - acknowledge within a day or two

COMMUNITY

Outreach

• None; they really don't do any (had no suggestions for us)

Core Contributors

• Small group of kids who are paying attention
• Different skill levels
• A few adults as well - all a bit transitory
• 'Recurring characters'