Hi, I understand the desire to have a constantly updated “dashboard”. But I don’t think a spreadsheed will work. At least not if your expectation is that we, collaboratively, keep it up to date. If we already fall behind our actual review commitments, surely we’ll fall behind additional red tape commitments. And then we’ll have a file that we can’t rely on because we wouldn’t be confident that it actually reflects reality. And it’s not that I hates manual solutions. In fact, my semi-regular “status” emails are fully manual! In a way you did more or less what I do every time I create these: I did through my email and curate the current status quo. This is tenable because it’s clear who does it (the secretary, instead of everybody), and because it’s an email there is no confusion as whether it is is up to date – is is up to date the moment I write it, and makes no promises about later states. So that’s a difference in frequency, form and ownership (at intervals vs. continous; push email vs. pull URL; collectively vs. secretarial). Your sheet also contains additional fields (Author, various dates) – maybe I should include them in the status email. I don’t want to stop us from trying out different procedures, though, so if there is a general sentiment that a wiki-like process (everyone collaboratively edits a common file) is worth exploring, we can do that of course. But I miss the “yes please and I definitely will keep it up to date” cries from our crowd :-) Ultimately, the best would be a tool that uses the Github API to create a dashboard (Note that most information on your sheet is already present in github, especially as all status changes are represented as label changes), maybe even with automatic nudging on github or email… The next best thing is someone (but someone, not somemany) doing that manually; maintaining a dashboard like yours, plus nudging. But who wants to do manually what can be done (mostly) automated… Cheers, Joachim Am Montag, dem 28.06.2021 um 09:56 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:
I’m a bit concerned that we are falling down on our commitment to decide about GHC proposals in a timely manner. Part of the problem is that at any moment I don’t have a clear snapshot in my head of what decisions are pending, and who is driving them. I know that Joachim hates manual solutions, but I have spent a few minutes digging through my email to build * this spreadsheet giving the current status You all have edit permissions. It covers only the handful of proposals that are in our court. Can I suggest that we all use it to keep ourselves on the ball? E.g. as a shepherd you can use it to record who you are waiting for, as I have done for #302. You’ll notice that we are behind on every one of them. Remember, if there edits we want the author to make, we push it back, out of our court. It can re-enter when the author re-submits. If our commitments are over-ambitious, let’s review them. Tom: you are our official nudger. Would you like to make you weekly nudge into an email to the full committee, with a pointer to the spreadsheet and your current understanding of who is responsible for driving? I hope this is helpful. If not, let’s think of something else! Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/