Skip to content

Latest commit

 

History

History
87 lines (50 loc) · 7.71 KB

sustainability.md

File metadata and controls

87 lines (50 loc) · 7.71 KB

##Sustainability plan and contributor pathway.

GOAL: If you somehow get stranded on a desert island, kidnapped by aliens, or simply move on to other projects at the close of your fellowship, how will your project continue on without you?

In this two-part activity, you'll first do some thinking and writing about creating a sustainable open science/open source project. Then you'll create a plan that will allow for an eventual project hand-off.

FORMAT:

For Part 1: A short (three paragraph) written Sustainabilty Plan
For Part 2: A new section in the CONTRIBUTING.md file in your repository.

TIME TO COMPLETE: 1 hour 30 mins.

TECHNOLOGY: Your favorite text editor and Markdown. A timer to keep track of brainstorming. Record and share your findings in your project's GitHub repository.

##Part 1. Sustainability Plan

###BACKGROUND You're all revved up and excited about your project, and you've made a committment to getting it off the ground and growing a fantastic community of contributors! #YES! (We're really excited too!) And we want your project to survive over the long term, regardless of where your career takes you or what other amazing things you dive into after the fellowship.

"Sustainability" for an open project here means three things:

  1. Ensuring that the responsibilty for this project doesn't rest solely on your shoulders. For your project to survive over the long term, others need the knowledge and skills to step-up and take over from you. They'll need to assume meaningful roles as core contributors and key decision-makers early on in the life of the project. For this to work, you'll need to ID potential key contributors right away and mentor them (see Part 2 for more on this). Who are your potential partners and stakeholders in this project? How can you avoid burn-out, for yourself and your partners/contributors? Are there steps you can take (around project documentation, around community managemnt, around project planning) that will help your project thrive, even if you're no longer actively involved?

  2. Planning for infrastructure and resource needs for the project over the long term. Your project may need a permanent home-- whether on a web server or within an institution that will support it for the long-haul. How will any project needs that arise in the years to come be funded? What are longer-term agreements you might make with an institution or like-minded partner organizations to help provide resources like space (virtual or physical), swag, sponsorship/funds, time and energy for updates, etc?

  3. Creating a project that transcends your target user group to make a broader impact. Part of "working open" is making work that's truly reusable and re-purposable. Your project likely has an audience or target user group that's informed by your particular research interests and anchored in your home community. But there's almost always part of a project-- whether it's a module of code, a particular piece of curriculum, or a really smart working process-- that can be useful to those working in totally different fields, on different projects. Amplifying your project's impact by sharing it across communities can help diversify and energize your group of contributors, sustaining and growing the project beyond your initial expectations. How can you reframe or expand your thinking about the work that you're doing so it's relevant to fields outside your own? How will you share your thinking and work beyond your own community? What are the connections you'll need to make to expand your project's reach?

###EXERCISE For each of the three points above, spend 4 minutes brainstorming and freewriting on an approach for your project. Use the italicized questions to jumpstart your brainstorm. Once you've finished brainstorming, spend 15 to 20 minutues organizing and re-wording your ideas and insights into a three-paragraph Sustainability Plan. (Brainstorming/Freewriting/Writing, 35-40 minutes).

##Part 2. Pathway: From Contributor to Project Lead!

###BACKGROUND: A key aspect of leading an open project is intentionally, consistently mentoring contributors so that they gain the knowlege, skills and experience to run an open project themselves. It's important that contributors know from the start that they can "level-up" skills by contributing; this valuable learning experience is a great motivator for participation.

By delegating work and encouraging contributors to take on increasingly important tasks, you'll eventually have the option of passing on leadership of your project to a capable, trusted contributor. Even if you never plan to hand off the project, you'll be adding to the pool of researchers who run open projects, enabling more open source experiments that further science on the web!

You may want to review some of the work you did in the User Personas and Pathways exercise to help inform your thinking about "leveling up" users/contributors. Note: The examples below are relevant primarily to development projects. If your project is a study group or curriculum, consider how you might shift a participant from being a student/attendee to leading sessions or creating their own curriculum.

You might start by grouping contributors in three sections: new, active and core. If it makes sense to have more levels (as we do in the Mozilla Leadership structure), add them. Here's a description of levels in a generic software development project:

New contributor This is anyone new to your project. They have filed a couple issues, joined in a discussion or sent their first pull request.

  • permissions: none
  • responsibility: none
  • recognition: welcome to the project!

Active contributor This person has made some good contributions, and may have started reviewing other contributions / working with other contributors.

  • permissions: commit privilege to repository
  • responsibility: review other contributions when tagged
  • recognition: varies; usually public thanks, special role or swag.

Core contributor A core contributor is someone who probably already leads a section of the project (maybe as a module maintainer), and has a strong contribution history, a great track record mentoring other contributors, and troubleshooting when there's difficulty with contributions or project decisionmaking.

  • permissions: commit privilege. Maybe can also grant commit to others.
  • responsibility: module maintainer, oversee all contributions to their module, participate in all community calls, and help welcome new contributors to the project.
  • recognition: varies. Public thanks, role or swag.

On your project, what kinds of responsibilities and permissions can you give to a contributor? Consider connecting strong contributors to resources offered via MSL: community calls, Sprints and other events, trainings, summmits, etc.

Here's an example, for a genric software project, describing a privilege-- the commit privilege, allowing users to merge changes to the main repository in GitHub-- that an ACTIVE CONTRIBUTOR would have, and a NEW CONTRIBUTOR could work towards.

###EXAMPLE Commit privilege: Commit privilege is granted to interested contributors who:

  • have landed at least 3 pull requests,
  • reviewed at least 3 pull requests, and
  • are in good standing with the community
  • responsibility: Committers are expected to review pull requests when flagged

###EXERCISE Write up specific roles and responsibilites for contributors to your project at each level and add them to your CONTRIBUTING.md file. Having these levels and/or privleges and criteria listed in your CONTRUBUTING.md file lets contrbutors understand how the project and community works, and what they can achieve. It also keeps active and core contributors accountable for their responsiblities. (Writing, 45 minutes)