Catalytic Grant Application

DIAL Open Source Center

Basic Project and Contact Information

The first section of this form tells us about your project and the work you plan to do should you be accepted for this grant.


Dirty Jobs (Round 2)
User Privacy and Responsible Data
Improving User Experience

Project Self-Assessment Checklist

This section of the form is a quick self-assessment for your project, to help us understand where your project is on its journey of growth. Please answer to the best of your ability and use your best judgement. There are no right or wrong answers. The information here simply helps reviewers understand your project more quickly.

Software code:

Code has FSF or OSI approved license, and actively distributed at no charge.
Code easily discoverable and publicly accessible.
Code can be built in a reproducible way using freely available standard tools.
Full history of project's code available via source control system, in a way that allows any released version to be recreated.
Provenance of each line of code established via source control system. Third-party contributions committed with reliable information about code provenance.
Code contains README, NOTICE, and CONTRIBUTING files, (or sections of a README file).

Licenses and copyright:

Code is released under one of the preferred copyleft licenses explained in our [Licensing Principles](licensing-principles).
Any mandatory libraries dependencies of the project's code do not create more restrictions than the project's license.
Any such libraries, if applicable, are available as Open Source software.
Written policy or agreement in place for committers that defines which code they are allowed to commit and how they need to identify code that is not their own.
Copyright ownership of everything the project produces is clearly defined and documented.
Project name checked for trademark issues.

Software releases:

Releases consist of source code, distributed using standard and open archive formats that are expected to stay readable in the long term.
Releases signed and/or distributed with hashes/digests that can be reliably used to validate downloaded archives.
Convenience binaries, if applicable, are distributed alongside source code, but they are not official releases (a convenience provided with no guarantee).
Release process publicly documented and repeatable so someone new to the project is able to independently generate the complete set of artifacts required for a release.
Release plans developed and executed in public by the community, and approved by the project's governing body.
Project uses a standard release taxonomy (e.g., alpha, beta, semantic versioning).
Project has released at least one stable version.

Software quality:

Project is open and honest about the quality of its code. Various levels of quality and maturity for various modules are natural and acceptable as long as they are clearly communicated.
Community highly prioritizes producing secure software.
Well-documented channel to report security issues, along with a documented response process.
High community priority on backward compatibility, documentation of any incompatible changes, tools and documentation to help users transition to new release features.
Project strives for timely response to bug reports.
Outstanding bug list is easily discoverable, prioritized, and responsively triaged.
Bugs ideal for new contributors labeled as such.
Project includes unit and integration test suites of sufficient coverage. Coverage is documented.
Project includes enough documentation for anyone to test or deploy any of the software.
Project includes documentation for a software developer of moderate skill to set up their development environment to contribute.
Project documents how it integrated with other software projects, if applicable.
A Continuous Integration pipeline is used for testing and deployment purposes.
Project has shown & documented sufficient scalability over various dimensions appropriate to the project.

Community engagement:

Project has a well-known web site that points to all the information required to operate according to this maturity model.
Community welcomes contributions from anyone who acts in good faith and in a respectful manner and adds value to the project.
Contribution considered as source code, documentation, constructive bug reports, constructive discussions, marketing, and generally anything that adds value to the project.
Community is a "holarchy" (see [Governance Principles](governance-principles)) and over time aims to give more rights and responsibilities to contributors who add value to the project.
Methods for contributors to increase privileges such as commit access or decision power is clearly documented and is the same for all contributors.
Community operates based on consensus of its members who have decision power.
Project strives to answer user questions in a timely manner.
Project has an open real-time communication platform such as IRC.
Project's real-time communications if any are archived so that users can refer back to past conversations.
Community forum or other discussion platform for users to ask questions, w/reasonable response times from the community.
Active and diverse set of contributing members representing various constituencies.

Consensus building:

Public list of contributors who have decision power and documented governance process.
Decisions made by consensus among leaders and documented on the project's main communications venue. Community opinions taken into account but leaders have final decision.
Documented voting rules used to build consensus when discussion is not sufficient.
Vetoes or similar overrides only valid for code commits, and justified by technical explanation.
Important discussions happen asynchronously in written form on the project's main communications channel. Offline, face-to-face or private discussions that affect the project are also documented on that channel.

Project independence:

Project independent from influence of any single organization.
Contributors act independently as themselves as opposed to representatives of a corporation or organization.
At least 3 legally independent software contributors, and no single entity controls decision making within the project.

Project impact:

Project actively used in real-life scenarios, beyond demostrations.
Community able to clearly make the case for project's importance in international development or humanitarian sectors.
Submit Application