Keynote: Accessibility In Open Source
summary
Claim: repositories with clearer code and higher test coverage attract more contributors, close issues faster and receive more stars; an analysis of popular JavaScript libraries shows a strong positive correlation (on a relatively small dataset) between test coverage and stars. Recommendations: keep tests as living documentation, follow language community standards and the single responsibility principle, write readable names and unit tests. Concrete example: a Java bowling class with descriptive methods plus unit tests makes onboarding and PRs noticeably easier.
AI-written summary · about
chapters (8)
- 0:00Start
- 0:09What is accessibility? What is inclusivity?
- 0:21Design a wheelchair ramp for a building entrance
- 0:34Design a better way for both wheeled and walking people to enter a building
- 1:52Designing with accessibility and inclusivity first creates a better experience for everyone.
- 2:34Yes these things make your product more accessible to the end user.
- 2:53But what about accessibility and inclusivity to open source developers?
- 5:03More inclusive code improves your product
related talks
30mDocs For All: Improving Open Source Accessibility
19mCommit to Change: How to Increase Accessibility in Your Favorite Open Source Projects
11mOpen Source Accessibility
29mBuilding Accessibility Testing into Your Workflow
43mHow to make your application accessible (and keep it that way!)
30mHow to Accessibility if You’re Mostly Back-End
43mHow to make your application accessible (and keep it that way!)
49mGitHub Accessibility: Bridging the Disability Divide through Code Collaboration