Haddock needs help

[Hécate]

Hi Mikolaj, you highlight something very interesting. Indeed there is no 
shame in disclosing technical debt.

That being said the problem isn't entirely technical. The main 
challenges here are the consolidation of expertise, onboarding of 
newcomers, a sensible product roadmap, and a realistic path forward when 
it comes to the big features I'd like to ship in the future.

At the moment I would be more comfortable with starting by onboarding a 
restricted group of people so that my attention can be properly focused 
on ramping up their skills, which is why I posted on the ghc-devs 
mailing-list, as GHC is our main (if not only) consumer, and GHC 
developers have already made contributions to Haddock.

Cheers,
Hécate

Le 26/05/2022 à 17:12, Mikolaj Konarski a écrit :
> Talking as a Haskell user, but also a cabal maintainer:
> the Haddock work Hécate describes is crucial for the health
> and efficiency of the whole ecosystem and the sooner
> we can start it, the less drag it's going to have on the rest.
>
> Given that GHC expertise is not necessary for many
> of the tasks involved, could we forward this message
> to other media? I don't think there is shame in disclosing
> technical debt (as opposed to hiding it) and I think the way
> it's worded, it may be viewed as a challenge, not a turn-off.
> Still, are there any suggestions on how to tweak the text
> before an announcement on discourse, reddit, etc.?
> Would, e.g., HF, like to chime in early in each of the ensuing
> discussions? If so, how would we know where it gets posted to?
>
> Cheers,
> Mikolaj
>
> On Thu, May 26, 2022 at 4:39 PM Hécate <hecate at glitchbra.in> wrote:
>> Hi everyone,
>>
>> Haddock needs help.
>>
>> Since I joined the Haddock team to help triage the tickets and interact
>> with the community, we lost all of our experts, and I didn't have time
>> to level up quickly enough to handle the mass of incoming tickets, let
>> alone actually reduce the number of tickets to number below two hundred.
>>
>> As things stand now, the Haddock code base is in a disastrous state,
>> largely not understood and its CI is in shambles.
>> There are things that we can improve on the short and longer term – see
>> https://github.com/haskell/haddock/issues/1465 – but the greater lack of
>> expertise means that any project involving some core business logic is
>> bound to be utterly and unnecessarily painful. The Hi Haddock GSOC
>> proposal, whilst fully implemented in GHC, cannot be brought in Haddock
>> at this moment in a reasonable timeline without any help.
>>
>> At present time, I need:
>>
>> * People who can refactor the code base, following modern software
>> engineering practices, like domain-driven design and test-driven
>> development.
>> * UI developers, proficient in CSS and web accessibility.
>>
>> If you feel like you fit some of these criteria, please do contact me at
>> this address. If your company can spare some engineering hours for you
>> to give a hand, you're most welcome to do so.
>>
>> Just so we are clear, I am immensely grateful to the people who have
>> submitted fixes and patches these past months, but this situation is
>> untenable.
>>
>> Hécate ✨
>> 🐦: @TechnoEmpress
>> IRC: Hecate
>> WWW: https://glitchbra.in
>> RUN: BSD
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD