Visit UNICEF Global
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.
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.
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
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.
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.
Brand and identity
Git platforms: GitHub, GitLab, Bitbucket, Pagure, etc.
Pull Request workflow
READMEs
Using issues to manage product feedback
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.
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.
Automation tools (e.g. GitHub Actions, Circle CI, etc.)
Contribution guidelines
Documentation for developers
Documentation for users
Tool-chains
Python Sphinx
Hugo
Docusaurus (Facebook)
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.
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.
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
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.
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.
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
The above modules are typically offered in groups with other modules. The programmes and most common combination of modules are described below:
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.
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.
This quarter focuses on building structure, process, and organization into your Open Source project and community.
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.
This quarter focuses on building strong entrypoints for new contributors to enter your project community.
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.
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.
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.
Updated on 19 Sep 2022