reflections on our tech process
85 views
Skip to first unread message
Richard Eisenberg
Jul 13, 2021, 6:21:13 PM7/13/21
to Haskell Foundation Board
Hi all,
First off, many thanks, Tom, for engaging Julian in response to his email to this group from a little while ago. For the record: Tom has written a summary of his conversation at https://haskell-foundation.slack.com/archives/C01MDPH0L95/p1626088205108700. Due to implications about specific individuals, this summary has not been posted to this public list.
Despite its existence on Slack, I'm going to respond here, because I have a few reactions that I think are best discussed in this public, archived channel.
I'm glad Julian has been posing (sometimes implicit) questions, both in his original email (https://groups.google.com/a/haskell.foundation/g/board/c/-aUL5IQmgtk) and in the followup. (This is *not* an endorsement of Julian's view on the technical details about the installer, about which I am ill-informed.) Much of what I say below is inspired by what Julian has expressed, but these are my own opinions, not necessarily his.
The key question:
* How do we want to effect change?
At opposite ends of a spectrum (but admittedly with points in between), we can have a top-down approach or a bottom-up one. Top-down means that we, the principals of the HF, decide what's best for Haskell and then do it, perhaps by recruiting volunteers do implement our ideas. Bottom-up means we wait for proposals from the community and then decide which proposals are best, eventually deciding which ones to support (with funding or other support, such as technical coordination).
We have, from our inception, been describing ourselves as bottom-up. It's worth re-reading the Principles and Ethos on https://haskell.foundation/vision/. However, in many ways, we have been behaving top-down. Examples of top-down behavior:
- Detailed discussions that happen in meetings. Yes, there are minutes -- and that helps keep some people up to date -- but that doesn't lead to broad participation and/or widespread knowledge of our initiatives.
- Projects listed on our website (https://haskell.foundation/projects/) that lack (public) proposals.
- Limited engagement on Discourse. Our posts tend to be Announcements, or Attempts To Calm The Masses, or similar, not questions and/or collective brainstorming. Examples include the https://discourse.haskell.org/t/irc-matrix-and-fragmentation/2526, https://discourse.haskell.org/t/irc-matrix-and-fragmentation/2526, https://discourse.haskell.org/t/rfc-a-new-cabal-user-guide/2639/10, and the resurrection of https://discourse.haskell.org/t/clearer-description-of-the-board-responsibilities/1598/13. An exception is https://discourse.haskell.org/t/rfc-brokering-toolchain-installations-with-hs/2746/17, which has various back-and-forth conversations both within and beyond the HF.
- All substantive PRs to https://github.com/haskellfoundation/tech-proposals have been by people on this list. (This last point is a bit less in our control, but it's a symptom of the top-down approach.)
(An example of bottom-up is the circulation of and engagement about https://haskell-foundation.slack.com/archives/C01PKJ9QKJ8/p1626127699271200, a process Emily has written to address some of the issues in this email -- though having so much discussion on hackmd instead of GitHub reduces its archival value.)
I see the value in top-down behavior and decision-making: it can be faster moving, coordinated, and (if well executed) less contentious. Sometimes, we should engage this mode. But, in keeping with having Transparency as one of our core principles, we should explain why we do this when we do. Given our nascent status, some top-down decision making may be appropriate: we want some achievements to show for ourselves. Yet, we have continued to couch our top-down moves as bottom-up, sowing confusion such as Julian's.
So, where do I propose we go from here?
- Be explicit about top-down vs bottom-up. If we are pushing an initiative using whatever force of will we have internally, let's say so in public with a rationale. I will assume "bottom-up" as the default (but happy to get push-back against this).
- Reinvigorate the tech-proposals repo, with a process that we pledge to follow and an explicit (that is, posted on Discourse) invitation to the community to write proposals. This also requires delineating the scope of the process. Emily's https://hackmd.io/W8THnWAtRfaG-p61lvdtiA?view is a great start to this.
- Commit ourselves to using the process, even for our own ideas. For example, the GHC proposals repo has many proposals from e.g. Simon and me. One reason for this is that our fellow contributors would stop us from committing user-facing changes without a proposal, just as they should. Let's similarly police each other regarding the HF.
- Work hard to avoid over-planning in tech track meetings. I think the meetings are valuable -- group synchronous brainstorming can be very powerful. But once a rough direction has been set, we should go to a more public venue.
- Make it clear how to access the tech track meetings. The charter (https://docs.google.com/document/d/1VHfWX7GrFcuSl299S0zZfs-17iJAZ-bTU4SRe8Eboc8/edit?usp=sharing) says to email Emily, which is good, but I imagine few people would know how to navigate to this charter. Putting the information on the website would be much better.
- Clarify the projects page on the website. One project there is approved by the HF, about text at UTF8. The installer has been proposed. All of the others are just ideas that have come up for conversation.
- Engage more with Discourse. For Andrew and Emily, this would be (if we agree with these suggestions), quite literally, part of their day job. There is quite a bit of insight in the Discourse threads, but it looks to me that, often, the non-HFers are just learning from each other, and that the message isn't getting over the wall.
I'm hoping that we, as a board, can get behind the proposal points immediately above and make these operating policy of the HF.
Thanks for reading!
Richard
First off, many thanks, Tom, for engaging Julian in response to his email to this group from a little while ago. For the record: Tom has written a summary of his conversation at https://haskell-foundation.slack.com/archives/C01MDPH0L95/p1626088205108700. Due to implications about specific individuals, this summary has not been posted to this public list.
Despite its existence on Slack, I'm going to respond here, because I have a few reactions that I think are best discussed in this public, archived channel.
I'm glad Julian has been posing (sometimes implicit) questions, both in his original email (https://groups.google.com/a/haskell.foundation/g/board/c/-aUL5IQmgtk) and in the followup. (This is *not* an endorsement of Julian's view on the technical details about the installer, about which I am ill-informed.) Much of what I say below is inspired by what Julian has expressed, but these are my own opinions, not necessarily his.
The key question:
* How do we want to effect change?
At opposite ends of a spectrum (but admittedly with points in between), we can have a top-down approach or a bottom-up one. Top-down means that we, the principals of the HF, decide what's best for Haskell and then do it, perhaps by recruiting volunteers do implement our ideas. Bottom-up means we wait for proposals from the community and then decide which proposals are best, eventually deciding which ones to support (with funding or other support, such as technical coordination).
We have, from our inception, been describing ourselves as bottom-up. It's worth re-reading the Principles and Ethos on https://haskell.foundation/vision/. However, in many ways, we have been behaving top-down. Examples of top-down behavior:
- Detailed discussions that happen in meetings. Yes, there are minutes -- and that helps keep some people up to date -- but that doesn't lead to broad participation and/or widespread knowledge of our initiatives.
- Projects listed on our website (https://haskell.foundation/projects/) that lack (public) proposals.
- Limited engagement on Discourse. Our posts tend to be Announcements, or Attempts To Calm The Masses, or similar, not questions and/or collective brainstorming. Examples include the https://discourse.haskell.org/t/irc-matrix-and-fragmentation/2526, https://discourse.haskell.org/t/irc-matrix-and-fragmentation/2526, https://discourse.haskell.org/t/rfc-a-new-cabal-user-guide/2639/10, and the resurrection of https://discourse.haskell.org/t/clearer-description-of-the-board-responsibilities/1598/13. An exception is https://discourse.haskell.org/t/rfc-brokering-toolchain-installations-with-hs/2746/17, which has various back-and-forth conversations both within and beyond the HF.
- All substantive PRs to https://github.com/haskellfoundation/tech-proposals have been by people on this list. (This last point is a bit less in our control, but it's a symptom of the top-down approach.)
(An example of bottom-up is the circulation of and engagement about https://haskell-foundation.slack.com/archives/C01PKJ9QKJ8/p1626127699271200, a process Emily has written to address some of the issues in this email -- though having so much discussion on hackmd instead of GitHub reduces its archival value.)
I see the value in top-down behavior and decision-making: it can be faster moving, coordinated, and (if well executed) less contentious. Sometimes, we should engage this mode. But, in keeping with having Transparency as one of our core principles, we should explain why we do this when we do. Given our nascent status, some top-down decision making may be appropriate: we want some achievements to show for ourselves. Yet, we have continued to couch our top-down moves as bottom-up, sowing confusion such as Julian's.
So, where do I propose we go from here?
- Be explicit about top-down vs bottom-up. If we are pushing an initiative using whatever force of will we have internally, let's say so in public with a rationale. I will assume "bottom-up" as the default (but happy to get push-back against this).
- Reinvigorate the tech-proposals repo, with a process that we pledge to follow and an explicit (that is, posted on Discourse) invitation to the community to write proposals. This also requires delineating the scope of the process. Emily's https://hackmd.io/W8THnWAtRfaG-p61lvdtiA?view is a great start to this.
- Commit ourselves to using the process, even for our own ideas. For example, the GHC proposals repo has many proposals from e.g. Simon and me. One reason for this is that our fellow contributors would stop us from committing user-facing changes without a proposal, just as they should. Let's similarly police each other regarding the HF.
- Work hard to avoid over-planning in tech track meetings. I think the meetings are valuable -- group synchronous brainstorming can be very powerful. But once a rough direction has been set, we should go to a more public venue.
- Make it clear how to access the tech track meetings. The charter (https://docs.google.com/document/d/1VHfWX7GrFcuSl299S0zZfs-17iJAZ-bTU4SRe8Eboc8/edit?usp=sharing) says to email Emily, which is good, but I imagine few people would know how to navigate to this charter. Putting the information on the website would be much better.
- Clarify the projects page on the website. One project there is approved by the HF, about text at UTF8. The installer has been proposed. All of the others are just ideas that have come up for conversation.
- Engage more with Discourse. For Andrew and Emily, this would be (if we agree with these suggestions), quite literally, part of their day job. There is quite a bit of insight in the Discourse threads, but it looks to me that, often, the non-HFers are just learning from each other, and that the message isn't getting over the wall.
I'm hoping that we, as a board, can get behind the proposal points immediately above and make these operating policy of the HF.
Thanks for reading!
Richard
Simon Peyton Jones
Jul 14, 2021, 4:18:42 AM7/14/21
to Richard Eisenberg, Haskell Foundation Board
I support what Richard says here.
Another set of language we could use (instead of top-down vs bottom-up) is
A) For most projects we *support* the work of others. [aka bottom up]
We help to coordinate, support the people leading the project, encourage
volunteers to join in, etc.
B) For some projects we *lead* the work [aka top down]
We identify that there is a gap where something that should be done
isn't getting done, and we fill that gap
So (A) is the default; but an explicit role of the HF is to fill important (but perhaps un-glamorous) gaps, hence (B).
This is essentially the same as what Richard is saying, but using slightly different language. I'm not sure which is best, but tone matters. I mildly prefer support vs lead, because "top-down" sounds rather non-consultative, whereas "lead" can and should be very consultative.
Simon
| -----Original Message-----
| From: bo...@haskell.foundation <bo...@haskell.foundation> On Behalf Of
| Richard Eisenberg
| Sent: 13 July 2021 23:21
| To: Haskell Foundation Board <bo...@haskell.foundation>
| Subject: [HF Board] reflections on our tech process
|
| Hi all,
|
| First off, many thanks, Tom, for engaging Julian in response to his
| email to this group from a little while ago. For the record: Tom has
| written a summary of his conversation at
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhask
| ell-
| foundation.slack.com%2Farchives%2FC01MDPH0L95%2Fp1626088205108700&
| data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90a54b3b199608d9464c8
| 692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637618116769000598%7C
| Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
| aWwiLCJXVCI6Mn0%3D%7C1000&sdata=OjWnSnBG8TL4hhCXWo6RPrIV8F6lAIF2%2
| FdP3m2gpklA%3D&reserved=0. Due to implications about specific
| ups.google.com%2Fa%2Fhaskell.foundation%2Fg%2Fboard%2Fc%2F-
| aUL5IQmgtk&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90a54b
| 3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637618
| 116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
| zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DO%2BdZsHiYSh9KMY0b
| fJp6f%2FFCJ6duSQW4N6%2FX0K2aKU%3D&reserved=0) and in the followup.
| ell.foundation%2Fvision%2F&data=04%7C01%7Csimonpj%40microsoft.com%
| 7C6709ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%
| 7C1%7C0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
| DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6nE
| vTInGZ%2FENH24%2F3RHyYEHTpco4K6U0tv1FrIYAF0Q%3D&reserved=0.
| kell.foundation%2Fprojects%2F&data=04%7C01%7Csimonpj%40microsoft.c
| om%7C6709ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db
| 47%7C1%7C0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
| AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
| orE3OM%2B8ZhIfR4%2B4yP2fLMEkV%2BX%2FNoHgQE9uSAIC2q4%3D&reserved=0)
| ourse.haskell.org%2Ft%2Firc-matrix-and-
| fragmentation%2F2526&data=04%7C01%7Csimonpj%40microsoft.com%7C6709
| ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
| 0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
| QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ymmCuKBQg
| wjX%2BnmkmprwJ2xmu3iwIjUW3zsmXdK73mg%3D&reserved=0,
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
| ourse.haskell.org%2Ft%2Firc-matrix-and-
| fragmentation%2F2526&data=04%7C01%7Csimonpj%40microsoft.com%7C6709
| ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
| 0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
| QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ymmCuKBQg
| wjX%2BnmkmprwJ2xmu3iwIjUW3zsmXdK73mg%3D&reserved=0,
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
| ourse.haskell.org%2Ft%2Frfc-a-new-cabal-user-
| guide%2F2639%2F10&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5
| f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
| C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
| oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F%2Fa6jGfm0R
| 5Ky2zUxzZ4EtBOCdXvqZnipMwHk6vJs8Q%3D&reserved=0, and the
| resurrection of
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
| ourse.haskell.org%2Ft%2Fclearer-description-of-the-board-
| responsibilities%2F1598%2F13&data=04%7C01%7Csimonpj%40microsoft.co
| m%7C6709ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db4
| 7%7C1%7C0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
| wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U
| 81ITKDlWSn3rgR%2BdLFM%2FJYjp6%2BEwZRyNtO0iQyP%2FX0%3D&reserved=0.
| An exception is
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
| ourse.haskell.org%2Ft%2Frfc-brokering-toolchain-installations-with-
| hs%2F2746%2F17&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90
| a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
| 7618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
| 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EZuk8Ax7LlKO3ll
| pBYxAwuz%2FoUljoBNftRFyzMjIYbI%3D&reserved=0, which has various
| ub.com%2Fhaskellfoundation%2Ftech-
| proposals&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90a54b3
| b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376181
| 16769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
| IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=opqPDwYKulMqhcspkAvN
| 3D8kaNrPvpVM%2BeKW%2FYg2rJw%3D&reserved=0 have been by people on
| ell-
| foundation.slack.com%2Farchives%2FC01PKJ9QKJ8%2Fp1626127699271200&
| data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90a54b3b199608d9464c8
| 692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637618116769010555%7C
| Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
| aWwiLCJXVCI6Mn0%3D%7C1000&sdata=cA%2FIk13%2FDuQy24zwpT6uGiwQafm4T2
| 53WumcNNXym%2F4%3D&reserved=0, a process Emily has written to
| md.io%2FW8THnWAtRfaG-
| p61lvdtiA%3Fview&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f
| 90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
| 637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
| iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yNoov8gjQmvI7
| Xqced71LdBzm30wVHf5chRQSEcNcJo%3D&reserved=0 is a great start to
| s.google.com%2Fdocument%2Fd%2F1VHfWX7GrFcuSl299S0zZfs-17iJAZ-
| bTU4SRe8Eboc8%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40micr
| osoft.com%7C6709ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7
| cd011db47%7C1%7C0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
| iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
| ;sdata=jqXEgw5nZKGmpyF9HesfIfFkGTXdgGY%2B%2FF1txyOcoLE%3D&reserved
| =0) says to email Emily, which is good, but I imagine few people would
| You received this message because you are subscribed to the Google
| Groups "Haskell Foundation Board" group.
| To unsubscribe from this group and stop receiving emails from it, send
| an email to board+un...@haskell.foundation.
| To view this discussion on the web visit
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
| ps.google.com%2Fa%2Fhaskell.foundation%2Fd%2Fmsgid%2Fboard%2F010f017aa
| 1f5b4e3-2a6908f6-ff9e-41c3-b7a4-1cf6dbcb6c50-000000%2540us-east-
| 2.amazonses.com&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f9
| 0a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
| 37618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
| V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=19TI35sxtTKvd5
| NfTIbB7rG8QF4CxH3BnUizyQAB9bw%3D&reserved=0.
Another set of language we could use (instead of top-down vs bottom-up) is
A) For most projects we *support* the work of others. [aka bottom up]
We help to coordinate, support the people leading the project, encourage
volunteers to join in, etc.
B) For some projects we *lead* the work [aka top down]
We identify that there is a gap where something that should be done
isn't getting done, and we fill that gap
So (A) is the default; but an explicit role of the HF is to fill important (but perhaps un-glamorous) gaps, hence (B).
This is essentially the same as what Richard is saying, but using slightly different language. I'm not sure which is best, but tone matters. I mildly prefer support vs lead, because "top-down" sounds rather non-consultative, whereas "lead" can and should be very consultative.
Simon
| -----Original Message-----
| From: bo...@haskell.foundation <bo...@haskell.foundation> On Behalf Of
| Richard Eisenberg
| Sent: 13 July 2021 23:21
| To: Haskell Foundation Board <bo...@haskell.foundation>
| Subject: [HF Board] reflections on our tech process
|
| Hi all,
|
| First off, many thanks, Tom, for engaging Julian in response to his
| email to this group from a little while ago. For the record: Tom has
| written a summary of his conversation at
| ell-
| foundation.slack.com%2Farchives%2FC01MDPH0L95%2Fp1626088205108700&
| data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90a54b3b199608d9464c8
| 692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637618116769000598%7C
| Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
| aWwiLCJXVCI6Mn0%3D%7C1000&sdata=OjWnSnBG8TL4hhCXWo6RPrIV8F6lAIF2%2
| FdP3m2gpklA%3D&reserved=0. Due to implications about specific
| individuals, this summary has not been posted to this public list.
|
| Despite its existence on Slack, I'm going to respond here, because I
| have a few reactions that I think are best discussed in this public,
| archived channel.
|
| I'm glad Julian has been posing (sometimes implicit) questions, both
| in his original email
| (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgro
|
| Despite its existence on Slack, I'm going to respond here, because I
| have a few reactions that I think are best discussed in this public,
| archived channel.
|
| I'm glad Julian has been posing (sometimes implicit) questions, both
| in his original email
| ups.google.com%2Fa%2Fhaskell.foundation%2Fg%2Fboard%2Fc%2F-
| aUL5IQmgtk&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90a54b
| 3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637618
| 116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
| zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DO%2BdZsHiYSh9KMY0b
| fJp6f%2FFCJ6duSQW4N6%2FX0K2aKU%3D&reserved=0) and in the followup.
| (This is *not* an endorsement of Julian's view on the technical
| details about the installer, about which I am ill-informed.) Much of
| what I say below is inspired by what Julian has expressed, but these
| are my own opinions, not necessarily his.
|
| The key question:
|
| * How do we want to effect change?
|
| At opposite ends of a spectrum (but admittedly with points in
| between), we can have a top-down approach or a bottom-up one. Top-down
| means that we, the principals of the HF, decide what's best for
| Haskell and then do it, perhaps by recruiting volunteers do implement
| our ideas. Bottom-up means we wait for proposals from the community
| and then decide which proposals are best, eventually deciding which
| ones to support (with funding or other support, such as technical
| coordination).
|
| We have, from our inception, been describing ourselves as bottom-up.
| It's worth re-reading the Principles and Ethos on
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhask
| details about the installer, about which I am ill-informed.) Much of
| what I say below is inspired by what Julian has expressed, but these
| are my own opinions, not necessarily his.
|
| The key question:
|
| * How do we want to effect change?
|
| At opposite ends of a spectrum (but admittedly with points in
| between), we can have a top-down approach or a bottom-up one. Top-down
| means that we, the principals of the HF, decide what's best for
| Haskell and then do it, perhaps by recruiting volunteers do implement
| our ideas. Bottom-up means we wait for proposals from the community
| and then decide which proposals are best, eventually deciding which
| ones to support (with funding or other support, such as technical
| coordination).
|
| We have, from our inception, been describing ourselves as bottom-up.
| It's worth re-reading the Principles and Ethos on
| ell.foundation%2Fvision%2F&data=04%7C01%7Csimonpj%40microsoft.com%
| 7C6709ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%
| 7C1%7C0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
| DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6nE
| vTInGZ%2FENH24%2F3RHyYEHTpco4K6U0tv1FrIYAF0Q%3D&reserved=0.
| However, in many ways, we have been behaving top-down. Examples of
| top-down behavior:
|
| - Detailed discussions that happen in meetings. Yes, there are minutes
| -- and that helps keep some people up to date -- but that doesn't lead
| to broad participation and/or widespread knowledge of our initiatives.
| - Projects listed on our website
| (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhas
| top-down behavior:
|
| - Detailed discussions that happen in meetings. Yes, there are minutes
| -- and that helps keep some people up to date -- but that doesn't lead
| to broad participation and/or widespread knowledge of our initiatives.
| - Projects listed on our website
| kell.foundation%2Fprojects%2F&data=04%7C01%7Csimonpj%40microsoft.c
| om%7C6709ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db
| 47%7C1%7C0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
| AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
| orE3OM%2B8ZhIfR4%2B4yP2fLMEkV%2BX%2FNoHgQE9uSAIC2q4%3D&reserved=0)
| that lack (public) proposals.
| - Limited engagement on Discourse. Our posts tend to be Announcements,
| or Attempts To Calm The Masses, or similar, not questions and/or
| collective brainstorming. Examples include the
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
| - Limited engagement on Discourse. Our posts tend to be Announcements,
| or Attempts To Calm The Masses, or similar, not questions and/or
| collective brainstorming. Examples include the
| ourse.haskell.org%2Ft%2Firc-matrix-and-
| fragmentation%2F2526&data=04%7C01%7Csimonpj%40microsoft.com%7C6709
| ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
| 0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
| QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ymmCuKBQg
| wjX%2BnmkmprwJ2xmu3iwIjUW3zsmXdK73mg%3D&reserved=0,
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
| ourse.haskell.org%2Ft%2Firc-matrix-and-
| fragmentation%2F2526&data=04%7C01%7Csimonpj%40microsoft.com%7C6709
| ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
| 0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
| QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ymmCuKBQg
| wjX%2BnmkmprwJ2xmu3iwIjUW3zsmXdK73mg%3D&reserved=0,
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
| ourse.haskell.org%2Ft%2Frfc-a-new-cabal-user-
| guide%2F2639%2F10&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5
| f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
| C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
| oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F%2Fa6jGfm0R
| 5Ky2zUxzZ4EtBOCdXvqZnipMwHk6vJs8Q%3D&reserved=0, and the
| resurrection of
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
| ourse.haskell.org%2Ft%2Fclearer-description-of-the-board-
| responsibilities%2F1598%2F13&data=04%7C01%7Csimonpj%40microsoft.co
| m%7C6709ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db4
| 7%7C1%7C0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
| wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U
| 81ITKDlWSn3rgR%2BdLFM%2FJYjp6%2BEwZRyNtO0iQyP%2FX0%3D&reserved=0.
| An exception is
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
| ourse.haskell.org%2Ft%2Frfc-brokering-toolchain-installations-with-
| hs%2F2746%2F17&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90
| a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
| 7618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
| 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EZuk8Ax7LlKO3ll
| pBYxAwuz%2FoUljoBNftRFyzMjIYbI%3D&reserved=0, which has various
| back-and-forth conversations both within and beyond the HF.
| - All substantive PRs to
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
| - All substantive PRs to
| ub.com%2Fhaskellfoundation%2Ftech-
| proposals&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90a54b3
| b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376181
| 16769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
| IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=opqPDwYKulMqhcspkAvN
| 3D8kaNrPvpVM%2BeKW%2FYg2rJw%3D&reserved=0 have been by people on
| this list. (This last point is a bit less in our control, but it's a
| symptom of the top-down approach.)
|
| (An example of bottom-up is the circulation of and engagement about
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhask
| symptom of the top-down approach.)
|
| (An example of bottom-up is the circulation of and engagement about
| ell-
| foundation.slack.com%2Farchives%2FC01PKJ9QKJ8%2Fp1626127699271200&
| data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f90a54b3b199608d9464c8
| 692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637618116769010555%7C
| Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
| aWwiLCJXVCI6Mn0%3D%7C1000&sdata=cA%2FIk13%2FDuQy24zwpT6uGiwQafm4T2
| 53WumcNNXym%2F4%3D&reserved=0, a process Emily has written to
| address some of the issues in this email -- though having so much
| discussion on hackmd instead of GitHub reduces its archival value.)
|
| I see the value in top-down behavior and decision-making: it can be
| faster moving, coordinated, and (if well executed) less contentious.
| Sometimes, we should engage this mode. But, in keeping with having
| Transparency as one of our core principles, we should explain why we
| do this when we do. Given our nascent status, some top-down decision
| making may be appropriate: we want some achievements to show for
| ourselves. Yet, we have continued to couch our top-down moves as
| bottom-up, sowing confusion such as Julian's.
|
| So, where do I propose we go from here?
|
| - Be explicit about top-down vs bottom-up. If we are pushing an
| initiative using whatever force of will we have internally, let's say
| so in public with a rationale. I will assume "bottom-up" as the
| default (but happy to get push-back against this).
| - Reinvigorate the tech-proposals repo, with a process that we pledge
| to follow and an explicit (that is, posted on Discourse) invitation to
| the community to write proposals. This also requires delineating the
| scope of the process. Emily's
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhack
| discussion on hackmd instead of GitHub reduces its archival value.)
|
| I see the value in top-down behavior and decision-making: it can be
| faster moving, coordinated, and (if well executed) less contentious.
| Sometimes, we should engage this mode. But, in keeping with having
| Transparency as one of our core principles, we should explain why we
| do this when we do. Given our nascent status, some top-down decision
| making may be appropriate: we want some achievements to show for
| ourselves. Yet, we have continued to couch our top-down moves as
| bottom-up, sowing confusion such as Julian's.
|
| So, where do I propose we go from here?
|
| - Be explicit about top-down vs bottom-up. If we are pushing an
| initiative using whatever force of will we have internally, let's say
| so in public with a rationale. I will assume "bottom-up" as the
| default (but happy to get push-back against this).
| - Reinvigorate the tech-proposals repo, with a process that we pledge
| to follow and an explicit (that is, posted on Discourse) invitation to
| the community to write proposals. This also requires delineating the
| scope of the process. Emily's
| md.io%2FW8THnWAtRfaG-
| p61lvdtiA%3Fview&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f
| 90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
| 637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
| iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yNoov8gjQmvI7
| Xqced71LdBzm30wVHf5chRQSEcNcJo%3D&reserved=0 is a great start to
| this.
| - Commit ourselves to using the process, even for our own ideas. For
| example, the GHC proposals repo has many proposals from e.g. Simon and
| me. One reason for this is that our fellow contributors would stop us
| from committing user-facing changes without a proposal, just as they
| should. Let's similarly police each other regarding the HF.
| - Work hard to avoid over-planning in tech track meetings. I think the
| meetings are valuable -- group synchronous brainstorming can be very
| powerful. But once a rough direction has been set, we should go to a
| more public venue.
| - Make it clear how to access the tech track meetings. The charter
| (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc
| - Commit ourselves to using the process, even for our own ideas. For
| example, the GHC proposals repo has many proposals from e.g. Simon and
| me. One reason for this is that our fellow contributors would stop us
| from committing user-facing changes without a proposal, just as they
| should. Let's similarly police each other regarding the HF.
| - Work hard to avoid over-planning in tech track meetings. I think the
| meetings are valuable -- group synchronous brainstorming can be very
| powerful. But once a rough direction has been set, we should go to a
| more public venue.
| - Make it clear how to access the tech track meetings. The charter
| s.google.com%2Fdocument%2Fd%2F1VHfWX7GrFcuSl299S0zZfs-17iJAZ-
| bTU4SRe8Eboc8%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40micr
| osoft.com%7C6709ff5f90a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7
| cd011db47%7C1%7C0%7C637618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
| iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
| ;sdata=jqXEgw5nZKGmpyF9HesfIfFkGTXdgGY%2B%2FF1txyOcoLE%3D&reserved
| =0) says to email Emily, which is good, but I imagine few people would
| know how to navigate to this charter. Putting the information on the
| website would be much better.
| - Clarify the projects page on the website. One project there is
| approved by the HF, about text at UTF8. The installer has been
| proposed. All of the others are just ideas that have come up for
| conversation.
| - Engage more with Discourse. For Andrew and Emily, this would be (if
| we agree with these suggestions), quite literally, part of their day
| job. There is quite a bit of insight in the Discourse threads, but it
| looks to me that, often, the non-HFers are just learning from each
| other, and that the message isn't getting over the wall.
|
| I'm hoping that we, as a board, can get behind the proposal points
| immediately above and make these operating policy of the HF.
|
| Thanks for reading!
| Richard
|
| --
| website would be much better.
| - Clarify the projects page on the website. One project there is
| approved by the HF, about text at UTF8. The installer has been
| proposed. All of the others are just ideas that have come up for
| conversation.
| - Engage more with Discourse. For Andrew and Emily, this would be (if
| we agree with these suggestions), quite literally, part of their day
| job. There is quite a bit of insight in the Discourse threads, but it
| looks to me that, often, the non-HFers are just learning from each
| other, and that the message isn't getting over the wall.
|
| I'm hoping that we, as a board, can get behind the proposal points
| immediately above and make these operating policy of the HF.
|
| Thanks for reading!
| Richard
|
| You received this message because you are subscribed to the Google
| Groups "Haskell Foundation Board" group.
| To unsubscribe from this group and stop receiving emails from it, send
| an email to board+un...@haskell.foundation.
| To view this discussion on the web visit
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
| ps.google.com%2Fa%2Fhaskell.foundation%2Fd%2Fmsgid%2Fboard%2F010f017aa
| 1f5b4e3-2a6908f6-ff9e-41c3-b7a4-1cf6dbcb6c50-000000%2540us-east-
| 2.amazonses.com&data=04%7C01%7Csimonpj%40microsoft.com%7C6709ff5f9
| 0a54b3b199608d9464c8692%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
| 37618116769010555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
| V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=19TI35sxtTKvd5
| NfTIbB7rG8QF4CxH3BnUizyQAB9bw%3D&reserved=0.
Julian Ospald
Jul 17, 2021, 9:49:28 AM7/17/21
to Haskell Foundation Board, li...@richarde.dev
Thanks Richard, I think this is a good discussion and some things seem to clear up. Let me comment on a few points specifically:
On Wednesday, July 14, 2021 at 12:21:13 AM UTC+2 li...@richarde.dev wrote:
So, where do I propose we go from here?
- Be explicit about top-down vs bottom-up. If we are pushing an initiative using whatever force of will we have internally, let's say so in public with a rationale. I will assume "bottom-up" as the default (but happy to get push-back against this).
The question to me isn't just which mode you pick, but how you decide to do so.
Let's say there has been prior discussion and prior work in the community about an issue. Now HF wants to engage. What happens next? It may be tempting to say "hop on or we'll do it ourselves". This can be daunting.
Going further, I'm questioning whether everything needs to be a
"project" or a "proposal" or even needs a "lead". Open source has always
been a somewhat odd combination of liberal collaboration and
dictatorship of those who write the code or patches.
What's
wrong with opening issues on project issue trackers and providing
patches? When do we really need proposals? Why not collaborate in small
steps? Is this about making an impression or making change? Change often
comes in baby steps.
Proposals are good for
sweeping breaking changes, but not so much for long-term goals. It is my
impression that HF tries to be recognized as a force of change. Maybe
that has lead to some imbalance in the approach, heavily leaning towards
"project management". Maybe there are other reasons. Feel free to
correct me. But I personally would like to see concrete issues on my
issue trackers, possibly with nicely worked out patches, rather than
long blog posts about visions that leave me confused.
- Reinvigorate the tech-proposals repo, with a process that we pledge to follow and an explicit (that is, posted on Discourse) invitation to the community to write proposals. This also requires delineating the scope of the process. Emily's https://hackmd.io/W8THnWAtRfaG-p61lvdtiA?view is a great start to this.
As said above. It appears proposals seem to be the primary way HF wants to engage in change. Why?
- Commit ourselves to using the process, even for our own ideas. For example, the GHC proposals repo has many proposals from e.g. Simon and me. One reason for this is that our fellow contributors would stop us from committing user-facing changes without a proposal, just as they should. Let's similarly police each other regarding the HF.
- Work hard to avoid over-planning in tech track meetings. I think the meetings are valuable -- group synchronous brainstorming can be very powerful. But once a rough direction has been set, we should go to a more public venue.
- Make it clear how to access the tech track meetings. The charter (https://docs.google.com/document/d/1VHfWX7GrFcuSl299S0zZfs-17iJAZ-bTU4SRe8Eboc8/edit?usp=sharing) says to email Emily, which is good, but I imagine few people would know how to navigate to this charter. Putting the information on the website would be much better.
- Clarify the projects page on the website. One project there is approved by the HF, about text at UTF8. The installer has been proposed. All of the others are just ideas that have come up for conversation.
I have to add here: I didn't even know I was added to the project page. This should be more explicit, always asking for consent and clarifying the project structure (if it is a structured project).
- Engage more with Discourse. For Andrew and Emily, this would be (if we agree with these suggestions), quite literally, part of their day job. There is quite a bit of insight in the Discourse threads, but it looks to me that, often, the non-HFers are just learning from each other, and that the message isn't getting over the wall.
I'd say engage more with projects directly, on their issue trackers, and sum up results in a discourse thread.
Thanks for replying to my concerns!
Richard Eisenberg
Jul 17, 2021, 8:35:41 PM7/17/21
to Julian Ospald, Haskell Foundation Board
(All views expressed here are mine and mine alone. These are not representative of the HF, though my experience with the HF suggests that some others would agree with me on many points.)
You're getting at the heart of why the HF exists. Let's start with our vision statement (from https://haskell.foundation/vision/):
> The Haskell Foundation is an independent, non-profit organization
dedicated to broadening the adoption of Haskell, by supporting its
ecosystem of tools, libraries, education, and research.
Our overarching goal is adoption of Haskell. We aim to achieve that by supporting its ecosystem. But "support" can mean a range of things here. It could mean, for example, that we evenly distribute our cash among every project that mentions Haskell on its README. Yet I don't think that such a blunderbuss approach would yield the best impact on adoption. So we must be selective in how we support the ecosystem. Maybe we proceed by spending all our cash on bounties for contributors to improve cabal's documentation and GHC's error messages. I actually think this is already an improvement over the first approach, but any kind of selectivity is going to involve tough choices, and prioritizing some areas -- and approaches -- over others. I think this is a good thing, as the HF can be a body that tries to connect the dots of the Haskell ecosystem in a (hopefully!) coherent manner.
So, how concretely would I want to proceed? (Again, these are my personal views, not ratified by anyone else.)
1. Use a public proposal process to decide what the HF, as an institution, wants.
2. Work with others in the ecosystem to get what we want.
For (1), before the HF can take action (that is, provide technical coordination or other support -- such as provisioned machines or cash), we need to decide what it is we want to do. I see the proposals process as our way of making that decision. This is ideally done in public, so that the public can influence the direction the HF takes -- we are a part of the community, not some separate unit. The reason I'm so in favor of this proposal process is that it is a measured, documented way for us to make important decisions. (There will, of course, be smaller decisions that we make without a proposal process behind them. Deciding the line between "big" decisions and "small" ones is a matter of judgment.)
For (2), there are a variety of ways of proceeding. Posting tickets to existing projects is one way. In practice, though, I don't see this happening often: more likely, authors of relevant projects will be aware of the proposal as it is being debated and get involved long before the ticket is posted.
If we were to debate internally about what to tackle (that is, without a public proposals process), then posting tickets would make a lot more sense, as those tickets may be the first time project authors learn of the HF's initiative.
I think that, in our (understandable) desire to be able to post early progress, we have skipped the public, deliberative process used to decide what our next move is. It is my hope to rectify this.
On Jul 17, 2021, at 6:54 AM, Julian Ospald <hasu...@posteo.de> wrote:Why not collaborate in small steps?
A good question. I think, for example, it would be quite sensible for a proposal to specify several milestones, where each milestone is a small step. But having all these as part of one proposal keeps us with a long-term view, helpful for planning.
Proposals are good for sweeping breaking changes, but not so much for long-term goals.
It depends on the proposal, I think. There's nothing barring a proposal that describes long-term goals.
It is my impression that HF tries to be recognized as a force of change.
I would like the HF to be a force for change, yes. We (the working group that brought the HF into being) formed the HF because we saw areas of our ecosystem that were not working as well as we would like. So, improving these areas is indeed changes to the status quo. I don't think the HF wants to support change simply for the sake of change or to effect a certain impression of change.
I personally would like to see concrete issues on my issue trackers, possibly with nicely worked out patches, rather than long blog posts about visions that leave me confused.
Fair enough. We could choose this as a mode of collaboration, where our communication all comes in the form of tickets. However, I think working together to form the specifications of what would work well for everyone is richer collaboration. Again, I think a central difference from usual collaboration here is that the HF is a heterogeneous body who debates in public about what it will do. The blog posts are a part of that. What has been confusing is that the separation between "half-baked internal thoughts" and "concrete action HF wants to take" has been very blurry -- something I'm hoping we can improve on.
I have to add here: I didn't even know I was added to the project page. This should be more explicit, always asking for consent and clarifying the project structure (if it is a structured project).
Yes, I agree completely.
- Engage more with Discourse. For Andrew and Emily, this would be (if we agree with these suggestions), quite literally, part of their day job. There is quite a bit of insight in the Discourse threads, but it looks to me that, often, the non-HFers are just learning from each other, and that the message isn't getting over the wall.
I'd say engage more with projects directly, on their issue trackers, and sum up results in a discourse thread.
To me, the engagement on Discourse is about figuring out what it is the HF wants to do. Once that's done, then going to issue trackers is a fine next step.
Thanks for replying to my concerns!
Thanks for these questions. I think articulating my (personal) answers may be helpful in explaining my ideas within the HF, too.
Richard
Julian Ospald
Jul 19, 2021, 8:04:27 AM7/19/21
to Haskell Foundation Board, li...@richarde.dev, Haskell Foundation Board, Julian Ospald
Thanks Richard,
so from what I understand the primary reason for the formal proposal workflow is that there are monetary decisions involved that need a clear foundation and making this process open helps with transparency and community involvement.
What I feel is missing from your elaborations is this: does the HF intend to represent and connect the community, regardless of technical goals? Because community participation on proposals etc. seem to be initiatives the community takes towards the HF, because the board will ultimately be the body deciding on those proposals. To get into more details: How was the HF board constituted? Why would someone write a proposal if they don't need funding?
Then: when you say the HF engages with projects, you're saying it does so in the context of finding contributors for their own goals (which may be partly shaped by community members actively engaging in the proposal process or being affiliated with HF). This again makes sense in the context of monetary decisions.
But I'm not sure our biggest problem is really funding. To me it seems the haskell community is scattered due to diverging ideas, historical feuds and miscommunication. Funding and formal proposal workflows won't solve that. A body that is actively seeking to help the community would, IMO:
1. try to figure out what the community wants: I said this before: this can be done. We can pump up the Haskell Survey, have tech scouts write proper blog posts about the state of certain ecosystem aspects. Get a sense of maintainer opinions by engaging with them on their issue trackers. And yes: also have public discourse debates, where the conclusion is left open. This may conflict with the "broaden Haskell adoption in industry" goal.
2. try to connect parties in a neutral way without imposing goals on them: This requires building trust in the community and conveying a strong image of neutrality. This may be conflicting with other HF goals as well.
3. become a hub of discussion and collaboration: This requires building culture.
I'm not sure a single body can balance between those two approaches. I do think we need both, but from your email and my past involvement, my understanding is that HF tilts towards the formal funding-approach. I say this without any judgement. But this is, IMO, the main source of confusion.
I think many organizations face this issue, think of "Mozilla Foundation" vs "Mozilla Corporation" maybe. Clarifying goals and approaches will definitely also help the community understand the Haskell Foundation better. And it may also allow for alternative bodies, that complement it, if need be. As it is now, there are too many ideas floating around what the Haskell Foundation is or should be and maybe it's trying too hard to be the primary force in the community.
Cheers
Richard Eisenberg
Jul 21, 2021, 1:41:26 PM7/21/21
to Julian Ospald, Haskell Foundation Board
Hi Julian,
Please see my (personal) answers inline, below.
On Jul 19, 2021, at 6:51 AM, Julian Ospald <hasu...@posteo.de> wrote:What I feel is missing from your elaborations is this: does the HF intend to represent and connect the community, regardless of technical goals?
Yes, I think so.... except that I'm not sure about "regardless of technical goals". The Haskell community is wide, and many may have technical goals that the HF may disagree with. However, if a large segment of the community were aligned around a certain goal, then that goal is certainly something the HF should consider. Of course, this may happen naturally, as the HF selects its leadership from among the community.
Because community participation on proposals etc. seem to be initiatives the community takes towards the HF, because the board will ultimately be the body deciding on those proposals. To get into more details: How was the HF board constituted?
There was an open call: https://haskell.foundation/board-nominations/ still has the text of the call. The interim board (with members chosen by the initial group of people who conceived of the foundation) chose people who applied. Looking forward, we will refresh ourselves yearly, according to https://gitlab.haskell.org/hf/meta/-/blob/main/board.md#7-board-membership-lifecycle
Why would someone write a proposal if they don't need funding?
If they need coordination. Maybe an idea requires cross-cutting support from a number of tools. An individual could, of course, work with all of the tools directly, but this can be hard to do. The central location of the HF makes it a good clearinghouse for such proposals. The idea could get accepted by the HF (in consultation with the other tools), and then everyone would work together to implement the idea. This model does imply more coordination and collaboration among the tools than we have consistently done in the past -- promoting this collaboration one of the key reasons the HF exists.
Then: when you say the HF engages with projects, you're saying it does so in the context of finding contributors for their own goals
Yes, but our goals are intended to align with the goals of the community, as well as we can understand those goals. It's a challenge to know what a heterogeneous community wants!
But I'm not sure our biggest problem is really funding. To me it seems the haskell community is scattered due to diverging ideas, historical feuds and miscommunication.
I agree here.
Funding and formal proposal workflows won't solve that.
I disagree here: I think a formal proposal workflow directly addresses the problems you describe.
* diverging ideas: A proposal workflow invites people to write down their ideas, in detail, so that any points of difference become more obvious. It also provides a mechanism for broader participation in engaging with these ideas; this participation may lead to the community favoring one idea over another. Then, we, as a community, can better evaluate diverging ideas and (try to) settle on a concrete direction. The proposal process does not necessarily lead to consensus, but I believe a well-done proposal process will lead to a concrete understanding of where parties disagree.
* historical feuds: These are always unfortunate. My hope is that the proposal process would draw us into technical conversations, with details, thus defusing some of the inter-personal animus that has developed. Nothing is perfect here, of course.
* miscommunication: Proposals are all about communication. In particular, the goal of the proposal process is to structure communication around a revisable document, where the hope is that the document remains the ground truth, thus avoiding some of the more pernicious forms of miscommunication, where each party is debating something different.
A body that is actively seeking to help the community would, IMO:
1. try to figure out what the community wants: I said this before: this can be done. We can pump up the Haskell Survey, have tech scouts write properblog posts about the state of certain ecosystem aspects. Get a sense of maintainer opinions by engaging with them on their issue trackers. And yes: also have public discourse debates, where the conclusion is left open. This may conflict with the "broaden Haskell adoption in industry" goal.
I agree here. Creating a robust, science-first data collection mechanism (such as the Haskell Survey, among other approaches) is something that is very much on our radar. However, doing this correctly requires having enough funding to do so. It was our decision to first start on technical fronts to help bootstrap the funding mechanism, and then turn to data collection later.
I don't see how data collection (including open debate) conflicts with broadening Haskell adoption -- unless the community declares (somehow) that it prefers to remain exclusive.
2. try to connect parties in a neutral way without imposing goals on them: This requires building trust in the community and conveying a strong image of neutrality. This may be conflicting with other HF goals as well.
It depends on one's definition of "neutral". The HF is roundly pro-inclusion, both in the sense that we want a diverse contributor pool and that we want to attract new users to Haskell. I agree that the HF should not enter a conversation with an a-priori preference on what technical solution to a problem is best.
However, I do think it's appropriate for us to "impose goals" -- in particular, around user experience. For example, a goal could be to have a tool with a very easy flow around getting Haskell up and running on a machine. Maybe a tool maintainer's goal differs -- they might want the tool to query the user many times to let them choose an array of preferences. That's reasonable, but perhaps not what the HF thinks is best. So, it's conceivable that we could work with a tool author, only to discover that the HF and the author do indeed have diverging goals, and that's fine. Naturally, the author could decide at that point to discontinue collaborating with the HF; nothing stops this.
3. become a hub of discussion and collaboration: This requires building culture.
Separate from our technical work, the HF has also been building community around the HF Slack instance. There's always room for improvement in how such a venture is managed, but we've already explored the possibility of trainings for potential moderators, and seeking out folks from other online communities in how best to manage ours. So this is very much in the HF's current purview.
I'm not sure a single body can balance between those two approaches. I do think we need both, but from your email and my past involvement, my understanding is that HF tilts towards the formal funding-approach. I say this without any judgement. But this is, IMO, the main source of confusion.
From where I sit, I don't see that we're primarily about funding. I see us as primarily about community -- the funding is there to fill holes where they exist, and where the community cannot satisfy a need (within a given timeframe).
I think many organizations face this issue, think of "Mozilla Foundation" vs "Mozilla Corporation" maybe. Clarifying goals and approaches will definitely also help the community understand the Haskell Foundation better.
I agree strongly here. It's clear we need to do better in our messaging. As we settle into more of a repeatable process, I think we can do a better job of articulating all of this.
Richard
Reply all
Reply to author
Forward
0 new messages