Skip to content

outline.md

Latest commit

 

History

History
87 lines (73 loc) · 3.7 KB

outline.md

File metadata and controls

87 lines (73 loc) · 3.7 KB

Implementing in Sprints Learning Path Outline

Learning Goals

  • The value of this sprint guide
  • Understanding prerequisites to successful InnerSource sprint
  • Learn additional activities for Sprint Planning
  • What to do during the sprint
  • What to do after the sprint

Target Audience

  • Teams who engage into InnerSource work, both Trusted Committers and Contributors
  • People who work/interface with these teams
    • Product Owners
    • Scrum masters
    • Project management
    • Team leaders

Outline

Introduction

  • Why do we need this guide

Project prerequisites

  • InnerSource checklist
    • Establish communication channel
    • README.md
      • Value of README.md
      • Structure of README.md
      • Examples of great README.md files
    • CONTRIBUTING.md
      • Value of CONTRIBUTING.md
      • Structure of CONTRIBUTING.md
      • Examples of great CONTRIBUTING.md files
  • Optional but highly valuable automation
    • Remove whitespace discussions from your code reviews - use linters
    • Implement pre-commit hooks to ensure your tests run before PR is submitted

Contribution prerequisites

  • General contribution guidelines
    • TC - establish rules for your team
      • Decide who does PR reviews and how long can a contributor wait for the review
      • Decide who supports contributors (see next section)
      • Decide when you need a design review prior to accepting pull requests (Request for Change practice)
    • TC - establish rules for contributors and spell them out in CONTRIBUTING.md - see prior section
    • Contributors - learn your area of work
      • Take time to learn the system you will contribute to
      • Review the host team requirements - their coding standards may differ from yours, even if you work in the same framework/language
  • How to organize your backlog
    • When contribution is more than one story
      • How to deal with large changes requested by the Contributor's team
      • What to do if their change has downstream effect
    • The importance of acceptance criteria
    • Indications of Contributor's commitment
    • Managing dependencies

Sprint Planning

  • TC - establish Contributor's point of contact
    • Their responsibilities
    • Communicating with Contributor
  • Contributor - show up and be prepared to confirm your capacity and availability to ensure you receive optimal support

During the Sprint

  • TC - ensure that Contributor's supporter is able to prioritize the support work over team backlog
  • Helpful tips for PR reviews
    • If you have to explain anything more than once - move that information into your docs
    • Apply the same diligence in reviewing your team's code as you do with external Contributors
  • Contributor - help close gaps in the docs to pave the road for future contributors
    • Document what you have learned from PR reviews, if it was not available or unclear prior to the reviews
    • Submit a separate PR for documentation fix, so your change does not have additional dependencies

After the Sprint

  • TC - remember to demo Contributor's work and recognize their contribution
    • Praise them verbally and in writing, include their peers and their manager
    • Give credit for their enhancements when reporting to your own leadership
  • Contributor - remember to thank your support and offer respectful feedback for future interactions
  • Re-establish expectations for post-Production support (link to 30-day warranty pattern)
  • What to do if contribution has not been completed

References

  • The Contributor section of the InnerSource learning path
  • The Trusted Committer section of the InnerSource learning path
  • 30-day warranty pattern
  • Possibly, other patterns, will add as needed