Review https://devstats.graphql.org

[caniszczyk]

The GraphQL Foundation recently stood up a devstats service to provide some insights to the GraphQL community: https://devstats.graphql.org

You can also evaluate "project health" https://devstats.graphql.org/d/53/projects-health-table?orgId=1

If you're happy with this, we can make this the official source of project stats.

[jturkel]

Would it make sense to have separate graphql-spec PR stats for editorial changes (i.e. PRs tagged with "✏️ Editorial") vs. substantive changes (i.e. PRs not tagged with "✏️ Editorial")? Both kinds of PRs are important but they have very different health characteristics.

[IvanGoncharov]

@jturkel I don't think so, GraphQL as a standard is slow moving by design, here is relevant design principle: https://github.com/graphql/graphql-spec/blob/master/CONTRIBUTING.md#guiding-principles

Favor no change

As GraphQL is implemented in over a dozen languages under the collaboration of hundreds of individuals, incorporating any change has a high cost. Accordingly, proposed changes must meet a very high bar of added value. The burden of proof is on the contributor to illustrate this value.

Lee also gave a talk about this: https://youtu.be/mePT9MNTM98?t=1179

So I don't the absence of "substantive changes" is an indicator of project health. On the other hand, the fact that we have a bunch of simple "editorial" changes unmerged for more than half year is worrying.

[jturkel]

@IvanGoncharov - I completely agree! Hopefully the broken out stats will demonstrate exactly that i.e. editorial changes are getting reviewed and resolved quickly while substantive changes are getting reviewed and resolved (either by accepting the proposal or rejecting it) more slowly but still in a reasonable timeframe. We're not trying to optimize the throughput of substantive change but we are trying to make sure there's a healthy process for making them happen. By separating out the two types of PRs we can have two very different definitions of health. The Github stats on substantive changes could start to answer questions like: are proposals getting timely feedback? are they getting too much or too little feedback? are RFCs stalling out in certain stages of the process for too long? which issues are getting the most community engagement?

[leebyron]

This is great! Should we link to this from somewhere in particular?

[benjie]

Closing as stale (related to #1413, though this isn't technically an action item)