Call for more co-maintainers (as I step down)

[Minoru]

Hey everyone,

I haven't paid attention to recent issues and PRs, and with some (happy) life changes that's coming my way, I don't expect I'll have time for Hakyll anytime soon. Thus I'm stepping down as a co-maintainer.

I really want Hakyll to exist and to trive, so let me describe what's required to maintain it. Perhaps you, the reader, will be interested in picking up some of that work!

Keeping Hakyll in Stackage. This can really be done by anyone who's capable of running cabal build (with help from someone who has commit access to Hakyll and Hackage). You add yourself to Stackage's build-constraints.yaml so you get pinged by issues like commercialhaskell/stackage#7529. For each ping, you update the dependency bounds in hakyll.cabal, submit a PR to Hakyll, merge it, make a Hackage revision (manually applying the changes from the PR), and comment about it on the Stackage issue. 95% of the time, it's as trivial as this. The other 5% is when a dependency API changes and you have to fix the compilation errors. This is usually easy too; and when it's not, you can tag Jasper and add a "help wanted" label.

Issue triage. If you want to explore Hakyll's capabilities, this is for you. People come with all sorts of problems; some trivial, some advanced. I think I was able to answer about 20% from my own experience of building a blog. The rest I was usually able to help somewhat by code-diving.

Reviewing trivial changes. Usually it's version bumps (#1036), but sometimes it's new features (#975) or generalisations of existing APIs (#957). Your job here is to ensure that the additions are consistent with what Hakyll already has: function names should be similar, arguments should be in the similar order (if that makes sense), code is in the appropriate module, etc. Reviewing such changes is a good catalyst for learning about Hakyll's APIs.

Reviewing big changes. This is the area where I struggled the most, but it got slightly easier as I learned about Hakyll's internals (and maybe even Haskell). The most recent such change is async runtime and its refinements (#844, #863, #946). These changes sometimes require a judgement call about their appropriateness or the way they are implemented; I just deferred to Jasper if I was unsure of what to do.

That's it; the four main areas of work as I see it. I should note that each area can possibly be covered by multiple people, so nobody is too stressed any everyone's back is covered.

I don't yet know how new co-maintainers will get appointed. I guess it's up to Jasper. I personally believe in meritocracy, so should point out that most of this work doesn't require commit access on GitHub or maintainership on Hackage. If you're interested in working on any of this, please just start; there's always someone who can merge your PR and push that release.

Please don't break this thing too much, I use it for my blog still ❤️