[Request for Comments] Proposal process proposal

Haskell Foundation
#1

In an effort to create a repeatable, predictable process for creating official Haskell Foundation proposals, I am proposing a proposal process proposal. So very meta. Wow.

You can find the proposal and any discussion around it in the Haskell Gitlab MR: https://gitlab.haskell.org/hf/meta/-/merge_requests/11

For convenience, here is a link to the rendered initial version: https://gitlab.haskell.org/hf/meta/-/blob/8088111238a35f6415c8b3633c7bff45dad314c9/proposals.md

Here is the full, initial text:

Lifecycle of Haskell Foundation Proposals

Incubation

This process is open to anyone in the community with ideas on how the Haskell Foundation should operate, what work we should undertake, and how that work should be structured. Generation, brainstorming, and discussion prior to officially proposing are out of scope of this document.

First Proposal

Proposals are created as Merge Requests in the proposals repository of the Haskell GitLab. Create a markdown file with an appropriate name, define the proposal as described below, and open an MR when you are ready for comments and review.

Community Notification and RFC

Once the merge request is opened, send a message to the Board mailing list announcing the MR. Post to the Haskell Discourse under the Haskell Foundation topic with the initial text and a link to the MR.

Although proposals may be announced on other social media platforms, these are the only two notifications required.

Review and Commentary

Feedback, commentary, dissent, and change requests are handled in the merge request. Discussions on Discourse and social media platforms are encouraged, however no one working on the proposal is required to read or incorporate feedback outside the merge request itself.

Official Board Vote

Once the proposers are ready they notify the Board, by sending email to the Board mailing list, that the merge request is ready for a final up or down vote. Each member of the Board is added as an approver, and those who vote yes will approve the MR.

Any Board member who votes no should add a comment to the MR with their reservations.

Board Meeting Vote

In some cases the proposals will have legal impacts. During an official Haskell Foundation Board Meeting there will be a vote taken on the record, and tallied in the minutes.

Merger

Once the voting is finished by whichever mechanism, a successful proposal will be merged into the master branch of the repo and will become official.

2 Likes
#2

Thanks for drafting this. A couple of comments:

  • Official Board Vote: what happens with abstentions? Are they counted as «No»?
  • «This process is open to anyone in the community with ideas on how the Haskell Foundation should operate, what work we should undertake, and how that work should be structured.» ← This wording might open the floodgates to “idea guys” with grandiose vision of what Haskell and the Foundation/Community should be but light on contributions/effort.

I am extremely glad you chose gitlab — an open source and community owned space — for this.

GitHub vs GitLab
#3

I have a couple of questions based on this general scenario: Let’s say a new member of our community (having felt some pain) decides they want to share a solution with us (for some of that pain they experienced). They spend a few moments to write up their thoughts to share with the community.

  • We need them to eventually realize they need to share this in a form of a proposal, how do we get them to realize that?
  • At least to a newb’s perspective, there are many seemingly authoritative groups in the Haskell ecosystem, how do they figure out who to send their proposal to?
  • The proposal process can be really challenging for new community members to get through, do you think we can do more to support a contributor and improve the success rate? Doc resources, mentorship/guidance and support, possibly even shepherding proposals?
  • The “ok, you should make a proposal” response can quickly kill a contributor’s spirit (particularly when they believe they are making that proposal), what resources can we provide to help the contributor make a better proposal, and more to the community’s liking/expectations?

I guess my general question is: we can make a process pretty strong, but if newbs don’t find or follow or do the process correctly, the process falls apart in those instances.

I have proposed a governance page on haskell.org to address some of these issues, but even that proposal is stuck b/c IDK what to do to push it to the next step and beyond (other than attempt to write the page myself, to which I respond: Why me? There are probably a dozen people in a fare more informed and far better position to write that content than I).

#4

It might be nice to see if more of the Haskell community infrastructure can be moved to GitLab - so there isn’t as much of a split (pick one or the other platform). I guess at the least we can also write some docs on which groups are on which platform.

1 Like
#5

SPJ made a similar point to your second bullet in the MR, here it is and my reply: https://gitlab.haskell.org/hf/meta/-/merge_requests/11#note_342960

On abstentions: board process requires a minimum set of yes votes, for official votes we will note abstentions specifically, for less format occasions they’re just lack of approval without comment.

1 Like
#6

I definitely agree with the point that it is not clear where to propose different kinds of changes, in this case we are talking about projects the Haskell Foundation is taking on. That means we’re using our time, resources, people, etc. to satisfy the proposal, which may mean then going to another group (like the GHC Steering Committee) and asking for some piece of the overall work.

If someone wants a change to a particular package, tool, etc. then they are likely better off talking to the maintainers specifically. HF projects are normally larger scope or spanning multiple groups, where our ability to help coordinate and facilitate communication can make a big difference.

Does that make sense?

1 Like
#7

We need them to eventually realize they need to share this in a form of a proposal, how do we get them to realize that?

We tell them. :slight_smile: I’ve frequently seen people, say, complaining about some feature of GHC. Maybe this leads to a conversation where we figure out how the feature can be fixed. Then, someone says that it all needs to go into a proposal. Or, in the case where the original post describes a concrete change, that can be the seed of a proposal.

At least to a newb’s perspective, there are many seemingly authoritative groups in the Haskell ecosystem, how do they figure out who to send their proposal to?

This is a great question. The idea has been floated a few times within the HF to have, on our website, some guide to these groups. Maybe a flowchart helping people decide where to post their question/concern? Not sure the best design, but I agree that we need to have some way for people to find their way among all these groups.

  • The proposal process can be really challenging for new community members to get through, do you think we can do more to support a contributor and improve the success rate? Doc resources, mentorship/guidance and support, possibly even shepherding proposals?
  • The “ok, you should make a proposal” response can quickly kill a contributor’s spirit (particularly when they believe they are making that proposal), what resources can we provide to help the contributor make a better proposal, and more to the community’s liking/expectations?

These are harder. The problem is that opening up a proposal process – even without shepherding – gives a way for any community member to demand time from the HF. Of course, this is by design: we want to be in conversation with the broader community. However, it leads to a potential failure mode where there are more proposals than we have the capacity to respond to thoughtfully. My hope (and belief) is that this will all balance out.

However, if we add a promise of offering to shepherd proposals, we are now promising quite a bit more of our attention. Can we uphold this promise? I’m not sure, and I would be reticent to making this promise early on.

It’s true that making a proposal is potentially burdensome, and that some community members will have a hard time doing so. In the GHC proposals process, some contributors who want to grow an idea but don’t have a full proposal ready to share start by making an Issue (not an MR). This could work for HF proposals, too. Then, other community members could help out composing a proposal together. If the idea doesn’t gain traction, however, that proposal might not form; I see this as a feature, not a bug. Not every idea needs to be formed into a proposal, especially if there is not community interest.

Maybe in the future, the HF will have the capacity to shepherd proposals from birth, but my stance is not to commit to that now. Instead, we can outsource this function to the community by directing contributors to making Issues instead of MRs (and then moderating to make sure that comments, etc., are indeed helpful).

3 Likes
#8

I really like the idea of having the lightweight version be opening Issues in the relevant repo (meta for things pertaining to how the Foundation functions, Proposals for either ideas that aren’t that refined yet or problems someone sees with an existing policy).

@rae, can you add that idea as a MR comment?

#9

@rae, can you add that idea as a MR comment?

Done, in https://gitlab.haskell.org/hf/meta/-/merge_requests/11/diffs?commit_id=788c8645113b44ea0579612bf369f6430bb8f75d

#10

I was referring to a variant of that, where an individual has gone out of their way and made an attempt to figure out the right group/person to propose their idea for some change, and they have made an attempt to present that proposal in a reasonable fashion, but ignorant of the group’s expectations, and not even really speaking to the right group
 rather than picking up the torch and helping that change get attention and feedback, telling them to “go make a proposal to those people over there”, ignores the efforts they’ve already invested to speak up as much as they have. I think we sometimes take for granted, how difficult it is to speak up in a public forum of busy and intelligent people.

I am advocating for that type of “chart” or guide to be on haskell.org. It could be on the foundation’s site as well, but I believe it needs to be on haskell.org first and foremost (the foundation also has a problem of competing with https://www.haskellfoundation.org/, which seems kinda wrong). That aside, if there are no objections to starting small, we don’t need to make it complicated, and we could start with a simple list of the organizations, with links, a description, etc. A while back I created https://github.com/haskell-infra/www.haskell.org/issues/60 to start a discussion about that, but it hasn’t gone very far.

#11

I agree that putting this on haskell.org is the right place. I don’t think that would be hard – haskell.org and the HF are quite friendly. So let’s not worry about that aspect right now. Instead, I think a good way to make progress is to start filling out the content of such a page. Even if you (for any value of “you” who is reading this) don’t quite know what the content should be, creating a skeleton that others can fill out is extremely helpful.

A good place to start is in https://github.com/haskellfoundation/haskell.foundation-redux/. Find a place that is a plausible spot for the content and create a new page there. Seek input from the community by posting in a new thread here on Discourse (or elsewhere). Once the page is built out, we can worry about how it fits into the larger picture and how to port it to haskell.org.

2 Likes