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
:
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
Example HTML page that we could host statically and update nightly via CRON job: 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>:
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> 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>:
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
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- 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org