Improving communication, transparency, and adoption

Pinging @emilypi, but posting publicly instead of in an email, since the whole point of this is transparency :slight_smile:

The purpose of this post is to kick-start a conversation around improving transparency into the Haskell Foundation (HF). But more broadly, this turns into how to make Haskell-the-community writ large more approachable. Everyone seems to be on board with the general notion of “transparency.” But like any broad term, it’s easy to agree to something and mean different things. So to start this off, let’s get some concrete goals defined.

Goals

In my opinion, if we are successful, we will achieve the following:

  • People will understand how decisions are made within the Haskell Foundation and related projects
  • People will be able to easily discover, for a wide range of topics, where best to ask questions, raise concerns, offer assistance, etc
  • Members of projects will know how to effectively broadcast information to others within the community but not intimately involved with projects
    • Those members will also know when they should broadcast information for maximum impact
  • People broadly interested in Haskell will have multiple, easy ways to stay up-to-date on important information
  • Existing communities, such as Reddit, Twitter, and the mailing lists, are kept in the loop as well

I hope these are non-controversial, but if people have objections, please raise them! And to be clear, I don’t think this is an exhaustive list. I think this is a good starting point, since it balances high priority and relatively easy to achieve items. Others may have different views on what should be tackled first. If so, please raise them!

Next steps

Now, some concrete comments on how I would achieve this:

  • Treat the Haskell Foundation homepage as a central point of information access
  • Host the source code for this site on Github, and provide clear instructions on how to submit PRs to modify content
  • Provide a blog with RSS feed on this site, and make it possible for multiple people to submit posts. Make it clear what the criteria is for “a blog can go here”. Subscribe this blog on Planet Haskell. And post every blog post on HF’s Twitter account and the Haskell subreddit
  • Provide a single page on the site delineating roles and responsibilities for core pieces of infrastructure. “Want to make a change to the transformers package? You’d talk to X group.” And include a section at the end of the page that clarifies “if anything wasn’t clear here, come to Discourse and ask.”
  • Do some user testing, by asking Haskellers not associated with HF to review the new pages and provide feedback on what questions they are left with

I personally am not sure who has to sign off on this as a plan-of-action. I’m also not sure who has the ability to get many of these steps implemented. Let’s first figure out if this is a plan we want to follow through with, and then decide on how to achieve it.

Further actions

I have further ideas in mind for what should happen next. I hesitate to mention these now just to avoid derailing short-term actions, and because these ideas are more subject to change. But I want to over-emphasize transparency, so I’ll mention some of them right now.

  • Discourse is great as a primary communication mechanism, but I think many projects will need real-time text and video chat as well. HF should endorse a single tool for this. I have a lot of experience choosing bad tools for this in the past…
  • I’ve already mentioned that I want to get Stack and Stackage more officially integrated with HF. In the case of Stackage, I will begin pursuing that, but I think it should come after website improvements so that we can make clear statements on the website itself.
  • The Stack case is more complicated, and more interesting. While Stackage has a clear governance structure, Stack is much more the wild west. I want to use this opportunity with HF to define this. I’ve avoided doing so previously out of laziness, but now’s a great time to overcome some inertia.

I’ll stop here. One paradox of transparency is that overly transparent communication is actual verbose communication, and that serves to hide a message instead of exposing it. I may have already crossed that line here. Anyway, let’s get this kicked off!

18 Likes

In the scope of the post this might be minor but: why not GitLab? Both GitHub and GitLab have their problems (e.g. barring contributors from certain countries), but at least the latter is open source and could be patched or become self-hosted if the need arises.

GHC chose a similar path also for this reason (Why not GitHub?«Github is not open-source, so we can’t fix any (future) issue we might have with it»).

2 Likes

Simple answer: we want to encourage as much contribution as possible, and reduce barriers to entry as much as possible. Github is de facto the most popular platform. Gitlab (and definitely Haskell’s own installation of Gitlab) is not as popular, and will require users to create accounts and become accustomed to a new interface.

Is Github perfect? No. There are flaws. But most of the points in the GHC document are not relevant to a greenfield, tiny, standard website.

10 Likes

Awesome Michael – this is great and I look forward to many such threads from other projects.

2 Likes

I don’t have a particularly strong opinion here but I would like to point out that GitLab does support authenticating via GitHub credentials via OAuth. Of course, the interface is indeed slightly different, but in my experience the differences are strict improvements (e.g. single-level threading of comments helps to keep long comment-chains manageable).

But again, I don’t have a strong opinion here.

3 Likes

To what @bgamari said, I would add that:
you previously stated

So you are already thinking about giving very precise and clear instructions for contributing, so I would not find much difference for newcomers that may be new to github too, in the end they always need to read the docs first.

It does not seem to me that we are always obliged to navigate in the same web pages, so also given the fact that Gitlab is not completely alien compared to Github, or other solutions, it doesn’t to seem to me that this is a relevant problem for newcomers, while for more experienced users, it takes very small effort to learn the difference, and I again stress the fact that every user should in any case first read the docs to learn how to properly contribute (or am I being utopistic here?).
Finally I’m a bit skeptical of the argument more used == more intuitive

So I would ask, in the spirit of communication and transparency why don’t you base your decision (which is going to be of the HF commitee in the end) on a poll for the whole community?

So you are already thinking about giving very precise and clear instructions for contributing, so I would not find much difference for newcomers that may be new to github too, in the end they always need to read the docs first.

I completely disagree with this statement. I have personally contributed to dozens of projects with trivial wording improvements without having to “read the docs first.”

or am I being utopistic here

I’m not sure about “utopistic.” But the mindset you have just expressed is IMO incredibly ingroup-oriented. I will argue vehemently against this mindset.

Finally I’m a bit skeptical of the argument more used == more intuitive

Can you point out where this argument was made?

So I would ask, in the spirit of communication and transparency why don’t you base your decision (which is going to be of the HF commitee in the end) on a poll for the whole community?

I think you’re misstating a process here. I have no decision making authority. I’m expressing my own opinion. I’m providing a proposal. You may want a different decision. You haven’t explained why that is. If the actual decision makers decide this is a contentious issue and want to start a poll, they’re more than welcome to. As stated, I will argue vehemently in such a forum that siloing ourselves behind Gitlab instead of Github is a sure-fire way to slow down new contributions, and should be avoided at all costs.

And lest someone accuse me of some inherent bias: I use Gitlab exclusively at work. I am personally fluent in both systems, and in many ways prefer Gitlab. I’m basing my opinion on the extensive experience I have, and other community’s do as well, in building thriving OSS ecosystems. And in my opinion, Github is simply superior in this arena.


As an aside, at a process level: it’s worrying to me that the only substantive responses to my post are focused on this one topic. The responses are not IMO expressing any concrete reason to change from the de facto standard way of doing things in the world. They are denying realities of the onboarding problems we face. It’s in fact almost parallel to the discussion that preceded moving to Discourse: a bunch of people already in the community making claims without addressing the substantive issues raised about what others will consider important.

I consider the choice of platform vital here. But I also don’t want to further distract from what I was actually trying to focus on here, which is how we improve transparency of how this organization operates. While related, I would suggest that if anyone wants to pursue the question of where to host code for a website, they start it in a new thread.

7 Likes

I think one challenge in this thread is that there isn’t really much to say, other than “I agree.”

By the way, the website is already hosted in public on GitHub: https://github.com/haskellfoundation/haskell.foundation Other “Next Steps” in the original post (other than user testing, which I agree is a great idea) have all come up in other conversations, and I expect we’ll do them. So I think we’re on a good path here. :slight_smile:

It all just takes time. As I understand it, @snoyberg has been asked to head up an effort within the HF to increase and shore up transparency issues. So, if you like, you can schedule a call with an invitation to participate, or you can recruit people to help implement, or just blast forward.

1 Like

I think there’s plenty to say beyond “I agree.” For one, providing the link to the existing repo for the site is incredibly valuable, thank you. I had no idea this already existed.

Other “Next Steps” in the original post (other than user testing, which I agree is a great idea) have all come up in other conversations, and I expect we’ll do them. So I think we’re on a good path here. :slight_smile:

This is good, but also slightly concerning. I’m not sure where these “other conversations” are happening. I don’t know who the “we” is in “we’ll do them.” I’m not sure who is trying to take this initiative. I don’t know who has decision making authority. I don’t know how to contribute. I don’t know where to send people who want to provide feedback.

So, if you like, you can schedule a call with an invitation to participate, or you can recruit people to help implement, or just blast forward.

I think you’re not seeing the gap that exists between what an outsider (like me) is seeing and what an insider would see. I’m laying out a roadmap that you’re implying already largely exists. Until your comment, I didn’t have the first idea on how to “just blast forward.” Now that I know where the code repo is, I’m still left with many lingering questions.

None of that is to say something is fundamentally wrong. As you said, “It all just takes time.” And my goal here is exactly to elucidate these points. I just want to push back on the idea that “there isn’t really much to say.” I think the people involved thus far have a lot of information, feedback, assistance, and direction to provide. They just may not know it.

3 Likes

I think I was not clear, my English is not really good (and I apologize for this). I’ll briefly clarify my point. I am not against github, I am just saying that your answer does not make much sense, here is why:

I totally agree with this goal.

This seems not well argumented, in fact, from what you wrote it looks like gitlab is harder to use, but I see no reason why. You just said that github is more used, hence more people are accustomed to it. But who are these people? How many of them there are, and why you are sure they wouldn’t easily get accustomed to gitlab’s interface? Also what about complete newcomers?
Also if this is so easy to use github for doing pull requests and contributing, because you are accustomed, why do you need to

?

I don’t want in-group logics at all, and if everybody thinks github is easier, I totally agree and I also agree that github gives more visibility in google searches, I I just didn’t trust your arguments, because they looked specious, to me.

I don’t expect an answer, I just wanted to make clear that I’m not trying to bikeshed anything, it just seemed to me that your argument was vague.

Finally I’d like to propose if it was possible to have a twitch channel where people can broadcast their haskell stuff, like kmett used to? It’d be cool, imho to have a centralized place where to get those videos. What do you all think?

This seems not well argumented, in fact, from what you wrote it looks like gitlab is harder to use, but I see no reason why.

I’m also a regular user of Gitlab and have used it professionally for a few years, I agree with Michael’s assessment that GitHub is far more popular among open source developers and makes the most sense.

If the aim is for the path of least resistance for the users, the project should come to where they are rather then force them to come to where the project is.

It’s easier for me to follow the work done on a project if I see it in my GitHub timeline, or get a notification because I clicked the follow button. Maybe there’s just one particular issue or PR that I’m interested in, and if it’s already in GitHub it makes it much easier for me to click and follow or chime in.

I believe the path of least resistance is incredibly important for wider adopting. This is true for the hosted platform, as well as documentation and transparency. Make it easy for others to participate. Come to them.

Finally I’d like to propose if it was possible to have a twitch channel where people can broadcast their haskell stuff, like kmett used to? It’d be cool, imho to have a centralized place where to get those videos. What do you all think?

You might be interested in https://github.com/chiroptical/declarative-programming-streams

4 Likes

In this case, the conversation was in the biweekly Haskell Foundation Working Group call, which I know happens at a time you are unable to attend. We have minutes from this meeting, but I believe we decided to wait a week after each meeting for the members to review the minutes before posting them publicly.

What is this HFWG, you ask? It’s a group of people, working with the blessing of the interim board, to carry out the day-to-day responsibilities of the HF. Right now, the WG is about setting up all the structure that we need. One of the recent areas of work is defining the WG publicly, including listing the names of WG members on the website. Anyone can join the WG just by asking, as we will highlight once the statement is ready for the website.

One particular idea from the last meeting that you may welcome: there appeared to be consensus that we would establish a public calendar of HF meetings, preferably with the ability for open attendance (but perhaps not with the general public being able to speak), and where we will post minutes after they have been agreed to.

We = all of us. The Haskell Foundation and/or its Working Group. You and I. That might read as overly flowery, but I mean it: there is not meant to a barrier between “insiders” and “outsiders”, and so “we” really means all of us.

The interim Board, who have formed and empowered the Working Group. (The membership of this Working Group will be posted soon.) The idea is that there should be consensus around decisions. If consensus is elusive, then the Board itself opines.

Right here. The Board decided to bless this Discourse category as the official communications hub of the HF and its WG.

I’m still left with many lingering questions.

Then please ask them!

My sense (and apologies if I have this wrong!) from reading your posts is that you’re feeling frustrated by lack of knowledge. Please just ask the questions you have – and trust that transparency really is one of the HF’s core values, one that we’re working on living up to.

Maybe my “there isn’t really much to say” reflected that I didn’t see questions to answer. The questions are more apparent now, so I tried to answer them.

2 Likes

Just came across https://github.com/haskellfoundation/haskell.foundation/issues/36, which is the request to post the calendar.

Then please ask them!

I was referring to my list of questions here, which you’ve very helpfully answered, thank you.

My sense (and apologies if I have this wrong!) from reading your posts is that you’re feeling frustrated by lack of knowledge

No, not at all. I expected a lack of knowledge. That’s the reason I’m focusing on helping with transparency. It’s not clear how this is all supposed to move forward. I am intentionally trying to be as much of a forcing function here as possible.

Please just ask the questions you have – and trust that transparency really is one of the HF’s core values, one that we’re working on living up to.

Part of the problem here is that it’s unclear which questions to ask. I had been told to speak with @emilypi about all of this, which I’m trying to do here. It seems that things are further along, or at least differently along, than I’d expected. Again, this isn’t a surprise, and not something that’s frustrating me. But I am trying to point these cases out.

Maybe my “there isn’t really much to say” reflected that I didn’t see questions to answer. The questions are more apparent now, so I tried to answer them.

Again, thank you!


All that said, even your answers here are still leaving open what I’m supposed to do next. The board makes decisions, and I’m supposed to discuss things on Discourse. At the same time, you’re already linking to Github issues where other discussions are proceeding outside of Discourse.

Are we at the point where PRs to that repo are expected? Are we supposed to be getting sign-off from the entire interim board? Is there someone designated as the day-to-day overseer of the website?


Here’s my proposal of a step forward:

  1. Someone should be “the person in charge”
  2. The interim board should make clear who that person is
  3. The interim board can revoke that at any time
  4. That person should indicate where and how contributions should be made

I think that person is in fact Emily, but I may be wrong.

3 Likes

Hi Michael, apologies for the delayed response. It was a heck of a week last week!

Re: goals:

I agree with all of these goals. I don’t even really have refinements or additions. Just agreement.

Re: Next steps

  • Treat the Haskell Foundation homepage 25 as a central point of information access
  • Host the source code for this site on Github, and provide clear instructions on how to submit PRs to modify content
  • Provide a blog with RSS feed on this site, and make it possible for multiple people to submit posts. Make it clear what the criteria is for “a blog can go here”. Subscribe this blog on Planet Haskell. And post every blog post on HF’s Twitter account and the Haskell subreddit

I agree with this. As we’re redesigning the site, I’ll remember to raise this and see if we can’t add the ability to have multi-author blog posts and a subscription feed. Just for clarity and my never having used it, what is the utility of Planet Haskell? Do we have any metrics regarding its usage?

Provide a single page on the site delineating roles and responsibilities for core pieces of infrastructure. “Want to make a change to the transformers package? You’d talk to X group.” And include a section at the end of the page that clarifies “if anything wasn’t clear here, come to Discourse and ask.”

Agreed. As a point of reference, consider Scalacenter’s team page. Each profile entry consists of 4 things:

  1. A name
  2. A way of contacting that person
  3. Their role
  4. What projects they are affiliated with

Each project links to the homepage/source of the project, which includes how to contribute + all the extra information needed to contribute/raise concerns etc. This is good design. I’d love to have something like that at some point.

Do some user testing, by asking Haskellers not associated with HF to review the new pages and provide feedback on what questions they are left with

Focus group testing is +1 from me.

Re: Further Actions

Discourse is great as a primary communication mechanism, but I think many projects will need real-time text and video chat as well. HF should endorse a single tool for this. I have a lot of experience choosing bad tools for this in the past…

For real time text, this is difficult. We arrive at a crossroads:

  • Slack and Discord are not transparency-forward. Without a paid account, history is swallowed up by the abyss in the case of Slack, and Discord does not allow you to export logs as far as I know. In the latter case, if a channel or server is removed, its data is lost forever.

  • IRC/Mailing lists are antiquated and people do not seem to respond to them in the broader industry. I view IRC as eminently user friendly and easily made persistent, but others always seem to disagree.

So the question here is “what can we use for real time chat?”, and I’m at a loss. For voice, it’s relatively simple: Jitsi. It’s free to create a room, free to join, and i don’t even think you need an email, so it’s freely auditable. It integrates with calendar invites relatively well, so I advocate for it.

I’ve already mentioned that I want to get Stack and Stackage more officially integrated with HF. In the case of Stackage, I will begin pursuing that, but I think it should come after website improvements so that we can make clear statements on the website itself.

+1 that’s good news, and I’m happy to work on the website first. That’s a good carrot at the end of the stick for us.

The Stack case is more complicated, and more interesting. While Stackage has a clear governance structure, Stack is much more the wild west. I want to use this opportunity with HF to define this. I’ve avoided doing so previously out of laziness, but now’s a great time to overcome some inertia.

Happy to help. It would be nice to synchronize a bit more with the cabal people as well (Oleg in particular). Perhaps this can inspire some collaboration!

Re: Proposal of a step forward

  1. I am that person. The board elected me chair of the working group, so we can get started immediately with any and all planning/action items/projects.

  2. They did, but it was not publicly announced. I’ll tell Simon we should announce it publicly.

  3. Yes, they can.

  4. Let’s figure this out.

So as a next step, can we schedule a working group meeting to help sort out what the calendar should look like for your suggestions?

5 Likes

My understanding is that Discord has an API that allows, for example, mirroring posts to/from IRC. (Some OCaml folks did this for their IRC and Discord channels.) Maybe that makes it possible to copy Discord discussions continuously, or regularly, to a storage location. Perhaps there are problems–Discord policies, for example–that I don’t know about.

1 Like

I didn’t realize that a redesign was in the works. Maybe this goes together with Richard’s comment about meeting minutes being delayed a week, but this is surprising. Is this being written down/shared/announced anywhere?

Just for clarity and my never having used it, what is the utility of Planet Haskell? Do we have any metrics regarding its usage?

Maybe it’s just for old people like me. When I started using Haskell, Google Reader was still a thing, and subscribing to Planet Haskell was the easiest way to stay up-to-speed on content. I still use it, and I thought others did too. But I honestly have no idea how prevalent its usage is. Regardless, an RSS feed would be a good thing to have.

I agree that the realtime text communications are a complicated topic. I’d recommend that we table that discussion for now. But I do think we should have that discussion here on Discourse at some point.

I am that person. The board elected me chair of the working group, so we can get started immediately with any and all planning/action items/projects.

That’s good to have officially. And as a note, I think we should ensure this kind of information is readily available on the website after the redesign.

So as a next step, can we schedule a working group meeting to help sort out what the calendar should look like for your suggestions?

Sounds good. I don’t know who the working group is at this point. Can I ask you to schedule something? For a “transparency but not spam” suggestion:

  • Let’s take this offline at this point for scheduling
  • After we discuss, one of us will update this thread with a summary
2 Likes

Recommendation from me, and I’m happy to move this to a new thread to discuss: I think this is a mistake. Minutes should be posted immediately. It’s much better to get the information out, and then allow people to add corrections/comments. In addition to keeping everyone in the loop, it’s a great way to more proactively discover if people had different understandings of a meeting.

1 Like

It’s common practice, at least in any organisation I’ve ever been involved in, to review minutes before making them public. For a good reason, I think. It is far too easy to misrepresent someone’s opinion or statements unintentionally when making notes, and once such misinformation is out, it’s much harder to correct.

7 Likes

I would suggest considering Matrix which can be used via the Element or Gitter clients. Element doesn’t require an email account to sign up and it has good IRC interoperability. I have been connecting to the #haskell IRC channel with the Element client for a while now.

4 Likes