Skip to content

Community Strategy

Jump to bottom
Leandru Martin edited this page May 5, 2026 · 2 revisions

Last Updated: 2026/05/05

Executive Summary

With Digital Bone Box, we aim to make first-time contributors feel welcome and help them easily understand how to get started with making helpful changes and improvements. We currently have a slow rate of contributions coming in from developers exteranl to Open Source with SLU, and we would like to see this metric rise. To aid this, we will focus on:

  • Ensuring there are always "good first issues" available for first-time contributors that are easy to work on without needing to know the whole project architecture or direction

  • Clear project structure and documentation so contributors can navigate the project easily and have quick access to information to answer their questions

  • Maintainer availability, so questions are answered quickly and pull requests are reviewed in a timely manner

Community Vision

Vision Statement

Over the next 1-2 years, a thriving community for the project would involve a regular influx of new contributors, as well as some regular contributors. Our goals for this are modest, as we do not currently have many contributors external to OPen Source with SLU.

Community Goals

  • Based on our current rate of new contributors, a healthy contribution rate that would be a slight improvement on our current contributor rate would be one pull request from an external contributor per month.

  • Response time < 1 week

Success Metrics

  • External contributor rate: Current: 1 per ~2 months, Target: 1 per month

Community Health Assessment

Current State

  • Contributors: 18 total, 3 external to Open Source with SLU

  • Active contributors: 1 external to OSS

  • Community size: 4 stargazers (all external to OSS), 10 forks

Strengths

  • Clear README and setup instructions
  • Several "good first issues"
  • Structured docmentation

Opportunities for Improvement

  • Parts of our project may be difficult to understand for new contributors without direct guidance. While some of this can be averted with good documentation, some structural changes may have to be made within the repository.
  • Adding a code of conduct

Contributor Journey

Discovery

How people find the project:

  • Currently, the only avenue for people to find the project is through GitHub search and Hacktoberfest.

  • Tactics: Add more issues labeled "good first issue" to make the project more visible on sites designed to surface projects with "good first issue" issues.

First Impression

What people see first:

  • README quality: Lays out the proejct description, purpose, and setup well. It could use improvements on the "features" section to either make it more robust or remove things that are not helpful for new contributors.

  • Documentation clarity: The documentation structure is clearer since the recent move to the wiki format. It has a defined structure improved on the previous version, but it is hard to judge its effectiveness because of how new the wiki is.

  • Code of conduct: No

  • Contributing guide: Yes

  • Improvements planned: Audit README file and determine what should be added or removed.

First Contribution

Path to first contribution:

  • "Good first issues" labeled: 15

  • Issue clarity: Generally, yes. Making sure issue definitions were clear was one of the first priorities in 2026.

  • Setup difficulty: Easy; project setup is defined clearly in project README.

  • Typical time to first response: About 1 week

  • Improvements planned: Look through all issues and determine which are appropriate for newcomers and should be given the "good first issue" label.

Ongoing Engagement

How you'll keep contributors:

  • Recognition: Contributors will be recognized through metadata added via the Fair Compliance Dashboard

  • Growth opportunities: Issues labeled "good first issue"

  • Community building: None planned currently

Community Engagement Tactics

Communication Channels

GitHub

  • How we use: Issues for bugs/features. Soon, the wiki feature will be used to host documentation.

  • Response time goal: consistently <1 week

  • Owner: Current project tech lead

Slack

  • How we use: Slack is used to host discussion.

  • Response time goal: <1 day

  • Owner: Current project tech lead

Content and Outreach

Currently, none is planned.

Recognition and Rewards

Contributors will be recognized through metadata added via the Fair Compliance Dashboard.

Governance and Decision-Making

Current Model

The tech lead lays out the goals for the project and assigns which issues need focus. Contributors may choose any issue to tackle.

Roles and Responsibilities

  • Maintainers: OSS tech lead. Full control over repository. Responsible for managing issues, reviewing pull requests, and maintaining community friendliness of repository.

  • Core Contributors: OSS internal developers. Responsible for tackling issues in fortnightly sprints.

  • Contributors: Other contributors are free to submit issues and pull requests.

  • Users: Users can submit feedback via issues or direct contact with the project maintainers.

Evolution Plan

Governance is planned to continue under the current model and evolve based on whoever is the project tech lead under Open Source with SLU.

Code of Conduct and Moderation

Code of Conduct

  • Status: Not yet created

  • Link: N/A

  • Enforcement: N/A

Moderation Guidelines

  • Response to spam: None yet (to be determined in future code of conduct)

  • Response to inappropriate behavior: None yet (to be determined in future code of conduct)

  • Escalation path: None yet (to be determined in future code of conduct)

Onboarding and Documentation

Contributor Documentation

  • README with clear project description

  • CONTRIBUTING.md with step-by-step guide

  • Developer setup instructions

  • Architecture documentation

  • Code style guide

  • Testing guide

  • Release process

Issue and PR Templates

  • Bug report template

  • Feature request template

  • Good first issue template

  • PR template with checklist

Onboarding Resources

  • Getting started guide

  • Video walkthrough

  • Office hours or onboarding calls

  • Mentorship program

Community Building Activities

Currently, none are planned.

Sustainability and Handoff

Long-term Maintenance

Maintenance will be handled by the current tech lead appointed at Open Source with SLU.

Succession Planning

  • Documentation completeness: No known gaps in documentation

  • Knowledge transfer needs: No known gaps in documentation

  • Future maintainer criteria: Determined by Open Source with SLU

Handoff Plan

Documentation has been improved by moving it to a wiki for clarity. Messy code in the repository has also been cleaned up in preparation for handoff.

Measurement and Iteration

How We'll Track Progress

  • Metrics to monitor: Rate of new pull requests per month

  • Review cadence: Every four weeks (two sprints)

  • Decision criteria: Target goals as outline above

Retrospective Questions

  • Are we attracting the right contributors?

  • Are first contributions getting easier?

  • Is community sentiment positive?

  • Are we responsive enough?

  • What's working that we should do more of?

  • What's not working that we should stop?

Clone this wiki locally