User Tools

Site Tools


Open source project management

Tools and Process

  • Please see our communication-protocol.
  • We use github issues for planning and task management as well as for filing bugs.
    • Tag the issue with a difficulty label (sm/md/lg) before assigning it. Planning poker is useful.
      • sm: 1d
      • md: up to 5d
      • lg: larger than 5d
    • New features and large breaking changes use RFC (Request for Comment) process.
    • To track prototype explorations, file an issue and tag it with explore label.
      • Explorations are not RFCs. They allow us to explore without putting things on the roadmap.
  • Pull requests: see Contributors Guide

Team Structure (in github)

    • Overall direction of the project, subteam leadership, cross-cutting concerns.
    • New Core Team members may be nominated by the Core Team.
    • Core team members focus full time on the project.
    • Only the Core team can merge the develop branch to the long-term stable release master branch.
    • Trusted community members who have commit access to code repositories and sheriff the codebase.
    • Responsible for reviewing pull requests, testing them and landing changes to the develop branch.
    • New Contributors can be nominated by other Contributors and are confirmed by the Core Team.

Strategy Thoughts

  • Watch Dave Herman's talk
  • Everyone in community has input
  • State vision and principles (design principles) up front
    • These become a tool for resolving differences later
  • “No new rationals” rule
    • Decision making conversations should happen in public
      • Avoid the feeling of decisions behind closed doors
    • Leaders must take into consideration all points of view
    • It all goes sideways if you use new rational that no one has heard of until this point.
    • What things have you said in private vs public?
    • Need to give people a chance to have their say
  • Core team reviews all community input and makes a decision about how to move forward
    • Collectively responsible for steering direction of project
    • Core team aims for rough consensus.
    • Core team should not have “specialties” or “ownership” of verticals. Co-ownership of decisions.
      • Avoid module ownership model. It accounts for small decisions, but not overall budget and steering.
      • Avoid: “within this leadership team, Bob is in charge of X and Alice is in charge of Y.” This creates fiefdoms. Don't give people individual roles.
    • Summarize community input and make a decision
    • Founder gets “+100” on rolls when making decisions
  • You should have a synchronous chat medium and an asynchronous chat mechanism
    • Want a place where you can hang out and have sync communications (Gitter or Slack or IRC… CHOOSE ONE[gitter])
    • And a place where you can have async decision making (Github Issues or RFC repo or forum… CHOOSE ONE[gh issues])
    • Don't make decisions on Slack! It's not async, which means people miss decisions due to time zones.
    • Once you create a communication medium, you can't revoke it
    • Do not create a mailing list :D
    • You need to leave enough time buffer that everyone can weigh in.
    • Recommend discourse
      • (This has worked out great for us!)
      • Threaded conversations are invitation for endless rat-holing and Discourse does not have threaded conversations. Win!
      • In non-tree formats, creating a new thread is enough disincentive that people stay focused.

Thoughts on open source projects:

  • If you want collaborators, you have to understand what they want from this relationship
    • People want a voice in how a project is built.
    • Fun project after day job.
    • Learning
  • Be kind. Encourage your community to be kind.

Prior art:

contributing/open_source_project_management.txt · Last modified: 2017/06/21 12:10 by rbaynes