Improving communication, transparency, and adoption

[simonpj]

@rebeccaskinner

To that end, I wonder if we should worry a little bit less about the details of how to maximize transparency with the current process, and instead focus on how to grow into a new process that has transparency built in from the ground up

I’m sympathetic to that point of view. But I think that in any setup I can currently imagine we are going to have working groups (from the board through to a highly focused limited timeframe group) that will want to meet together, record their thoughts, decisions, proposals, and share that thinking with others. The kind of workflow I describe above (or some variant thereof) is going to be necessary for any such group. So I don’t think it would be effort wasted or duplicated.

You raise a separate question, namely the future of the current Haskell Foundation Working Group. My personal view is that it, or something like it, may well be useful into the future. We want a “way in” whereby people who would like to contribute to the Foundation can actively do so.

You might say that anyone can, but my experience is that when everyone is responsible then no one is responsible. Example: I pay a lot more attention to GHC proposals because I am a named member of the group that has (as volunteers) agreed to pay careful attention to GHC proposals and ultimately decide about them. I would pay much less attention if I had not explicitly made that commitment, and was not a member.

But that’s just a personal view. The long term future of the HF WG is ultimately a matter for the Board, once appointed. Meanwhile, I don’t think we need wait for that day to get good workflows in place as above – I think we will need them regardless.

[rebeccaskinner]

I’m sympathetic to that point of view. But I think that in any setup I can currently imagine we are going to have working groups (from the board through to a highly focused limited timeframe group) that will want to meet together, record their thoughts, decisions, proposals, and share that thinking with others. The kind of workflow I describe above (or some variant thereof) is going to be necessary for any such group. So I don’t think it would be effort wasted or duplicated.

I think the process you outlined is good, and not too bureaucratic at all. I believe that if we focus on the best way to implement transparency in these groups we’ll be in a good state. I do think it’s unlikely and impractical for most of these new working groups to have the size and scope of the 40+ member working group we had when we were launching the haskell foundation.

Even if many of the processes we want to adopt won’t be meaningfully different between the new smaller working groups and the larger current working group, I think there will be a few places where we’ll want to have different priorities at least. For example, in a 40-person working group, decisions will be relatively slow, and a lot of time and energy may need to be spent making sure everyone’s voice is captured accurately in the minutes. For a two-person working group, making sure everyone’s perspective is captured might be trivial, but it will take some effort to consciously make decisions slowly enough that the community has time to provide input.

My thought was just to say that, if there’s a conflict, we should be prioritize ensuring that these newer smaller groups can operate effective and with transparency before we focus too much time on the sorts of problems that will most hamper the larger sized working groups that we might not see as much of in the future.

[simonpj]

@rebeccaskinner

My thought was just to say that, if there’s a conflict, we should be prioritize ensuring that these newer smaller groups can operate effective and with transparency before we focus too much time on the sorts of problems that will most hamper the larger sized working groups that we might not see as much of in the future.

I’m fine with that!

Meanwhile, does anyone have advice about mechanisms to support the workflow outlined above? Neither Google docs nor GitHub seem ideal on their own. Maybe

• Google docs for the real-time writing. (A new link, so privacy is a minor issue.)
• Transer to a private GitHub repo for review and refinement
• Transer to a public GitHub repo to publish

That seems a bit complicated. Others will have better ideas, I am sure.

[carlosdagos]

I would support Michael’s view on full transparency where there’s no state in which the meeting minutes are private. As I understand, the desire for meeting minutes to be private is to offer the attendees the chance to properly articulate their viewpoints in case they may be misrepresented and that’s totally fair.

I would say that a potential workflow could be:

1. Use a real-time collaboration tool (i.e. Google Docs).
2. When the meeting is done, move the contents to a repo like so:
   i. Create a “Draft” PR in a github repo under the haskellfoundation org.
   ii. Every attendee has a chance to re-word and/or ratify the points.
   iii. Once the deadline is reached, merge.

No tool is perfect, but IMO with this workflow the benefits are:

1. Meeting minutes are recorded for posterity under the HF’s github org.
2. The original meeting minutes are stored in a PR.
3. Every amendement done by the attendees is also public, as it stays in the PR where everyone made sure their viewpoints were accurately represented and signed off on it.

It would entail however making sure that the repo/org settings are appropriately tweaked to only allow attendees to be able to suggest edits to the minutes, and maybe to enable only “owners” to merge.

Just an idea. Happy to see these conversations happening

[f-a]

I am puzzled by the focus on minutes. In every firm I have worked/non-profit organisation I have collaborated to the minutes are made public only after each participant has had the chance to review them and sign them off. This usually happens at the next meeting, where the first point on the agenda is «approve last meeting minutes».
In this regard seven days of time to review is speedier than bodies with way more resources than the HF. It also makes the job of the minute taker less of a burden.

[snoyberg]

@f-a

I am puzzled by the focus on minutes.

I’m puzzled by the pushback here. And I’m puzzled by the claims. I’ve never seen an organization behave the way you and others are describing. Regardless, let’s ignore “what other organizations do” and focus instead on why the status quo is broken and needs to be fixed here.

The claim is that the HF working group is transparent. The claim is that Discourse is a good place to discuss activities. At least, I think that’s the claim. This very thread demonstrates that the status quo breaks this. Without assigning fault, let’s point out that we had an entire conversation for a week straight here. I was specifically asked by WG and interim board members to take initiative on these points. And only later did we all find out that at the 40-person WG meeting, decisions were reached that superseded anything we discussed here. That’s a broken system.

I don’t understand how a 40-person group can be effective in video calls. I’ve never been to those meetings, so I can’t speak to it. I can say that it creates a layer of opacity that I think is unhealthy. Further obscuring behind a week long delay to write down for the public what was discussed essentially means everyone on the outside needs to wait a week after each of these meetings to have any real conversations, because we don’t know what happened at the WG meeting.

@simonpj I’ll tell you directly what I think should be the MO here:

• There is a general HF working group, I don’t have an objection to that
• However, the primary communication platform is Discourse, nothing else
• Other conversations will happen, including video calls, text chats, etc
• Like I did above with Emily, the correct thing to do is to state “we’re taking this discussion offline, and we’ll post a follow up when we’re done.” Essentially: we’re publicly grabbing a mutex
• I think a 40 person general-purpose WG is a bad idea. I think specific, focused working groups are a great idea. Let’s say we decide that we need to rebrand Haskell with a new color scheme (silly example). The process I’d see is:
  1. Someone raises the point here on Discourse
  2. People generally agree it should happen
  3. Someone takes initiative to own the process
  4. That person says “we’ll go work on this for 2 weeks, if you’re interested, ping me”
  5. When that person is done, they present their findings here on Discourse
  6. If there’s disagreement at any point in this, then the board would step in

Right now, the claim that Discourse is the primary communication mechanism is false. The real communication is still happening at a private meeting. It’s great that we now at least have the promise of meeting minutes, but it’s still relegating the community to second-tier at best.

[simonmic]

Thank you all very much for working on this!

And, here are three cents from a random Haskeller:

Planet Haskell: I read Planet Haskell, via feed reader (bazqux.com) and highly value it. It’s our community’s aggregator of blogs and blog-like feeds. It’s a very efficient way to keep up with a community’s blogosphere; it has been a kind of standard in FOSS communities for years (Debian, Ubuntu, Gnome, etc.) This is more reliable than relying on, say, reddit mentions. At least if people continue to add their blogs to Planet Haskell. At present, I think quite a few do not do this (and many folks aren’t aware of it).

Real-time chat/audio/video: Matrix is the solution. Slick clients on all devices (eg Element), works very well for matrix, IRC and gitter rooms, has jitsi built in, has strong governance and a bright future, etc.

Minutes: delayed minutes (by a week!) may be the norm in “real life”, but it’s not what works well in the FOSS world. I think this new initiative will live or die on its Transparency, so I think hidden minutes are the wrong choice here. I fully agree with Michael’s pushback and I want him to rock the boat here; he is doing his job.

[simonpj]

This is a good conversation.

Perhaps it’s got to the point where the Transparency Working Group (= Emily, Michael, and anyone who would like to join them) can talk about it, come to a consensus, and emerge with some concrete proposals to bring to the WG and board?

Simon

[rae]

A very easy solution has occurred to me that I thought I would share:

It has been floated that regular meetings would be streamed for wide attendance. If that’s the case, and if the recording is preserved, then we can have our cake and eat it, too: we have the transparency granted by having the raw video available, and the chance for the minutes (which are much quicker to consume) to be reviewed before posting. With the original recording freely available, there does not seem to be a need also for the minutes to be instantly available in order to guarantee transparency.

Personally, I see both sides of the argument on whether minutes should be embargoed or released at once. With the addition of streaming, however, it seems both sides of this debate can get what they want, which is surely a good thing.

[snoyberg]

I wouldn’t consider that a good solution. In my blog post on transparency, I called this out to some extent:

Appropriate signal to noise ratio

Burying important action items in a 2 hour video that needs to be watched in full to pick up on the important parts does not fit my definition of transparency. To quote the referenced Hitchhiker’s Guide to the Galaxy:

“There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you’ve never been to Alpha Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away, you know. I’m sorry, but if you can’t be bothered to take an interest in local affairs, that’s your own lookout. Energize the demolition beams.”

[rae]

@snoyberg

Burying important action items in a 2 hour video that needs to be watched in full to pick up on the important parts does not fit my definition of transparency.

I agree! I’m not at all suggesting that the minutes not be published.

It seems to me that there is worry that allowing a time for closed-session minutes-editing would somehow give rise to nefarious actions – like unsaying something. While I personally disagree with these fears, I understand why people would worry about this. However, if a video is freely available, then there is a strong disincentive to trying to misrepresent history in the minutes.

My bottom line: the video makes all the information available immediately (but in a time-consuming-to-access format), while the minutes makes all the information easy to digest (but with a small delay in publication).

[emilypi]

Just boosting this post because I’m scheduling it now. Message me if you want to join.

[snoyberg]

@rae

It seems to me that there is worry that allowing a time for closed-session minutes-editing would somehow give rise to nefarious actions

I think this is the third time in this thread you’ve implied a motive to me that I never said. I said nothing at all like this. I would appreciate if you would respond to what I’ve said, not what you think I may be thinking. I do not claim nefarious actions. I don’t believe such things would happen. I stated my reasons for being opposed to this secret-minutes approach above.

I can’t state my position more clearly than I have, and I can’t have a conversation where someone makes up motivations for what I’m saying. I do not accept “publish the video” as an act of transparency, and I’ve stated why above.

[simonmic]

I am probably naive, but: adopt a policy of getting everybody’s agreement on the minutes before ending ?

In my mind, in the FOSS/getting-things-done-in-a-big-online-community context, a meeting that hasn’t confirmed its minutes, is unfinished. Better to design meetings to be more atomic and definite ?

[emilypi]

So, I don’t want to get bogged down in this convo longer than we already have, but I’d be in favor of a 24-hour review process and then posting it publicly, immediately. All changes must be made within a day, and we have a deterministic staging area everyone can access. Perhaps staging on Github, with the publication being on the site.

I feel like this is a happy medium. I don’t think the pace of conversation should be such that we wait days plural or weeks to ratify minutes.

[parsonsmatt]

When you say “everyone can access,” do you mean the general public (aka a semi-public publish), or just the working group (aka private)? Having the text available in eg a GitHub PR to the main website would satisfy everyone’s needs I think.

[emilypi]

I’m fine with read-only for everyone outside, read-write for the working group. The main point of publishing it to the site, would be that there would be a “blessed” official version, but there’s no reason why people shouldn’t see the history in github. Most people know how to edit a markdown file on github, and we can track historical changes/PR’s easily. It’s a win-win.

[jaspervdj]

I think a 24-hour review period is reasonable compromise.

For whatever it’s worth, I trust everyone on the board will have good intentions and would not intentionally misrepresent someone in the notes. If someone is accidentally misrepresented, I’m sure we can sort that out by talking to each other.

However, I am a bit worried about accidentally leaking confidential details (e.g. ongoing sponsorships with company X that hasn’t been confirmed and company X doesn’t want this public yet) so I think having some review period to double check these things is good.

[Nycticorax]

@snoyberg worries that waiting a full week before releasing the minutes is not doing justice to transparency.

Others worry that releasing the minutes immediately after meetings might run the risk of ascribing claims, thoughts or intentions not completely faithful to participants.

Humble suggestion from an anonymous trying to reconcile them all:

1. schedule meetings in a way that makes reviewing the minutes part of the time participants plan for, i.e. a 1.30 long meeting should reserve 15 minutes for the minutes right after it’s done.
2. to alleviate the pain of longer meetings, make sure that every meeting are announced in a way that:
   • summarizes the context from the previous meeting;
   • introduces the context for the upcoming meeting, with goals, objectives, and people responsible clearly identified;
   • provides material for people to do their homework ahead fo the meeting, so that every is on the same page when the meeting comes up.

Then

3. organize and moderate meetings in a way that minimizes the number of “open questions”, so that most of the meeting around “I assent” / “I dissent, for reasons X, Y, Z”.

Of course, this presupposes that people are going to communicate and ask questions ahead of the meeting. If this presupposition cannot be honoured, the above bullet points can be tweaked to make more open questions enter the meeting proper.

[snoyberg]

We had a transparency track meeting on Monday (December 21), the notes are available here: https://docs.google.com/document/d/1mhokEg3M0E8f9i7-c4oEq-aNmATZrYBS_dWD3D5z3iQ/edit?usp=sharing

As a summary: for most of the topics that we’ve been discussing in the thread, the takeaway is “Emily will raise the points at the next biweekly working group call.”