A New Proposal Process #10
Conversation
proposals/PROPOSALS.md
Outdated
|
|
||
| - Discuss your idea on the [Haskell.org Discourse](https://discourse.haskell.org/). Currently, we suggest cross-posting on the Haskell Foundation Slack for higher volume commentary. Create a Discourse topic under the category "Haskell Foundation", that starts with "Pre-HIP” and briefly describe what you would like to change and why you think it’s a good idea. | ||
|
|
||
| - Proposing your ideas on the Discourse is not an optional step. For every change to the ecosystem, it is important to engage in Due Diligence with the community and relevant stakeholders. Use this step to promote your idea and gather early feedback on your Pre-HIP proposal. It may happen that experts and community members may have tried something similar in the past and may offer valuable advice. |
There was a problem hiding this comment.
The non-optional nature of this point is questionable. Perhaps this should be an internal HF policy to make sure we don't tread on anyone else's work. In general I don't see a problem with people going straight to submission, though, it may cause more collisions with other people's work than we'd want.
There was a problem hiding this comment.
Firstly, is there any reason why "Due Diligence" is capitalized here?
As far as the non-optionality of this, if the goal is 'eyeballs' and 'not stepping on other toes', you could mandate either Discourse or Slack? I think that gives some more flexibility, especially for people who prefer a more synchronous discussion medium.
There was a problem hiding this comment.
Firstly, is there any reason why "Due Diligence" is capitalized here?
DD is a formal process where I'm from. Must've been a slip.
As far as the non-optionality of this, if the goal is 'eyeballs' and 'not stepping on other toes', you could mandate either Discourse or Slack?
If given the choice, I'd choose Discourse, since that's our stated "place to formally interface with the community". The request that the HF also do this on slack could be taken to the extreme: we could do it on Reddit, Twitter, and the mailing lists too. The point is to get the word out that we're interested by casting as wide a net as possible so as to make sure we don't overlap with any existing projects like we did with #7
There was a problem hiding this comment.
The main reason I felt multiple options would be good is because not everyone is on every platform. To use myself as an example, I'm present on Slack and Twitter and pretty much nowhere else; I'm certain that there are folks who are present on one, and only one, of the options you listed there.
There is some tension here between reach, centralization and convenience; the exact point we want to hit is a little hard to determine.
There was a problem hiding this comment.
For the most part, I think submission is a fine point to sort out DD. Having a public proposals process before work starts is a good opportunity to figure out what related work exists and how it interacts. In some of the cases where there was overlap, I think having had a better proposals process in place with more public discussion would have helped sort that out earlier and better.
Having pre-discussion on the discourse or whatever is however a good idea as well, since that means that there are proposals that aren't solely one person off on their own, but at least have had some initial scrutiny and feedback before they hit the requirements of a Process.
There was a problem hiding this comment.
There is a real tension here: while I respect that everyone has different communication preferences, it is also important for there to be one place with the official record of what is happening. Then, an interested observer can monitor the one place. Having additional places is great -- but not at the expense of the one place. Right now, the one place the HF has designated is Discourse.
Another way to think about this is: Who should be inconvenienced more? The proposal authors or (potential) proposal readers? I think the author should bear the brunt of inconvenience: they are proposing a change that will affect potentially the entire Haskell community. This is not to be taken lightly!
As for @gbaz's point: I agree that a proposal can be a fine place to sort out DD, but I think it's not best for HF-sourced proposals, as those can appear to be in advanced stages by the time they hit this repo. See my proposed dichotomy of Proposals vs RFCs below (#10 (comment)).
There was a problem hiding this comment.
@goldfirere You make an excellent point - from the point of view of inconveniencing the fewest, having a single, designated location is definitely preferable. I guess the main advantage of Discourse is 'maintained searchable history'?
There was a problem hiding this comment.
While maintained searchable history is indeed fantastic, my real desire is more about an assumption of asynchronous communication. Discourse's threading model allows someone to come along several days after an announcement and see what they missed. Slack's is potentially capable of this, too, but it's not used in practice: reactions to a comment are often interleaved with new topics. Twitter similarly doesn't offer the organizational tools to be able to easily catch up if one misses a post. Discourse also has an advantage in that it's an open-source tool that we can control directly, in contrast to the other services.
There was a problem hiding this comment.
💯% agree with @goldfirere here.
proposals/PROPOSALS.md
Outdated
|
|
||
| While the majority of general technical commentary and feedback will occur in the proposals repo, it's hard to tell when a particular proposal is finalized. This what we call "Formal Evaluation". | ||
|
|
||
| Formal Evaluation of a proposal is done in iterations. The maximum number of iterations is five. These iterations take place in the HF Tech Track meetings and are usually monthly. However, they can last longer, in which case the author has more time to implement all the required changes. |
There was a problem hiding this comment.
HF tech track meetings are weekly, however, we may want to add a meeting series specifically for HIP review. The language will change as we decide what to do here.
proposals/PROPOSALS.md
Outdated
|
|
||
| - Discuss your idea on the [Haskell.org Discourse](https://discourse.haskell.org/). Currently, we suggest cross-posting on the Haskell Foundation Slack for higher volume commentary. Create a Discourse topic under the category "Haskell Foundation", that starts with "Pre-HIP” and briefly describe what you would like to change and why you think it’s a good idea. | ||
|
|
||
| - Proposing your ideas on the Discourse is not an optional step. For every change to the ecosystem, it is important to engage in Due Diligence with the community and relevant stakeholders. Use this step to promote your idea and gather early feedback on your Pre-HIP proposal. It may happen that experts and community members may have tried something similar in the past and may offer valuable advice. |
There was a problem hiding this comment.
Firstly, is there any reason why "Due Diligence" is capitalized here?
As far as the non-optionality of this, if the goal is 'eyeballs' and 'not stepping on other toes', you could mandate either Discourse or Slack? I think that gives some more flexibility, especially for people who prefer a more synchronous discussion medium.
proposals/PROPOSALS.md
Outdated
|
|
||
| * Submit a Pre-HIP topic to the HF Discourse, soliciting informal feedback. | ||
| * If the feedback is favorable, fork the Haskell Foundation tech-proposals repository, [https://github.com/haskellfoundation/tech-proposals](https://github.com/haskellfoundation/tech-proposals). | ||
| * Create a new HIP file in the `hips/` directory. Use the [HIP template](https://github.com/haskellfoundation/tech-proposals/blob/main/TEMPLATE.md) |
There was a problem hiding this comment.
Perhaps add a link back to the PROPOSALS file in the first paragraph of this template? (before the introduction)?
Co-authored-by: Sebastiaan Joosten <[email protected]>
Co-authored-by: Sebastiaan Joosten <[email protected]>
Co-authored-by: Sebastiaan Joosten <[email protected]>
Co-authored-by: Sebastiaan Joosten <[email protected]>
…ion/tech-proposals into feat/new-proposal-process
|
@sjcjoosten Your feedback is extremely welcome and detailed! Thanks. Let's continue iterating 😄 |
Co-authored-by: Alexey Kuleshevich <[email protected]>
|
I've thought more about this process, and I think we have conflated several different goals here. Separating them out may clarify how to do this best.
Though related, (1) and (2) are different. Ideas under (2) would likely be more developed than ideas under (1), and we'd have a better idea of who might perform the work. In addition, it is easier for ideas under (2) to seem like they are pre-decided, and that we are posting only to alert the community of something we've already decided on. Because of this threat on (2), I've advocated that we always pre-post on Discourse before posting here. But this need is much less for (1): an author is probably well-advised to be aware of prior work, stakeholders, etc., but I don't see this as a requirement we need to impose on them. (It is a requirement for us to be informed about such issues before, say, accepting a proposal.) So I propose this structure: A. Every PR here is either a Proposal or a Request For Comments (RFC). The former come from non-HF entities (I say "entity" to include, say, companies), while the latter come from the HF itself. (An HF person can still write a Proposal, but they are acting as an individual and not in their HF capacity. When/if this happens, this fact must be made abundantly clear.) A Proposal thus introduces a fresh idea, while an RFC circulates an idea that already has some currency within the HF. B. Every PR includes an indication of how committed the HF already is to the idea. Proposals naturally start with no commitment, and won't receive that commitment until the end of the process. RFCs start in a variety of states. We might have an idea we're sure we want to pursue, in some form, but the details want input from the community. Or we might have an idea that we're less sure about and want to gauge the community's opinion. As an example, we're pretty sure we want to produce resources to help Haskellers make their programs run faster. But the precise form (book? wiki? who edits it? etc.) is still being considered. And so, with our support, @soupi made #9 to gather wider input and refine the idea. On the other hand, there may be an idea that we think would be interesting but we're unsure of. Being explicit about where the HF sits will help frame the conversation and prevent surprise. What do we think about this? |
proposals/PROPOSALS.md
Outdated
|
|
||
| ## Why Write a Proposal? | ||
|
|
||
| HIPs are key to making the HF and its initiatives better for the good of everyone. If you decide to invest the time and effort of putting a proposal forward and see it through, your efforts and time will shape and improve the Haskell ecosystem, which means that your proposal may impact the life of a myriad of developers all over the world, including those on your own team. For many, this aspect alone can be quite worthwhile. |
There was a problem hiding this comment.
This section describes the benefits (and dangers) to the person writing the proposal, but it does not describe any benefits to the wider community. Maybe add a few sentences about how a proposal gives us all a place to concretize our ideas and then form guidance during implementation?
proposals/PROPOSALS.md
Outdated
|
|
||
| ### Initial Discussion | ||
|
|
||
| Before submitting a HIP, it is required that you perform necessary preparations: |
There was a problem hiding this comment.
In keeping with my Proposal/RFC dichotomy above (#10 (comment)) I think this step is required only for RFCs, not Proposals.
proposals/PROPOSALS.md
Outdated
|
|
||
| - Discuss your idea on the [Haskell.org Discourse](https://discourse.haskell.org/). Currently, we suggest cross-posting on the Haskell Foundation Slack for higher volume commentary. Create a Discourse topic under the category "Haskell Foundation", that starts with "Pre-HIP” and briefly describe what you would like to change and why you think it’s a good idea. | ||
|
|
||
| - Proposing your ideas on the Discourse is not an optional step. For every change to the ecosystem, it is important to engage in Due Diligence with the community and relevant stakeholders. Use this step to promote your idea and gather early feedback on your Pre-HIP proposal. It may happen that experts and community members may have tried something similar in the past and may offer valuable advice. |
There was a problem hiding this comment.
There is a real tension here: while I respect that everyone has different communication preferences, it is also important for there to be one place with the official record of what is happening. Then, an interested observer can monitor the one place. Having additional places is great -- but not at the expense of the one place. Right now, the one place the HF has designated is Discourse.
Another way to think about this is: Who should be inconvenienced more? The proposal authors or (potential) proposal readers? I think the author should bear the brunt of inconvenience: they are proposing a change that will affect potentially the entire Haskell community. This is not to be taken lightly!
As for @gbaz's point: I agree that a proposal can be a fine place to sort out DD, but I think it's not best for HF-sourced proposals, as those can appear to be in advanced stages by the time they hit this repo. See my proposed dichotomy of Proposals vs RFCs below (#10 (comment)).
| ### Submission | ||
|
|
||
| A HIP is a Markdown document written in conformance with the [process template](https://github.com/haskellfoundation/tech-proposals/blob/main/TEMPLATE.md). When such changes significantly alter an existing library or tool, the author is invited to provide a proof of concept. Delivering a basic implementation can speed up the process dramatically. If your changes are big or somewhat controversial, don’t let people hypothesize about them and show results upfront. | ||
|
|
There was a problem hiding this comment.
Maybe add some text saying that the proposer should ideally reach out to the authors of the library/tool first? If I, say, want cabal to support Stackage directly and proposed this here first, it may come as a surprise to the cabal developers -- making broad acceptance of the plan less likely. So it's probably best to start with individuals and involve the HF only when there seems to be a need for larger coordination.
Exception: when the HF itself wants to achieve a certain goal, we will reach out to library/tool maintainers first but eventually surface an RFC here.
There was a problem hiding this comment.
I like that idea - it makes sense for the example you give
proposals/PROPOSALS.md
Outdated
|
|
||
| #### Involving Stakeholders | ||
|
|
||
| At this point where a propsal is being reviewed, if there are relevant stakeholders from industry or in the community (e.g. library authors and maintainers who are affected), they should be solicited for comment and brought into the discussion. Remember, proposals may sound good, but it's best to iron out as many details as possible prior to their acceptance. This means that any hesitations stakeholders have with the project should be factored into the proposal's details. |
There was a problem hiding this comment.
Who is responsible for this step? Should proposal authors reach out? Or should someone from the HFTT? My take: authors should do this, and it's up to the HFTT to ensure that it's been done. Members of the HFTT can help the authors identify and reach stakeholders if that would be helpful.
proposals/PROPOSALS.md
Outdated
|
|
||
| #### Updating Proposal Statuses | ||
|
|
||
| If the author of a particular proposal wants to update the status of their proposal, they should either comment on the issue and tag an HF Technical Track member with a note regarding what status they would like to update the proposal to. It is good to be redundant and raise the question in our other fora as well: Slack and Discourse. However, Github should be the first choice. |
There was a problem hiding this comment.
"tag an HFTT member"
Which one? I'm trying to think of myself as an author, and this instruction seems confusing, requiring me to look up the HFTT membership, track down their GitHub names, and then arbitrarily choose one, hoping not to offend anyone. We should either designate an individual (essentially: the HFTT secretary) or have some sort of group tag (does GitHub even have this?).
"GitHub should be the first choice": This, to me, implies that an author who dislikes GitHub may choose to just make a small comment on Slack. That comment might get missed, and then the author gets frustrated. I think we should clarify that all official requests for action on a proposal take place through GitHub.
There was a problem hiding this comment.
Github does have group tags (ala @haskellfoundation/tech-proposals), which requires adding HFTT members to a team on this repo. This is easy to do, and I would prefer this as opposed to adding a new role.
proposals/PROPOSALS.md
Outdated
|
|
||
| ### Formal presentation | ||
|
|
||
| After a proposal is merged, the author will present KPI's and deliverables that define the proposal to the HF Technical track. During the next available Technical Track meeting after acceptance, the author or designated lead (as defined by the proposal) should give a short 5-10min presentation consisting of the following: |
There was a problem hiding this comment.
What is a KPI? I really don't know.
This step seems surprising to me. During the whole deliberation process, it seems that the author is not generally invited to present their case. And then after the proposal is accepted, they can? I'm not sure I see the logic here.
There was a problem hiding this comment.
I too am a bit surprised. I'm inclined to suggest that this document ends with acceptance. Then there is some separate process by which the HF board, led by its ED and CTO have to prioritise resources, choose initiatives, etc. That may or may not involve project presentations, but it'll involve a lot else. But it's beyond the scope of this document.
This links with my remarks below about the distinction between acceptance and execution.
There was a problem hiding this comment.
What is a KPI
Key Performance Indicators - it's a term used in project management in Agile settings.
Suprising
The logic here is that the accepted proposal represents the finalized proposal state, while the presentation gives the authors a chance to present the finalized proposal to the track as a kind of "first standup". The HFTT gets to meet the representative who will be giving future updates, as well as give the broader HFTT (who may all not have seen the proposal) the chance to see the finished product. Of course there are questions here: is this necessary? Perhaps not. I may have gone beyond the scope here.
It sounds like we want to strike this from the process, which is fine.
There was a problem hiding this comment.
Yes, I tend to think that this is beyond the process. That is, once we agree to pursue a project, the proposals process is complete. It's quite reasonable for the HFTT to both oversee the proposal process and the implementation process, but the meeting described here sounds like part of the implementation process. In my opinion, there's not as much of a need to codify implementation processes, as there will be big differences between e.g. volunteer work and work that the HF pays for.
However, there is still an open question: is there an opportunity for proposal authors to make their case live to the HFTT? Maybe this step is optional, but if so, who decides whether authors get to present? Does the HFTT invite them based on their interest? Does the author decide they wish to attend in person? I tend to think it's fairest if we give proposers the opportunity to make their case to us -- all the more so because I suspect that HFTT members will sometimes also be authors, and naturally HFTT members will advocate for their proposals in meetings.
proposals/PROPOSALS.md
Outdated
| 3. **Resources:** What resources are required in order to take the project from start to completion. | ||
| 4. **Contact:** Who is going to update the HF Technical Track members, and on what schedule. | ||
|
|
||
| Once the formal presentation is given, the HF Technical Track members will track the progress over time at our ongoing meetings. This also gives the track members time to introduce themselves and and we can all get to know each other. Currently, HF Technical Track meetings are held weekly on Tuesdays at 11:30am-12:30pm UTC-5 (EST). |
There was a problem hiding this comment.
"This also gives the track members time to introduce themselves and and we can all get to know each other." I don't see how this sentence relates to the rest of the paragraph.
It's true that current meetings are 11:30-12:30 EST, but that's a bit confusing: no place on earth is in the EST time zone at the moment (we're in EDT for summer). Will this timeslot stay the same after daylight saving time ends? Will we remember to update this when changing the schedule? Instead, I think we should have an HFTT home page of sorts (maybe the README to this repo? Maybe haskell.foundation/projects?) that lists the current status of the HFTT, including membership, meeting times, and how to join. Then, we just refer to that page from here.
| 4. **Contact:** Who is going to update the HF Technical Track members, and on what schedule. | ||
|
|
||
| Once the formal presentation is given, the HF Technical Track members will track the progress over time at our ongoing meetings. This also gives the track members time to introduce themselves and and we can all get to know each other. Currently, HF Technical Track meetings are held weekly on Tuesdays at 11:30am-12:30pm UTC-5 (EST). | ||
|
|
There was a problem hiding this comment.
I've been expecting to see a notion of shepherd here somewhere. That is, for each proposal, there should be an individual who feels responsible for keeping it in line. Maybe this is always you, @emilypi, for every proposal. But I think having responsible individuals, instead of a responsible committee, is more likely to lead to forward action.
proposals/PROPOSALS.md
Outdated
| - weighing in pros and cons of every proposal | ||
| - accepting, postponing or rejecting the proposal. | ||
|
|
||
| HF Technical Track members should be either individuals responsible for a specific part of the Haskell ecosystem, or contributors and committers to parts of it. The members are selected by the HF CTO based on their expertise and implication in the community. |
There was a problem hiding this comment.
Did you mean "implication"? Perhaps "reputation" would be better?
I may have complained about this previously, but I'm now OK with you, @emilypi, unilaterally selecting the HFTT. We serve at your pleasure. But I do think there should be a process by which a community member can apply to join. Having open applications works against a situation where you choose only people close to you -- not because of bias, but because those are the people you're aware of.
Is this list of people up-to-date? Some names here are not regular attendees of our meetings and may be surprised to be listed. Best to double-check with everyone. (I explicitly agree to serve.)
There was a problem hiding this comment.
Did you mean "implication"? Perhaps "reputation" would be better?
In a sense, implication is both the correct word and too strong a word here. We don't want the HFTT to be composed exclusively of Haskell titans, which sets the bar extremely high and gives the wrong impression. I'd be perfectly fine with having enthusiastically dedicated students, as well as representatives from industry, in addition to those big Haskell names. But implication sounds a bit... political. Here, we'd want to say something broader, like taking a sample of the community.
(I explicitly agree to serve.)
Glad to have you on board 🎉
| - Theophile Choutri ([@Kleidukos](https://github.com/Kleidukos)), Scrive | ||
| - Gil Mizrahi (@soupi) | ||
|
|
||
| ### Voting |
There was a problem hiding this comment.
If you, @emilypi, unilaterally select the HFTT, then having these rules around voting seem unenforceable: you could always kick someone off the HFTT just during a vote and then reinstate them. So I think it simplifies matters considerably to make the HFTT a labor-producing and advisory body. We can vote, but our vote is a recommendation to you, who makes the decisions.
There was a problem hiding this comment.
make the HFTT a labor-producing and advisory body.
I think this idea is in line with what we want as a foundation. How should we codify this into language (and where)?
proposals/PROPOSALS.md
Outdated
| * Use the [Markdown Syntax](http://daringfireball.net/projects/markdown/syntax) to write your HIP. | ||
| * Commit your changes to your forked repository | ||
| * Create a new [pull request](https://github.com/haskellfoundation/tech-proposals/pull/new). | ||
| * Notify the Haskell HIP team on the Slack instance or on Discourse (or both!). |
There was a problem hiding this comment.
Is this last step necessary? I would expect GitHub to do this notification.
There was a problem hiding this comment.
I agree that GitHub should, but I also really like this step. It's a fallback in case someone erroneously forked a fork of this repo and sent the pull request there instead. It also establishes an extra line of communication to the author. You may not know their slack/discourse/email name otherwise. Good for comments like 'awesome proposal', or 'I got the impression that what you were discussing in Discourse was a different proposal?' or 'I don't think I understand any of this small-step semantics stuff, we may need to wait for goldfirere to get back from his trip so we can make sense of it'.
I dislike the Proposal/RFC distinction being suggested here. I think it is a response to a very real problem, but instead of tackling the problem head-on, it codifies the problem. The problem that came up is that there were proposals that made it very far without "sunlight" and so interested parties were not informed, there was no opportunity for others to introduce prior or related work, etc. The proposal/RFC split seems to say "ok, for those proposals that went on too long without sunlight (which we approximate by those that are HF originated), we'll now have stricter rules around them." This whole thing is patching the symptom, not the problem! The root cause fix is to not have proposals discussed for a long time strictly within the HF -- instead get them out in the open and talk them around the way any average person not in HF meetings would! Then, the distinction can disappear again :-) There's no set of rules for process that can fix what was at root an organizational problem in the first round of proposals the HF was brokering. But by codifying the process, then HFers can just try to follow it early and often, and ideally by the same considerations and approaches that anyone else would. I.e., from a social standpoint, it is better that everyone see proposals from HFers and non-HFers alike on an even footing, rather than with different distinguished statuses. Compare to the ghc proposals process -- would you want proposals from GHCHQ to be given a special "RFC" status as well? As much as marking these as needing special procedures, wouldn't you worry it might also distinguish them too much as a fait accompli? |
I'm rather with Gershom here. The "proposal" vs "RFC" distinction is bit of a distinction without a difference -- or at least, without a difference that we want to codify/institutionalise. These days, if I want to make a change to GHC, I really do have to write a GHC Proposal. Since, I'm on the GHC Steering Committee you might way that it's not really a level playing field, but it nevertheless exposes my idea to the scrutiny of the community using the same process as applies to any proposal; and in practice the committee is very even handed. So the process at least expresses the clear intent that a proposal should be considered on its merits, not on its source. Colour me "yet to be convinced" that it would be helpful to make a distinction. |
proposals/PROPOSALS.md
Outdated
|
|
||
| ### Formal Review (up to 5 iterations) | ||
|
|
||
| While the majority of general technical commentary and feedback will occur in the proposals repo, it's hard to tell when a particular proposal is finalized. This what we call "Formal Review". |
There was a problem hiding this comment.
I'm not quite sure what this paragraph means. Here's a rephrasing that, I believe, captures your intent. But I'm not sure
The entire community is strongly encouraged to comment on, and help improve, a proposal. Ultimately, however, the Foundation needs a mechanism to make a decision, to accept, reject, or push back a proposal. This process is called "Formal Review", and is carried out by the HF Tech Track working group.
There was a problem hiding this comment.
Given the importance of the Tech Track group, it would be good to give a link to where readers can find out what the group does, who the members are, how to become a member, etc.
There was a problem hiding this comment.
Good idea. I suppose these would now go hand in hand, where before we were a working group.
proposals/PROPOSALS.md
Outdated
|
|
||
| ### Formal presentation | ||
|
|
||
| After a proposal is merged, the author will present KPI's and deliverables that define the proposal to the HF Technical track. During the next available Technical Track meeting after acceptance, the author or designated lead (as defined by the proposal) should give a short 5-10min presentation consisting of the following: |
There was a problem hiding this comment.
I too am a bit surprised. I'm inclined to suggest that this document ends with acceptance. Then there is some separate process by which the HF board, led by its ED and CTO have to prioritise resources, choose initiatives, etc. That may or may not involve project presentations, but it'll involve a lot else. But it's beyond the scope of this document.
This links with my remarks below about the distinction between acceptance and execution.
proposals/PROPOSALS.md
Outdated
|
|
||
| ## Proposal states | ||
|
|
||
| The state of a proposal changes over time depending on the phase of the process and the decisions taken by the HF Technical Track. A given proposal can be in one of several states: |
There was a problem hiding this comment.
A flow diagram would be quite useful here.
proposals/PROPOSALS.md
Outdated
|
|
||
| Authors are responsible for building consensus within the community and documenting dissenting opinions before the HIP is officially discussed by the HIP HF Technical Track . Their goal is to convince the HF Technical Track that their proposal is useful and addresses pertinent problems in the Haskell ecosystem as well as interactions with already existing features. Authors can change over the life-cycle of the HIP. | ||
|
|
||
| ### The HF Technical Track |
There was a problem hiding this comment.
Don't we need a different document that describes, for the Tech Track working group
- Purpose
- Membership
- How to become a member, membership terms etc
etc? Does that really belong here? If reviewing HIPs is the sole purpose of the Tech Track wg then maybe yes it belongs here (in which case we need to say more, so it's a complete description of the working group). But I suspect it has some broader roles and deserves its own document.
There was a problem hiding this comment.
I agree. I think there should be a separate document that describes the HFTT and this document should just call out to it as an abstract function. If we kept this section and the HFTT operating principles were to be described somewhere else as well then this document could be in conflict with them. I think it only makes sense to describe the HFTT here if its only purpose is and will ever be the one described in this document.
proposals/PROPOSALS.md
Outdated
|
|
||
| ### The HIP Authors | ||
|
|
||
| Authors are responsible for building consensus within the community and documenting dissenting opinions before the HIP is officially discussed by the HIP HF Technical Track . Their goal is to convince the HF Technical Track that their proposal is useful and addresses pertinent problems in the Haskell ecosystem as well as interactions with already existing features. Authors can change over the life-cycle of the HIP. |
There was a problem hiding this comment.
If the decision making body is the Tech Track working group, then I assume HIPs are intended to be primarily technical. What about proposals that are more social than technical, e.g. "We should run an annual conference" or "HF should affiliate to group X"?
Rather than try to be comprehensive, I suggest restricting this process to stuff within the scope of the Tech Track task force -- and try to write down what that scope is. (In a word "technical".)
|
The arguments against my Proposal vs RFC are good ones, but I think there are difference between the HF and the GHCSC (GHC Steering Committee, which evaluates GHC proposals):
While @gbaz describes an ideal where all our nascent ideas are put into proposal form very early, I don't think that will happen in practice. Put another way: it would be great if our internal proposals really do hit the repo in the same form as outside proposals -- but I don't think that's the case. And I'd rather codify the difference than to pretend it doesn't exist -- even if I wish the difference didn't exist. (I'm reminded of the all-too-frequent meetings I attended as a secondary school teacher where the administration would bring up a potential idea -- perhaps a change in graduation requirements -- for community discussion and input. Many of these, it was clear in retrospect, were already decided behind closed doors and the presentation was merely stated as a discussion to make an idea seem more palatable. I don't wish the HF to echo this behavior.) Maybe calling one a Proposal and the other an RFC (making them Different Things) is a step too far. A smaller step would be to have a section of the proposal that describes the HF's current level of interest in a proposal. Outside proposals would have no a-priori interest, while internal ones would have such an interest, ranging from "exploratory idea -- is this crazy talk?" to "we think this is a good idea" to "we're definitely going to invest resources, but want the public to help with the design" to "we know exactly what we want, but our written process requires this bureaucratic step" (let's avoid that last one!). |
Co-authored-by: Richard Eisenberg <[email protected]>
I tend to agree with Gershom here, and we can spell this out in more detail. The "Why Write a Proposal" section details the motivations here. I also don't think it's particularly useful to go into extreme detail with justifying why the process exists. I believe the "Why Write" section actually details this quite cleanly, and the rest of the process details answer the line of questioning as to whether 1-4 are the correct interpretation: it's up to the proposal.
I don't think these are necessarily relevant to the people writing a proposal. This seems more like an internal statement of purpose. "What are we trying to do with this process", and "why does each step exist" are too meta to include in a document like this. The process gets us the three things you list, by construction. We reach (or hope to reach) the full range of stakeholders by requiring a socialization step. We gain input from people with expertise by pulling them into the review process. We take into account pre-existing work by requiring the socialization process and leaving the review process open to the public etc. Whether or not someone writing a proposal should care about this needs to be justified before it's included in the document, and we need to keep in mind that we do not want to introduce hurdles that foist too much burden on proposal authors.
|
There was a problem hiding this comment.
Left a couple of comments, I think it is important to mention explicitly:
- What the HF's role in executing the proposal is and what kind of support should the author expect
- What is the time frame for a proposal
- Who can create a proposal, maybe this should be a section below "why write a proposal"
proposals/PROPOSALS.md
Outdated
| @@ -0,0 +1,146 @@ | |||
| An HFTP (*Haskell Foundation Technical Proposal*) is a process for submitting a proposal for a technical initiative to be undertaken by the Haskell Foundation (HF). This document describes how the community may propose, discuss, and implement technical initiatives to be carried out through the Haskell Foundation that will affect the Haskell ecosystem. Each HFTP goes through an iterative process in which it is discussed by the HF Technical Track (HFTT), the broader community, and any and all interested stakeholders. If a consensus is reached, the initiative is accepted and may then be executed by the Foundation (resources permitting). Only upon reaching a consensus are initiatives accepted to be merged and executed. | |||
There was a problem hiding this comment.
What does "undertaken by the Haskell Foundation" mean? Are HF members going to execute the proposal once it is accepted? Or will the HF support the proposal's author in executing the proposal? It's important to clarify HF's role here.
| 2. **Implementation guidance:** the myriad of subject matter experts and stakeholders affected by a proposal can comment in a centralized place to form a consensus and guide the implementation strategy for a particular task. | ||
| 3. **Resource requirements:** ideas are often discussed in the abstract, without the consideration for the cost of work required for their implementation. This process allows for discussion that reifies the resource requirements for proposals, and allows the community to more accurately weigh the cost and benefits of an implementation. | ||
|
|
||
| It's important to note that seeing a proposal through to its conclusion is an involved task. On the one hand, it takes time to convince people that your suggestions are a worthwhile change for hundreds of thousands of developers to accept. Particularly given the sheer volume of developers that could be affected by a proposal, its acceptance is conservative and carefully thought through. Typically, this includes many rounds of discussion with HF leaders, Haskell library maintainers, and the broader community, several iterations on the design of the proposal, and some effort at prototyping the proposed change. Often, it takes weeks to months of discussion, re-design, and prototyping for a proposal to be accepted. It is therefore important to note that seeing a proposal through to its conclusion can be time-consuming and not all proposals may end up accepted, although they may teach us all something! |
There was a problem hiding this comment.
Maybe add here how long (roughly) the proposal process take? (I think this is covered in "Formal Review" and the answer is roughly 6 months at most?)
|
Ah, thanks @gbaz and @emilypi, I see that I was the one making a scope error. This PR is for explaining to the public how the public-facing parts of this process work. In that case I have no objection. On the other hand I am concerned that if we do not flesh out the purpose and principles as explained in my comment in parallel (not necessarily as part of this PR, but perhaps somewhere else) then we risk getting confused about what this process is actually for and what different parties can reasonably expect of it. |
|
To be honest, I'm quite indifferent to minute details of proposal lifecycle. From my perspective, it would be fine to say "The proposal is approved by benevolent dictatorship of HF CTO and ratified by HF Board", and everything else is implementation details, if I may say. What I care more is a bigger picture. What is in scope for this proposal process? There are multiple proposal processes for technical initiatives in Haskell ecosystem, how is this one different or related with others? Why should someone seek HF approval? How could someone expect to benefit from it? What kind of support is potentially available? As an insider I know some answers, but for outsiders it is a complete mystery. I believe this should be clearly covered in the very first section, ideally with examples. |
|
For me, the important part that I would want extracted from @tomjaguarpaw's post is that this document should make very clear what reasonable expectations of outside users (e.g. proposers and commenters) is. Examples:
I'm sure we can come up with others. This addresses @tomjaguarpaw's "purpose" points, but without necessarily pinning down what the HF can and cannot do. As one particular example of expectation: I've been expecting that all projects at https://haskell.foundation/projects/ would have corresponding proposals here. Maybe that expectation is wrong -- but I would want a written statement of, say, what the relationship is between this repo and that page. One other, related mistake I may have made is to conflate "design document" with "proposal". I feel very strongly that every project at https://haskell.foundation/projects/ should have a written design document (where we can have stated goals of the project and means by which to reach those goals), but maybe not every project needs a proposal (in case @emilypi e.g. just chooses for the HF to pursue a certain goal). There's wiggle room here -- but I want us to know where we stand and what we should expect going forward, and to have this written down. (Any policy, also, is welcome to have exceptions in practice, but ideally each exception would have a written rationale as to why it's an exception to the rule.) Separately, I wholeheartedly agree with @Bodigrim's suggestion for defining clearly what kinds of proposals should end up here. Why would someone make an HF proposal, instead of (say) a GHC proposal or a CLC proposal? It might be nice even to have a flow chart to help a contributor decide where they should take their idea. To me, HF proposals are most appropriate for ideas that cross-cut several different projects in the Haskell ecosystem. As such, the text-utf8 proposal may actually be a poor exemplar: why is that here and not on the text repo? (I really don't know the answer to that question.) Another perhaps good reason for HF involvement is when the project is new but will broadly help the Haskell ecosystem (this is like the matchmaker project). In any case, knowing where this process fits in more broadly is very helpful, both to outside contributors and insiders. |
|
Related discussion: https://discourse.haskell.org/t/proposing-haskell-foundation-community-grants/3049 We may want to make sure that this process covers neatly the "Here's what we want to do, we also want to implement it, but also we could use modest funding to support ourselves doing this" case -- especially covering "bridge" or "push goal" funding of existing projects. |
|
Thanks for these revisions! I particularly like the introductory matter, which does a nice job of getting a potential author excited about writing a proposal. My one big remaining question is about the relationship between this process and https://haskell.foundation/projects/. Should I expect all projects on that page to include an accepted proposal here? Should I expect all accepted proposals here to be on that page? I don't think the current text specifies this, but I think being explicit about this relationship will help set everyone's expectations going forward. |
|
@goldfirere Good question. I think that every accepted proposal should have a project page listed the projects page of the website. We want to publicize both the involvement of the individuals on the site, as well as provide contact information for people who want to help out on those projects. This is a convention I think we should follow (e.g. https://scala.epfl.ch/projects.html). |
Great. I agree! What about the converse? Should every project listed on the website have an accepted proposal? Regardless of the answers, I think this relationship should be documented both in this repo and on the projects page. |
|
I'd advocate for not retroactively writing proposals for projects listed on the projects page, and just have them submit a proposal. I believe most are in the ideation phase as is, and the ones that are in flight have an associated proposal either in PR or merged |
|
That said, I've gotten the go-ahead to merge. Thanks everyone for reviewing, and for all additional wibbles, let's take the discussion to the issues list or the discourse. |
The addition of this document is to define the technical proposal process in complete detail, and refine the existing processes for everyone's benefit. As such, I welcome any and all feedback.
Rendered version of the proposal