@sclv I see
There’s a lot of flexibility in filling these roles. They could be
- Occupied by the same person, or different ones
- Rotating per release, or few releases
- Filled by a keen community member, or a paid professional
Currently, the GHC.X.hackage maintainer role is effectively filled by the GHC developers who maintain head.hackage. However, if the scope of the role expands, this is likely to be unsustainable. Potentially this is somewhere where the HF could provide assistance.
But this doesn’t seem “fairly concrete” to me. Conversely I see the proposal is as really 3 proposals in 1:
1. Concrete Technical plan
I’ll paraphrase as
Fork head.hackage a few times and/or add more branches
This is trivial and doesn’t need HFTT authorization.
2. Concrete Social plan
I’ll paraphrase as
Promote the the use of head.hackage to assuage community concerns about GHC upgrades being too difficult / there being too much unforeseen breakage.
This is very interesting to me! But it is a question of trying to steer the ecosystem write large (GHC, libraries) towards different migration norms and practices, not of resourcing in and of itself. It is still unclear to me whether you (@sclv) think the proposal is “valid” as a whole because:
- the HFTT is supposed to deliberate on social/community policy
or
- the authors of this policy (@bgamari, simonpj) have the authority to make this decision on their own, so any residual resourcing questions are all that remains to deliberate.
(Relatedly, I recall it was you who first mentioned resurrecting GitHub - haskell/ecosystem-proposals: Proposals for the Haskell Ecosystem for these sorts of things, versus @simonpj above saying that repo is obviated by HFTT proposals.)
3. Nebulous resourcing promise
I’ll paraphrase as
for now us GHC devs are probably good to go, but FYI if the social plan succeeds in making GHC-specific package wildly very popular, we’re going to need some help maintaining them
I don’t think that resourcing ask is concrete at all. I think it is instead asking the HF to promise to have the GHC dev’s backs and relieve them of the burdens of success, so they aren’t punished for their good deed.
Now, that is still a resourcing question of sorts, and a good thing for the HF to deliberate on. And as member of the community, I think
Yes! This is great, the HF should absolutely have the GHC dev’s backs here!
But as a mere engineer on the HFTT not familiar with the ins and outs of hiring, I feel a little awkward approving making a vague promise that I am not responsible for keeping. The as-yet unknown future ED will be responsible for making good on this promise, with an unclear time line, and they are not here to discuss it with the rest of the HFTT.
My bias is still:
the HFTT as a board of engineers is ill-suited to make resourcing decisions that almost invariably are flexible matters anyways (like this) and one the HF executives should be empowered to make asynchronously from agreeing upon the object to be resourced.
but I am not trying to promote that so much as just ask for clarity.
Right now each proposal we get seems to need its own “rubric”, and I just want some to know what I am supposed to do as an HFTT member and as someone that would like to see more HFTT proposals written.
Nor am I trying to be a process weenie for rigidity’s sake!
If we do want each proposal to be judged somewhat freely, I am actually OK with that! But it’s a bit at odds with the current documents for the HFTT, which seem (to me at least) to imply a rigid constitution of what the HFTT is for and what we do. I don’t think that rigidity is reflecting what we are actually doing terribly well, or even more so any consensus among the various folks in this thread over what we should be doing. It is that gap that concerns me.
