[Osmf-talk] Seeking feedback and interest in the OSMF Engineering Working Group

Michal Migurski mike at teczno.com
Wed Jul 14 17:52:29 UTC 2021


Thanks for working on this, Mikel! An active EWG is necessary for the stability and longevity of OSM.

I’d like to see the proposed charter address motivation and cooperation with the OWG.

One of my goals in 2020 was to make it easier for newcomers to contribute to the OSM website repository by reducing friction when installing it locally. I joined Jaime Alessio’s Oct 2019 PR (https://github.com/openstreetmap/openstreetmap-website/pull/2409) to add Docker supported to the dev environment. I’m proud that we got this merged but it took almost 1 1/2 years with sustained persistence and mild nagging. Summary here: https://www.openstreetmap.org/user/migurski/diary/396190

This experience will probably need to change to successfully attract contributors to the EWG. I’m happy to have earned a “contributor” status in the repo but I’m probably unusual in my pig-headedness in making it happen. It’s well-established in open source software communities that speedy acceptance of community contributions into main is a self-reinforcing driver of enthusiasm and growth. One of Google’s DORA metrics, Lead Time For Changes, suggests measuring time for commits to enter production (https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance).

OSM isn’t great at this:


(graphs at http://mike.teczno.com/img/osm-prs-2016-2020.png)

These graphs are built from our Github repository pull requests (PRs) over the past five years. The bars in blue are composed solely of commits from core committers and a handful of bots vs. PRs in green with any other participants included. We see that community PRs are accepted approximately half the time, while owner-only PRs are merged almost always. We also see a long-standing pattern of community changes taking multiple weeks to merge. These closure speeds are faster than recent years though slower than 2016. My conclusion from these graphs is that OSM’s software is not encouraging a healthy level of community involvement.

Can the EWG proposal include measurable goals for moving these numbers and a commitment from Operations to help? These are the changes we should be looking for:

	• Raise the number of community PRs
	• Lower the proportion of owner-only PRs
	• Speed up the merge time of community PRs (Lead Time)
	• Raise the merge rates of community PRs

-mike.

> On Jul 6, 2021, at 5:55 AM, Mikel Maron <mikel.maron at gmail.com> wrote:
> 
> The Engineering Working Group is restarting with a new charter. OSMF is seeking feedback on the proposed charter, and also interest in joining the group. You can share here on this thread, or directly with board at osmfoundation.org.
> 
> For background on the revival of the Engineering Working Group, there are notes in last month's Board minutes.
> https://wiki.osmfoundation.org/wiki/Board/Minutes/2021-06#Engineering_Working_Group
> 
> The draft of the proposed charter is below, as well as sketch of potential budget.
> 
> Thanks in advance for your input!
> 
> -Mikel, for OSMF Board
> 
> 
> ## What we do
> The Engineering Working Group is charged with
> - Handling software development paid for by the OSMF
> - Putting out calls for proposals on tasks of interest, and accepting proposals on other tasks
> - Offering a platform for coordination of software development efforts across the OSM ecosystem
> - Managing OSM’s participation in software mentorship programs
> 
> For handling paid development, "tasks" include development of new features, maintenance of code, documentation, and other tasks that improve the developer experience. We encourage applications from skilled individuals who aren’t professional developers, professional contractors or companies, as well as those who are. In our first round we will look for projects that don’t need much management and will apply the principles of the [Hiring Framework](https://wiki.osmfoundation.org/wiki/Hiring_Framework).
> 
> We encourage standardization and shared efforts between projects by bringing together developers with similar interests. This work also includes responding to emails and directing people at other people or appropriate resources.
> 
> ## Join us
> 
> We are looking for people with experience with the OSM software ecosystem, developing software, or managing software development.
> 
> ## Prospective Budget
> 
> Our first budget will outline further detail, and is subject to change after the WG forms and we have initial meetings.
> 
> - Estimated 50k initial budget, same scale as microgrants
> - 50% of funding to core OSM software used to edit OSM or OSM-specific software run on the OpenStreetMap website
> - 30% of funding to OSM QA and analysis tools and OSM-specific software in common use (category named TBD)
> - 20% of funding to consumer-facing OSM software and new software
> 
> All code written must be open-source and available without charge.
> 
> We would like to budget for administrative assistance for meeting minutes, document management, and other administrative tasks and believe this is best handled through existing contracts the board has in place.
> 
> 
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
> _______________________________________________
> osmf-talk mailing list
> osmf-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk

----------------------------------------------------------------
michal migurski- contact info and pgp key:
sf/ca            http://mike.teczno.com/contact.html




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20210714/45e25b79/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osm-prs-2016-2020.png
Type: image/png
Size: 43147 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20210714/45e25b79/attachment.png>


More information about the osmf-talk mailing list