Mentoring modules

docs
legal
mentoring
testing
Justin W. Flory
Overview of learning modules currently offered through the UNICEF Open Source Mentorship programme.

The UNICEF Open Source Mentorship programme offers multiple learning modules and mentorship topics. This page provides an overview of the different modules currently offered through the Open Source Mentorship programme.

1. Offered modules ðŸ”—

The following modules are currently offered in UNICEF-facilitated mentorship:

Building an Open Source community is like building a house. A good house must have a solid foundation, and Open Source projects are no different. The licenses surrounding Open Source, sometimes called Free Software, are part of the foundation of your Open Source project. This module introduces the Open Source Definition, the types of Open Source licenses, and how to be strategic and intentional in your choice of licenses.

The Open Source licenses are the legal foundation of your project. By the end of this module, you should understand how the limits and bounds of your Open Source license impact the rules of your business model.

Topics included:

  • Contributor License Agreements (CLAs)

  • Licenses (MIT License, Apache License, GPL licenses, etc.)

    • Copyleft licenses

    • Permissive licenses

  • Open Source business models

  • Open Source Definition

  • Open Source Initiative

1.2. Launching your Open Source project ðŸ”—

Lift-off! You know your licensing strategy and you are ready to go Open Source. Now what? This module introduces Open Source forges and collaboration platforms. You will learn how to use these tools effectively and efficiently, as well as ways to structure your project in order to scale with a community over time.

This module is for early-stage Open Source projects that are still in active development. By the end of this module, you should understand common Open Source development workflows and how to enable collaboration with advanced features of your source code-hosting platform.

Topics included:

  • Brand and identity

  • Git platforms: GitHub, GitLab, Bitbucket, Pagure, etc.

  • Pull Request workflow

  • READMEs

  • Using issues to manage product feedback

1.3. Open Source documentation ðŸ”—

If everyone knew a programming language, source code alone might be enough. But most people do not know a programming language, and some people who use your project will not be engineers or developers with specialized knowledge. Planning, creating, and maintaining Open Source documentation fills an unavoidable gap to improve accessibility and understanding of your Open Source project. This module introduces the following:

  • Common tools and platforms used for Open Source documentation;

  • How to build an automated pipeline to deploy new documentation in real-time;

  • Building a documentation culture and community in your project;

  • Creating structure to enable external contributions to documentation.

By the end of this module, your project will have an Open Source documentation site and a plan on how to maintain the documentation over time. This module is for any Open Source project, at any stage, that wants to improve their documentation acumen and invite others to collaborate and contribute.

Topics included:

  • Automation tools (e.g. GitHub Actions, Circle CI, etc.)

  • Contribution guidelines

  • Documentation for developers

  • Documentation for users

  • Tool-chains

    • Python Sphinx

    • Hugo

    • Docusaurus (Facebook)

1.4. Continuous Integration for continuous contribution ðŸ”—

As in life, Open Source projects will change over time. As you manage new changes to the source code of a project, how do you verify that new changes do not break existing code? You can spend time manually validating changes and testing them locally. But you can also automate it using workflow automation tools. This module introduces Continuous Integration (C.I.) and Continuous Deployment (C.D.) in an Open Source context.

By the end of this module, your project will have a working CI/CD pipeline for your Open Source repositories. New changes to the repositories will be validated against a basic set of tests, depending on what kind of software you are building. This module is for any Open Source project, at any stage, that wants to improve code quality, code health, and save time from manually testing and validating new code changes.

Topics included:

  • CI/CD platforms (e.g. Circle CI, GitHub Actions, Jenkins, etc.)

  • Code test coverage and unit tests, if applicable

  • Deploy new changes to software or documentation to a testing or production environment

  • Pull Request Workflows with a CI pipeline

  • Code health tools to monitor and alert to best practices and warning signs

1.5. Archetypes: Shape and size of Open Source over time ðŸ”—

Building an Open Source community is like building a house. Before you can invite people over, you need a solid foundation to build your community on. If you have completed the previous modules, your project is primed for working with new contributors. This reflective module introduces you to the Mozilla Open Source Archetypes report and understanding a theory of change for Open Source.

By the end of this module, you will have an understanding of the different forms an Open Source project and community may take. You will also be able to identify where your project falls and make predictions on where it will go next. This module is for any Open Source project anticipating growth, change, or evolution to its code or the community.

Topics included:

  • Project archetypes:

    • Business-to-Business (B2B) Open Source

    • Multi-Vendor Infrastructure

    • Rocket Ship to Mars

    • Controlled Ecosystem

    • Wide Open

    • Mass Market

    • Speciality Library

    • Trusted Vendor

    • Upstream Dependency

  • Business models:

    • Professional/enterprise versions

    • Services around your product

    • Services *are* your product

    • Content

    • Packaging

    • Franchising

    • Training

2. Module programming ðŸ”—

The above modules are typically offered in groups with other modules. The programmes and most common combination of modules are described below:

2.1. 12-month Venture Fund contracts ðŸ”—

12 months is the standard length of the Open Source Mentorship programme. 12-month contracts are typically offered through the procurement process through the UNICEF Venture Fund. The breakdown below orders the modules and adds context to what content is covered.

2.1.1. Q1: Foundations ðŸ”—

This quarter focuses on establishing an Open Source project and laying the groundwork for future work.

Milestones:

  • Determine licensing strategy for Open Source intellectual property (i.e. permissive or copyleft). Apply an Open Source Initiative-approved license to a public source code repository.

  • Create READMEs (in English) for all public repositories. READMEs should include:

    • Overview of specific repo

    • Developer environment instructions (i.e. how to set software up)

    • Note how repo connects into overall product

    • List of any Open Source software used to create product (including tools and frameworks).

  • Create a public Open Source documentation with a corresponding public source code repository. Use automation tools to set up automatic deployments of HTML documentation site from public source code repository (e.g. with Continuous Integration).

  • Establish an Open Source quality assurance process. Explore unit testing frameworks for front-end/back-end software, if applicable. Document user stories and test cases for games, if applicable. Document data structures and algorithm decisions for data science, if applicable.

  • Identify a Code of Conduct for any public Open Source repositories. Upload it to public source code repositories. Create internal documentation for how to respond to a Code of Conduct report, if one were to be made.

  • Follow the Pull Request Workflow when contributing code into your Open Source repositories.

2.1.2. Q2: Structures ðŸ”—

This quarter focuses on building structure, process, and organization into your Open Source project and community.

Milestones:

  • MUST have a OSI-approved license distributed with public source code repositories by end of Q2.

  • Create contributing guidelines for all Open Source repositories. Explain how someone makes a contribution to the projects.

  • Create public tickets/issues that correspond to planned features and known bugs/problems with Open Source repositories.

  • Use a public project management board to track progress on public tickets/issues (e.g. Taiga, GitHub/GitLab Projects, JIRA, Trello, or similar).

  • Add either developer or user documentation to the Open Source documentation site. (Hint: Developer docs often include API docs, architecture or system state diagrams, or deployment guides.)

  • Advance Open Source quality assurance. Target 15% code coverage for unit tests, if applicable.

2.1.3. Q3: Entrypoints ðŸ”—

This quarter focuses on building strong entrypoints for new contributors to enter your project community.

Milestones:

  • Advance Open Source quality assurance. Set up a Continuous Integration / Continuous Deployment (CI/CD) pipeline from source code repository. Set up checks or tests on new Pull Requests. Target 40% code coverage, if applicable.

  • Add ticket/issue templates to source code repositories for new tickets opened by the public and the core contributor team.

  • Create "Good First Issues" for bite-sized, low-commitment contributions for new developers to make to your source code repositories.

  • Establish a public communication platform for the public to interact with project development team. (Suggested: UNICEF Venture Fund community forum.)

  • Add either developer or user documentation to the Open Source documentation site, whichever was not completed the previous quarter.

2.1.4. Q4: Graduation ðŸ”—

This quarter leaves time to address any pending items from previous quarters, and looks at creative opportunities based on the context of a specific project.

Milestones:

  • Finalize Open Source documentation. User and developer documentation should be available.

  • Finalize Open Source quality assurance. Achieve 80% code test coverage, if applicable.

  • Growth planning, contextual analysis, and focused support with Open Source Mentor.