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

[Michal Migurski]

Hey Andy, thanks for your response!

I know that this conversation touches on your extensive contributions to OSM’s infrastructure and code over the years, and I am not intending to criticize your work. My intent is to stick very close to the original topic: feedback on Mikel’s EWG proposal. It is missing a plan for measuring its own success so I’m looking toward our existing track record in critical OSM repositories.

You’re right that it’s normal for a software project to have more and faster contributions from its own maintainers. Mateusz also says this in his response to the thread:

> I would add that situation where there are people who consistently make high quality PRs and are not becoming maintainers would be a bit weird. So nonmaintainers PRs are very likely to be of lower quality and/or get abandoned and so on - as people making high quality PRs are typically becoming maintainers. As result both groups are self selecting, and such differences are to be expected.

Our software projects so far have not gained contributors and maintainers over time, and in fact the opposite has happened. iD no longer has Bryan or Quincy contributing to its development. The team behind the API & website has been reduced to you and Tom for many years. We are lucky to have had dedicated and skilled people like yourself, but the board has not chosen to prioritize or support a conducive environment for growing the community of engineers. This story has been consistent over the past five years and should be cause for alarm for the majority of community members who prioritized stability in the recent survey.

The current EWG proposal seeks to address the gap. My analysis and personal experience both point toward a measurable goal for the EWG of increasing diverse contributions to OSM software projects. I’m also making the raw data for my earlier charts available here for anyone interested in core repo contribution patterns: https://athena-osm-checks.s3.amazonaws.com/osm-website-git/data/ds=2021-07-01/PR-data.txt

My intent here is not to critique the excellent work that you’ve done as a maintainer of the API & website throughout OSM’s history, and I’m grateful that you’ve helped guide a few of my PRs to acceptance. Instead I am proposing a way for the board to set a goal for the EWG using readily-available public data. We’ll know the working group is successful when we see a movement in the contribution and maintenance patterns on core repos.

-mike.

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

> On Jul 15, 2021, at 6:58 AM, Andy Allan <gravitystorm at gmail.com> wrote:
> 
> On Wed, 14 Jul 2021 at 18:55, Michal Migurski <mike at teczno.com> wrote:
>> 
>> 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.
> 
> I find these results deeply unsurprising. You've highlighted that PRs
> from bots (i.e. dependabot) are quick and easy to merge. What else
> would you expect here? You've also highlighted that PRs made by
> maintainers are usually merged quickly. So again, is it really
> surprising that maintainers are good at writing PRs that pass the
> tests, are easy to review, and likely to be merged without need for
> changes? Isn't that likely to be one of the abilities expected of a
> maintainer?
> 
> That community changes can take multiple weeks to merge is also not
> surprising. By ignoring the "changes requested" label, any review
> status on the PR, and whether PRs need follow-up commits added later
> (or rewritten wholesale into a new PR) before being merged, I don't
> know what conclusions you can draw from these statistics. There's no
> expectation that community contributors must be able to write PRs that
> pass the tests, are easy to review and likely to be merged without
> need for changes. That would be an unreasonable expectation for an
> open community, as opposed to a corporate environment. So naturally
> it's expected that people will make PRs and need help to get them
> merged, and that PRs will sit in the "waiting for changes" state for a
> while until they have some free time to do so. I also don't expect our
> volunteers to immediately have time to amend their PR after review,
> but your analysis seems to expect that all community PRs are
> immediately eligible for merging.
> 
>> My conclusion from these graphs is that OSM’s software is not encouraging a healthy level of community involvement.
> 
> That's a heck of a conclusion to make from two poorly constructed charts.
> 
> Perhaps in future, before attempting to make sweeping conclusions on
> such flawed analysis, you could give the maintainers of the project a
> chance to discuss with you your methodology? That way we can get some
> more useful analysis and ideally some actionable conclusions. Because
> I put in a ton of effort, week in and week out, year after year to
> make it easier to contribute, and I'm happy to hear how to improve the
> situation further, but posts like this just don't help.
> 
> Thanks,
> Andy
>