Hi Adam, 

> I've already fixed a few PR label metadata errors

that were visible from skimming the summary.
> Could we arrange for this to run overnight via GitHub Actions and

publish to GitHub Pages?

Great that you found it helpful, Adam! Yes, running it over night with GH actions is absolutely what I think we should do. (It's also not particularly costly; should run in less than a minute.)

Am Do., 7. Mai 2026 um 11:26 Uhr schrieb Simon Peyton Jones <simon.peytonjones@gmail.com>:

Really helpful thanks.

Absolutely crucial to run it nightly (or on demand when I click a link) so that it's easy for anyone to get an up to date result.

How did you gather the voting information? 

Simon

On Thu, 7 May 2026 at 08:17, Adam Gundry <adam@well-typed.com> wrote:

Thanks Sebastian, I haven't looked at the code but the overview output
looks really helpful! I've already fixed a few PR label metadata errors
that were visible from skimming the summary.

Could we arrange for this to run overnight via GitHub Actions and
publish to GitHub Pages?

I wonder if we should rethink the treatment of dormant proposals, so
there is a clearer distinction between active and inactive proposals
(not just "pending shepherd/committee" and "everything else"). But
that's a separate discussion I guess.

Cheers,

Adam



On 07/05/2026 07:51, Sebastian Graf wrote:
> The python script is ready for review. It's a substantial piece of code
> (1k lines), but it's not difficult code. It also doesn't read AI sloppy,
> as far as I can tell, and is IMO good enough to get an overview over our
> proposals.
> I attached the generated HTML at this point.
>
> Am Mo., 4. Mai 2026 um 11:29 Uhr schrieb Sebastian Graf
> <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>:
>
>     I vibe-coded a python script that automates all columns of the
>     spreadsheet except for the votes (lack of structure in mail format).
>     Here's the PR: https://github.com/ghc-proposals/ghc-proposals/
>     pull/756 <https://github.com/ghc-proposals/ghc-proposals/pull/756>
>
>     Example HTML page that we could host statically and update nightly
>     via CRON job: https://github.com/user-attachments/files/27344127/
>     dashboard.html <https://github.com/user-attachments/files/27344127/
>     dashboard.html>
>
>     Am Mo., 4. Mai 2026 um 10:11 Uhr schrieb Simon Peyton Jones
>     <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>:
>
>         Thanks -- it's good to discuss how we can work together better.
>
>             Frankly, I don't see how this sort of manual bookkeeping is
>             doing us any favours. What's the purpose? It's a lot of work
>             (tracking back "Date entered inbox", etc." that should all
>             be automatable by a vibe-coded script, since all the traffic
>             on this mailing list is public.
>
>
>         In my mind it's just a secretarial aid.    How, otherwise, can I
>         find out what proposals are open, which ones I am
>         actively supposed to be commenting on, and which committee
>         members have expressed an opinion, what that opinion is, and
>         what the deadline.
>
>         If a script will do the job, well and good.  But then someone
>         has to write it and maintain it.
>
>         I'm interested that filling in the spreadsheet takes a lot of
>         work.  In my experience, all the work was trying to read
>         proposals, comment on them, and (when I'm the shepherd) who had
>         voted and what they said.  Filling in this information was 0.5%
>         of the burden and saved me time repeatedly working out "has X
>         voted".
>
>         But it's just a mechanism.  And indeed if the shepherds don't
>         update it, it'll get out of date.  Let's by all means have a
>         better mechanism, provided that it can give a continuously
>         available snapshot of the state of play.
>
>             Actually, the committee bylaws isn't the right place to put
>             this information either, so I'll leave it in the README for
>             the time being. But as a member of the committee, I find a
>             separate list such as acceptance.rst very very useful.
>
>
>         Yes the main README page is very long.  Perhaps we should split
>         it up
>
>         Simon
>
>
>         On Mon, 4 May 2026 at 08:05, Sebastian Graf <sgraf1337@gmail.com
>         <mailto:sgraf1337@gmail.com>> wrote:
>
>             Hi friends,
>
>             I want to get back to this:
>
>              > Maintain a list of votes on this spreadsheet <https://
>             docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-
>             b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>.
>
>             Frankly, I don't see how this sort of manual bookkeeping is
>             doing us any favours. What's the purpose? It's a lot of work
>             (tracking back "Date entered inbox", etc." that should all
>             be automatable by a vibe-coded script, since all the traffic
>             on this mailing list is public.
>             Also it has fallen out of date already. Who can tell whether
>             this list is complete?
>
>             I'll add my entry for #700 (post-hoc), but as I said it is a
>             lot of work.
>
>             Cheers,
>             Sebastian
>
>             Am Mi., 10. Sept. 2025 um 09:55 Uhr schrieb Adam Gundry
>             <adam@well-typed.com <mailto:adam@well-typed.com>>:
>
>                 Thanks for this, Simon! It makes sense to document this
>                 more clearly,
>                 and at the suggestion from you and Erik off-list, I've
>                 opened a PR
>                 adding a variant of this to the README:
>
>                 https://github.com/ghc-proposals/ghc-proposals/pull/726
>                 <https://github.com/ghc-proposals/ghc-proposals/pull/726>
>
>                 If anyone would like to suggest changes, please feel
>                 free. (I made one
>                 change: our existing guideline is two weeks rather than
>                 one week for
>                 shepherds to make a recommendation to the committee.)
>
>                 Cheers,
>
>                 Adam
>
>
>                 On 09/09/2025 23:58, Simon Peyton Jones wrote:
>                  > Friends
>                  >
>                  > I have realised, rather belatedly, that we don't
>                 actually have any
>                  > written guidance for shepherds of GHC proposals, so
>                 we all have to make
>                  > it up as we go along.   Perhaps it'd be helpful to
>                 have some.  Here's a
>                  > start.
>                  >
>                  > The shepherd does these things:
>                  >
>                  >   * Makes a recommendation to the committee for
>                 whether to accept,
>                  >     reject, or send back for revision, within a week
>                 of being appointed.
>                  >   * Actively guide the committee's discussion.
>                  >   * Maintain a list of votes on this spreadsheet
>                 <https://
>                  > docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-
>                 <http://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP->
>                  >     b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>.
>                  >   * Actively facilitate the committee discussion,
>                 guiding us towards a
>                  >     decision, within the published time frame of 4-5
>                 weeks.
>                  >   * Summarise the committee's thinking for the
>                 author's benefit, and
>                  >     work with the author on next steps -- this may
>                 often take the form
>                  >     of revisions to the proposal.
>                  >   *
>                  >   * Remind members (by name, not just general
>                 exhortation) who are
>                  >     silent that they are highly encouraged to contribute.
>                  >   * If the discussion does not converge within 4-5
>                 weeks, take action to
>                  >     consult the chair, vice-chair, or secretary to
>                 decide what to do.
>                  >
>                  > It's much more than "make a recommendation and wait".
>                  >
>                  > Being a member of the GHC Steering Committee is a
>                 real service to the
>                  > community.   But of course we all have day jobs, and
>                 so not everything
>                  > happens as we hope.
>                  >
>                  > Any thoughts?
>                  >
>                  > Simon
>                  >
>
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org