The role of the shepherd
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
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
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
P.S.: I also feels like "the role of the shepherd" feels out of place in README.rst. It lists information that is important for the person taking the role of the shepherd. It is not important for a person who submits a proposal. We have https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst where most of the information of the former kind resides. I'll open a PR to move it there. Am Mo., 4. Mai 2026 um 09:04 Uhr schrieb Sebastian Graf <sgraf1337@gmail.com
:
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
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. It is quite time-consuming for me to go through a multiple page long README just to find the information about my role as a shepherd that I care about. Am Mo., 4. Mai 2026 um 09:13 Uhr schrieb Sebastian Graf <sgraf1337@gmail.com
:
P.S.: I also feels like "the role of the shepherd" feels out of place in README.rst. It lists information that is important for the person taking the role of the shepherd. It is not important for a person who submits a proposal. We have https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst where most of the information of the former kind resides. I'll open a PR to move it there.
Am Mo., 4. Mai 2026 um 09:04 Uhr schrieb Sebastian Graf < sgraf1337@gmail.com>:
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
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
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
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
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
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
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
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
There is definitely a need to have one place where we can quickly see the current status, but I don't think a manual spreadsheet is the way to do this. Maybe for voting, because we don't have another good source of truth for that data, but for the other aspects of proposals the source of truth is elsewhere. The spreadsheet would have the following problems: 1. It has to be manually updated 2. It's not the source of truth for the data 3. Due to human error and inaction, it inevitably diverges from reality 4. So we waste time either acting on incorrect information or tracking down and eliminating differences Folk may remember that I made a little script to solve this problem for myself when I became secretary: https://github.com/simonmar/ghc-proposals-stats/ (I did mention this on the list at the time, but there wasn't any discussion). I ran the script today and it worked fine. I'm also happy to use Sebastian's script. (apologies if this reply is a bit out of date I haven't read the whole thread yet...) Cheers Simon On Mon, 4 May 2026 at 09:11, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
Great. FWIW, I'm not attached to the AI-written dashboard script at all. I'm also not a consumer of the data it visualizes. I just don't want to maintain the spreadsheet manually. Whatever works for Simon and Simon that doesn't require me to maintain the spreadsheet manually is great. Either Simon's script or the dashboard generation script fit that bill from my side. However, one thing the dashboard script made pretty clear to me is that we should adopt a more rigid Syntax in our mails to submit votes, like "vote #1234: accept" to aid automated parsing. Simon Marlow <marlowsd@gmail.com> schrieb am Do., 25. Juni 2026, 11:43:
There is definitely a need to have one place where we can quickly see the current status, but I don't think a manual spreadsheet is the way to do this. Maybe for voting, because we don't have another good source of truth for that data, but for the other aspects of proposals the source of truth is elsewhere. The spreadsheet would have the following problems:
1. It has to be manually updated 2. It's not the source of truth for the data 3. Due to human error and inaction, it inevitably diverges from reality 4. So we waste time either acting on incorrect information or tracking down and eliminating differences
Folk may remember that I made a little script to solve this problem for myself when I became secretary: https://github.com/simonmar/ghc-proposals-stats/ (I did mention this on the list at the time, but there wasn't any discussion). I ran the script today and it worked fine. I'm also happy to use Sebastian's script. (apologies if this reply is a bit out of date I haven't read the whole thread yet...)
Cheers Simon
On Mon, 4 May 2026 at 09:11, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
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 <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
_______________________________________________ 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
participants (4)
-
Adam Gundry -
Sebastian Graf -
Simon Marlow -
Simon Peyton Jones