[2020-09-16] Create an SLA for responding to PRs, issues and comments

[Urigo]

@IvanGoncharov should have an SLA for responding to PRs, issues and comments

• assignee(s): @IvanGoncharov
• source: https://github.com/graphql/graphql-js-wg/blob/main/notes/2020-09-16.md#requirements-for-becoming-a-maintainer-15m-uri

---

Note: Action Item issues are reviewed and closed during Working Group meetings.

[brianwarner]

Just to clarify - this is a "C"LA bot, not an "S"LA bot. We're using EasyCLA to ensure that everybody has signed the GraphQL Specification Membership agreement, which is a requirement to participate in GraphQL. The Spec membership agreement isn't strictly a CLA, but the workflow is the same, so the tool fits in nicely.

On the topic of SLAs though, I think this is an area that is worth some introspection. SLA is a very specific term - the whole point being that it's providing a guaranteed response time, with consequences if missed. SLAs are inherently unidirectional, meaning that you're expecting a response no matter what. While this makes sense for paid vendors (e.g., uptime guarantees, applying security fixes, etc), it can also lead to really unhealthy situations when applied to volunteer maintainers like Ivan.

Maintainers do make an elevated commitment to a project to be diligent and timely in their work, and it's very healthy to openly communicate a key decision-maker's availability. However, that needs to be tempered with the fact that a single person can only do so much and, despite best intentions, life often sets priorities for us irrespective of our open source commitments.

In this particular case, instead of guaranteed response times (i.e., an SLA) I'd recommend instead looking at triaging things into reasonable response times, and looking at ways to spread the load. I understand from Ivan that there's been some progress on this front, and I'd encourage continuing down that path instead of the SLA approach.

[saihaj]

My bad I mixed up the two. Yeah I agree a SLA for an open source project can be little unhealthy from a maintainers perspective. For sure we can do triaging issues and even setup a GitHub actions bot and get some issue templates which can help speed up things. Something I can try setup after the TS migration. Probably will comeback to this action item and discuss in a meeting after 16.x.x is out

[brianwarner]

Good call on the actions, if you find something that works I would bet a number of other projects could really benefit from what you learn.

[saihaj]

I think we should enable GitHub discussions for https://docs.github.com/en/discussions
so we keep the issue tracker just for development related issues and Q/A or any other things that community might have can go there. If maintainers feel like this is an issue they can easily convert discussion to an issue.

[brianwarner]

I like that idea because it keeps the two things separate. Does it make sense for discussions to be enabled on graphql-js, or graphql-js-wg?

[saihaj]

Yeah we should enable for graphql-js. I don't think we need for working group. If there are issues in this repo we can always transfer them to project repo or vice-versa.