<div dir="auto">I would agree a metrics driven approach is rarely the best approach.  It's too simple and sometimes things take time to gel.<div dir="auto"><br></div><div dir="auto">Cheerio John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 19, 2021, 11:44 Andy Allan <<a href="mailto:gravitystorm@gmail.com">gravitystorm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 15 Jul 2021 at 23:29, Michal Migurski <<a href="mailto:mike@teczno.com" target="_blank" rel="noreferrer">mike@teczno.com</a>> wrote:<br>
<br>
> 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.<br>
<br>
I feel I should point out that I wasn't even a maintainer 5 years ago!<br>
So perhaps the story is the same, but the actual situation does<br>
change, and so I reiterate my request that you double-check with the<br>
people involved before drawing any more conclusions based on incorrect<br>
data.<br>
<br>
Another example is including the JOSM pull request data in your<br>
analysis, despite them not using github for development! That would<br>
skew your analysis somewhat. Again, it's something that could easily<br>
have been caught before you published your charts and targets.<br>
<br>
> 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.<br>
<br>
Having worked in various metrics-driven organisations, I'm deeply<br>
cautious about the choosing of targets. And I'm still deeply skeptical<br>
of these "contribution and maintenance patterns" that you have chosen.<br>
If the board starts measuring progress on those charts and your stated<br>
goals, then there are two simple ways we can "improve" those outcomes<br>
- simply close community pull requests immediately, and arbitrarily<br>
decline merging maintainer PRs. That's a step backwards for everyone<br>
involved, but would meet those defined goals.<br>
<br>
So my hope is that you set those charts and goals aside, and<br>
reconsider your approach.<br>
<br>
Thanks,<br>
Andy<br>
<br>
_______________________________________________<br>
osmf-talk mailing list<br>
<a href="mailto:osmf-talk@openstreetmap.org" target="_blank" rel="noreferrer">osmf-talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/osmf-talk" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/osmf-talk</a><br>
</blockquote></div>