Engineering Working Group/Project Funding Framework

From OpenStreetMap Foundation

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.

Proposal process

  • Proposals will be processed by the Engineering Working Group.
  • Project ideas may be generated by members of the Engineering Working Group and by the wider community.
  • Before a call for proposals there will be a public review of project ideas. The Engineering Working Group will share these ideas with stakeholders, for example other working groups and the wider community, for review.
  • 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 engineering@osmfoundation.org. As always, Engineering Working Group meetings are open to the public.


Eligibility criteria

  • 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.

Scoring criteria

General remarks

No weights for the following criteria have been decided on, and this is not a top priority. The qualitative feedback from the criteria is expected to be useful already on its own. Suitable weights are more likely to be a matter of fine-tuning over the time, and we may find that we prefer not to exactly quantify them.

Note that there is some overlap between the criteria, because things like automated tests or communications skills help in many different ways. Please note also that some hard criteria like the requirement to make the software Open Source do not need to be restated here because they are mandatory anyway for all bidders.

Meeting the requirements

Does the bid meet the requirements from the call for proposals? Given that we allow for questions from the bidder answered to all bidders, the final bid should always fulfill all of the requirements.

Part of the requirements are the general objectives of OpenStreetMap, the OSMF, and the EWG. The EWG will ensure that these objectives are contained in each call for proposal.

Documentation

When there are APIs to implement, are these APIs comprehensively documented? When there are user interfaces to implement, what is the i18n strategy? The intended observable data model shall be sketched already in the bid. We consider the efforts reserved for documentation, planned documentation formats, and strategies for user acceptance tests with the community.

The EWG reserves the right to reuse all or parts of the bid as documentation when community is dissatisfied with the delivered documentation.

Security

Does the bid rely on now or later vulnerable components? In the best case, the implemented software is self-contained. In the worst case, it relies, directly or indirectly on components known to be stale and have security holes. To depend on external components is often bad, but only slightly bad if the component is well maintained and can be reasonably be expected to remain well maintained in the future. It is also only slightly bad if the external component is simple enough to expose only an insignificant attack surface.

Bonus points for a well-understandable security model in the bid.

Test cases, test strategy, and testing

The functionality shall be covered by automated tests. Good testing is known to be hard. Hence we look in particular on the efforts reserved for the testing stategy, finding test cases, and setting up the automated tests. We also value whether the laid-out test strategy is easy to understand and comprehensive. Bids may contain examples that can also serve as test cases.

Maintainability

What lifetime proposes the bid for the solution? What effort on maintenance do we expect for that lifetime? Good is a self-contained solution with little source code in a well-established programming language. Also good is if other work from the applicant is well-structured and well-commented. Excellent is a comprehensive coverage with automated tests on the functional level. Code coverage is good, but we know that that metric can be gamed. Bad is deeply tied dependencies, particular when it is difficult or impossible to find a drop-in replacement for that dependency.

Interoperability

Are the proposed interfaces accessible with state-of-the-art protocols? Open formats are a must-have. Simpler formats are better. E.g. JSON beats XML because XML allows for more complexity. Commonly used formats are better than arcane ones.

Cost

Bids must be reasonably priced. Bids with an unusually high cost or an unrealistically low cost may be rejected.

Communications with the community

The bidders are expected to conduct the communication with the community. There should be a plan for with communication channels will get which information, although it is understood that there might and shall be always more communication if helpful.

The EWG reserves the non-exclusive right to publish the successful bid after removing personal data of the bidder or bidders. The EWG may also publish only parts of the successful bid.

Person

We encourage the bidders to tell about the person or people that actually do the work. Experience is an advantage when it comes to experience with the community and their conventions and priorities. Likewise, programming experience will give the bidder's estimations more credibility.

Project management

Although we expect bidders to be able to work self-sustained and even to incorporate dynamic feedback from the community without moderation, the EWG would like to see a project plan such that the EWG can at any given time give a reasonable exact estimation to third parties how much progress has already been made.

How to apply

To apply visit the public Github repo. Please make a pull request against the main branch with your proposal in the form of a markdown document. Send a message to engineering@osmfoundation.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 Operator

  • 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.
Retrieved from "https://osmfoundation.org/w/index.php?title=Engineering_Working_Group/Project_Funding_Framework&oldid=9821"