Engineering Working Group/Project Funding Framework
The following information will guide the Engineering Working Group's process for managing project funding proposals for software projects.
Project ideas are sourced from OSM community members, including members of the Engineering Working Group. Project ideas are then prioritized by the Engineering Working Group.
All code must be licensed under a free and/or open-source license (see below) and available without charge.
Qualities of a successful proposal
- Demonstrates a thorough understanding of the task, relevant codebases, and applicable technologies.
- Clearly defines the scope of work to be completed.
- Includes a list of applicant's relevant experience and in particular experience with the OSM tech stack.
- Lays out a detailed timeline, including as many milestones as make sense for the project in question.
- Focuses on the technical problems to be solved without evangelizing frameworks, languages, or other software tools.
- Communicates any potential roadblocks forseen by applicant and makes a good faith attempt to estimate non-financial support needed from the Engineering Working Group.
- Proposals will be processed by the Engineering Working Group.
- Before a call for proposals there will be a public review of project ideas, both those generated by members of the Engineering Working Group and those solicited from the wider community.
- The process will then proceed with a public call for proposals that includes a list of finalized project ideas.
- Proposals should be in response to one of the aforementioned project ideas. Proposals for project ideas not in the aforementioned finalized list may be considered in future funding rounds, but not at this time.
- Starting with the announcement of the call for proposals there will be a period in which proposals can be submitted. The length of this period will be decided on a project by project basis
- Proposals will be submitted in the form of a PR against the proposal repository on Github [link to be placed here].
- Proposals for a given project will be discussed in private to protect the privacy of applicants and publically scored by members of the Engineering Working Group.
- The proposal with the highest score for a given task will be accepted (See scoring criteria below). That outcome will then be communicated to all parties.
- A minimum of 5 members of the Engineering Working Group must be present to score proposals.
- A majority of members present may also vote to not accept any proposal for a given task, putting the funding process for that task on hold until the Engineering Working Group decides to open it up again.
- Engineering Working Group members are expected to encourage community involvement in the selection process. Members of the community may leave feedback on the proposal Github repo or, should they prefer, email the working group directly at email@example.com. As always, Engineering Working Group meetings are open to the public.
- Project length should be no longer than 6 months counted from the actual start of work.
- Applicants must make a good-faith effort to avoid conflicts of interest to ensure their proposal is judged on the merits of their application.
- Applicants must also agree to the reporting requirements and provide the OpenStreetMap Foundation with information needed to process their funding.
- Applicants and beneficiaries should have a history of volunteer OSM activity at least comparable in scope to the grant project.
- All software must be open-sourced. Media must be freely downloadable and published under open licenses (see definition at https://opensource.org/osd).
- The Engineering Working Group or another body of the OSMF must be able to build, set up, and run both a production grade and independent sandbox instance of all proposed work.
- All project participants should be in good community standing.
- Projects participants can be recipients of other funds of any form, including paid jobs, but need to disclose this during the application process. It is not necessary to share exact salaries.
- Proposals can be to support continuing work on projects already underway.
How to apply
To apply visit the public Github repo [link to be placed here]. Please make a pull request against the main branch with your proposal in the form of a markdown document. Send a message to firstname.lastname@example.org when it is ready.
By submitting a proposal to the OpenStreetMap Foundation, you certify the information contained in your proposal is correct and you understand that the decisions made by the OSM Engineering Working Group are final.
Responsibilities of parties
Engineering Working Group
- The Engineering Working Group will prioritize communicating status updates on proposals and projects with the community to ensure visiblity into all paid work.
- When deciding on proposals, members of the Engineering Working Group will declare relevant conflicts of interest and abstain from voting accordingly.
- The Engineering Working Group will ensure that the accepted proposals will receive funds. Payment schedules will be discussed with project operators and agreed to before work outlined on the proposal has begun.
- The Engineering Working Group will also respond to practical issues a project may face, answer questions from project operators, and generally offer assistance to the best of their abilities.
- Should a project operator fail to deliver on the terms outlined in their proposal, the Engineering Working Group may decide to withhold funds until such terms are fulfilled or, if need be, elect to suspend work permanently and cancel future payments.
- The Engineering Working Group will keep track of difficulties faced by project operators and in turn share lessons learned with future applicants.
- If the Engineering Working Group has larger issues with certain projects, it can ask the Board for assistance.
- The community is encouraged to ask questions of the Engineering Working Group during any phase of the projects and will be kept informed through public reporting.
- Project operators are expected to adhere to the work described in their proposal.
- Project operators should communicate any known possible practical issues that might arise during the execution of the project, especially those that might prevent them from fulfilling the acceptance criteria defined by the Engineering Working Group for their project.
- Every project is different, so project operators should also come up with their own planning and reporting schedule. While the first version of this should be part of the proposal, once accepted, the content of that plan can be refined in agreement with the Engineering Working Group.
- Reporting should be hosted on the public Github repo and be done in such a way that the community can have insight into work being performed.
- More generally, project operators must commit to communicating with the community, including sharing updates of their work, and fielding questions. At the end of the project, project operators are expected to start a thread on OSMF-talk about their project to share their work.