FedDIY/DEI.md

Diversity, Equity, and Inclusion Statement

FeDIY is committed to building a welcoming, inclusive community where everyone—regardless of background, identity, or experience level—can contribute to making DIY project sharing more accessible, federated, and community-driven.

Our Commitment

We recognize that open source communities historically have barriers to participation and representation. We are committed to actively dismantling those barriers and building a project where:

• Diverse voices are valued and heard. We seek perspectives from people with different backgrounds, identities, expertise levels, and life experiences.
• Newcomers and learners are welcomed. DIY communities thrive on curiosity. Questions are encouraged, and we provide guidance to help people grow.
• Accessibility is prioritized. We design for multiple abilities (physical, cognitive, visual, hearing) and multiple ways of learning (visual, written, video, interactive).
• Representation in leadership matters. We actively work to ensure decision-making roles reflect our community's diversity.
• Systemic barriers are addressed. We regularly examine and remove practices that exclude or disadvantage specific groups.

How We Live This Commitment

1. Inclusive Governance and Leadership

• Open decision-making. Major decisions are discussed transparently in GitHub issues, community forums, and public meetings.
• Diverse maintainers. We actively recruit and support maintainers from underrepresented groups in tech.
• Mentorship and growth paths. We provide mentorship, documentation, and support to help community members step into leadership roles.
• Regular feedback. We solicit feedback from underrepresented groups and use it to inform our practices.

2. Welcoming Culture

• Code of Conduct. We maintain a Code of Conduct that sets clear expectations and is actively enforced.
• Inclusive language. We use neutral, respectful language in documentation, discussions, and code.
• No assumptions. We don't assume gender, skill level, background, or motivation. We ask and listen.
• Celebrate diversity. We highlight contributions from people of all backgrounds and skill levels.

3. Accessible Documentation and Resources

• Multiple formats. Documentation is available in text, code examples, and (when feasible) video/visual formats.
• Beginner-friendly guides. We provide clear, step-by-step instructions for getting started, contributing code, reporting issues, etc.
• Accessibility standards. We follow WCAG 2.1 AA standards for web content and documentation.
• Clear jargon explanation. We define technical terms and explain concepts in multiple ways.
• Multilingual support. We welcome translations of documentation and aim to support non-English speakers.

4. Lowering Barriers to Entry

• Async-first communication. Not everyone can attend meetings in real time. We document decisions and support asynchronous participation.
• Timezone-aware scheduling. When we do hold synchronous events, we rotate times or provide recordings.
• Beginner-friendly issues. We label issues suitable for new contributors (good-first-issue, help-wanted) with clear guidance.
• Mentorship pairings. We connect newcomers with experienced contributors who can guide them.
• Financial support. Where feasible, we support attendance at conferences and events for contributors from underrepresented groups.

5. Safety and Respect

• Code of Conduct enforcement. We enforce our Code of Conduct fairly and consistently.
• Multiple reporting channels. People can report concerns anonymously or directly to maintainers.
• Swift response. We investigate reports promptly and take appropriate action.
• No retaliation. We protect people who report concerns in good faith.
• Continuous improvement. We regularly review our enforcement practices and adjust as needed.

6. Meaningful Participation Across Skill Levels

FeDIY recognizes that DIY communities span all skill levels—from complete beginners to experts. We support this diversity:

• Beginner-welcoming. Questions about basic concepts are always welcome. We celebrate learning.
• Diverse contribution types. We value bug reports, documentation improvements, design feedback, and testing—not just code.
• Recognition. We recognize contributions of all types, not just pull requests.
• Collaborative problem-solving. We work together on issues rather than placing all burden on issue reporters.

7. Addressing Domain-Specific Inclusion

FeDIY's federated project model serves many communities (crafting, making, cooking, etc.), each with unique demographics and barriers:

• Cross-domain awareness. We listen to leaders from different DIY domains about inclusion barriers specific to their communities.
• Extensible design. Our composable project model allows instances and extensions to tailor inclusion practices to their communities.
• Content policy thoughtfulness. We develop content policies in consultation with affected communities, not in isolation.

8. Accessibility for People with Sensory and Motor Differences

We are committed to building FeDIY to be fully accessible to people who are blind, low-vision, Deaf, hard-of-hearing, or have motor differences. This is not an afterthought—accessibility is a core design principle from day one.

Visual Accessibility

• Alt text for all images. Every image in a project (step photos, diagrams, material pictures) has descriptive alt text. We provide tools and guidance to help creators write good alt text.
• Text-to-speech support. The API provides structured data (project title, step descriptions, material lists) in formats suitable for text-to-speech clients. The bundled UI includes TTS functionality for reading instructions aloud.
• Color contrast. We maintain WCAG 2.1 AA contrast ratios throughout the UI. Project creators receive guidance on color contrast for their materials and visuals.
• Scalable fonts and layouts. Text can be resized to 200% without loss of functionality. Layouts reflow gracefully.
• Screen reader compatibility. The bundled UI uses semantic HTML, ARIA labels where needed, and is tested with popular screen readers.

Hearing Accessibility

• Captions and transcripts. Any audio or video content in instructions includes captions and full transcripts.
• Visual indicators. Audio cues or warnings are also provided as visual indicators (icons, text, animations).
• Sound-independent design. No information is conveyed through sound alone.

Motor Accessibility

• Full keyboard navigation. All functionality is accessible via keyboard. No mouse-only interactions.
• Keyboard shortcuts. Power users can navigate efficiently via keyboard.
• No time-dependent interactions. Users have sufficient time to read and interact with content. No auto-advancing carousels or expiring sessions that aren't adjustable.
• Large click targets. Buttons and interactive elements are large enough to easily activate with motor impairments.
• Accessible form design. Forms clearly label all inputs, provide clear error messages, and are easy to navigate with assistive devices.

Cognitive and Learning Accessibility

• Clear language. Instructions use plain, simple language and avoid jargon where possible.
• Consistent navigation. The UI is predictable and consistent across pages.
• Multiple content formats. Instructions are available as text, images, and (where possible) video or audio.
• Adjustable reading level. Where feasible, instructions can be displayed in simplified language.
• Craft-specific considerations. Different DIY domains may have unique accessibility needs (e.g., tactile learners for fiber arts, kinesthetic learners for woodworking). We work with community leaders to identify and address these.

Reading Comfort and Dyslexia Support

We recognize that reading text on screens is not equally comfortable for everyone. Dyslexia, visual stress, ADHD, and other reading differences are common, and we design our interface to accommodate them:

• User-controlled fonts. Users may choose their preferred typeface, including dyslexia-friendly options such as OpenDyslexic and Atkinson Hyperlegible. The bundled UI ships with at least one dyslexia-friendly font available by default.
• No font lock-in. The bundled UI must not prevent browser or OS font overrides. Users who have configured their own reading fonts system-wide will have those respected.
• Adjustable typography. Users can control font size, line height, letter spacing, and word spacing. Generous spacing aids many readers, especially for step-by-step instruction text.
• Adjustable line length. Long line lengths are tiring and disorienting for many readers. The UI provides comfortable default line lengths and allows users to adjust them.
• Low-visual-stress themes. High-contrast black-on-white can cause visual stress for some readers. The UI offers off-white or tinted background themes as an alternative. Users may also apply custom color themes.
• Settings are persistent. Reading preferences are saved to the user's account and apply across all devices. Unauthenticated users can set display preferences via browser storage.
• API-exposed preferences. Display preferences are stored in the API so third-party clients can retrieve and honor them without requiring duplication.

Localization and Language Inclusion

We design FeDIY to be usable and readable across languages and locales:

• All UI strings are externalized. No display text is hardcoded in the application. This makes community translation straightforward without touching application code.
• Community-driven translation. Translation files live in the repository. Anyone can contribute a new locale or improve an existing one.
• Content language tagging. Projects carry a language tag (BCP 47). Search and display respect declared content language.
• RTL script support. Layout supports right-to-left scripts (Arabic, Hebrew, Persian, etc.) from the first UI design pass.
• Locale-sensitive formatting. Dates, times, numbers, and units of measure are formatted according to the user's locale, not hardcoded to any single convention.
• No English-only default behavior. The platform's default experience does not assume English-speaking users. Language preference is surfaced as a first-class setting.

How We Maintain Accessibility

• From the start. Accessibility is part of the design process, not an afterthought.
• Testing. We test with real assistive technologies (screen readers, speech recognition, switch control) and with people who use them.
• Standards. We follow WCAG 2.1 AA as a minimum. We aim for AAA where practical.
• Feedback. Users with disabilities can report accessibility issues; we prioritize fixing them.
• Documentation. We document accessibility features so users know what's available.
• Creator support. We help project creators make their content accessible (alt text tools, captions, etc.).

Measuring Our Progress

We track the following metrics to assess our inclusion efforts:

Metric	Current	Goal	Notes
% of first-time contributors receiving response within 48 hours	TBD	100%	Ensures newcomers feel welcomed
% of issues with beginner-friendly labels	TBD	30%+	Lowers barriers for new contributors
Diversity in maintainer team	TBD	Improve	Goal is to reflect community diversity
% of contributors from underrepresented groups	TBD	Improve	Tracked via anonymous surveys
Code of Conduct enforcement rate	N/A	100%	All violations are addressed
Accessibility audit results	TBD	WCAG AA	Regular audits of docs and code
Accessibility issues resolved	TBD	100% within 30 days	User-reported accessibility bugs are prioritized

We will publish progress updates on these metrics quarterly.

Feedback and Improvement

Inclusion is not a one-time effort—it's continuous. We welcome feedback:

• Anonymous feedback form: [link to be added]
• Email: conduct@moturpin.com
• GitHub discussions: Open an issue labeled inclusion
• Community meetings: Bring concerns to our (scheduled) community meetings

If you see something we're not doing well, please tell us. We're committed to listening and improving.

Acknowledgments

This commitment is informed by:

• Contributor Covenant Code of Conduct
• CHAOSS Community Health Analytics and DEI Project Badging
• The Good Docs Project — documentation for inclusive communities
• Linux Foundation DEI Report
• Brittney Ball's "Creating an Inclusive Open Source Community"
• Communities in crafting, making, and DIY projects where we learn from existing inclusion efforts

---

Last Updated: May 2026
Maintained by: FeDIY Maintainers
Next Review: May 2027