Re: Haddock needs help

i might have some bandwidth to help out in small spurts if needed in the second half of this summer, lets catsup sometime soon on IRC or whatever and maybe i can help kick the can a smidge On Mon, Jun 6, 2022 at 7:49 AM Hécate wrote:

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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs