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 <hec...@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@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
