Hi Simon,
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.
Agreed. Running it nightly seems far easier.
How did you gather the voting information?
The script recognises a couple of keywords in mailing list archives by regex. The regexes are declared here: https://github.com/sgraf812/ghc-proposals/blob/66b4dac92318e8bf4cbe792cba6f8... The way these regexes were chosen is by "training" on the existing Google Sheet as labelled training data. But Malte has a good point when he says that in the future we should freeze these regexes so that we do not vote by accidental use of some phrase on the mailing list. Am Di., 12. Mai 2026 um 14:03 Uhr schrieb Sebastian Graf < sgraf1337@gmail.com>:
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