GHC proposal process: merging and closing

Spiwack, Arnaud

23 Feb 2018 23 Feb '18

9:08 a.m.

Dear all, Joachim directed me here to raise some remarks about the proposal process that I've brought up. Out of the hundred or so submitted proposals, only roughly half were closed, including a mere 11 merged. On the merging end, I noticed, in particular that the backpack proposal[1] has not been merged. The reason being that it had been implemented before the committee had time to evaluate it, hence became out of scope. Why do we merge proposals? One reason proposal can be referred to by pull requests authors to describe the changes that they're implementing. The other reason that I can see is that proposals can serve as documentation: they can be referred to inside the documentation to explain why things are done the way they are, they can be browsed by curious onlookers who want to understand the trade-offs that went into this particular design, we could even consider linking to them in the manual as longer-form stand-alone pieces of documentation for individual features.

...

From that point of view the backpack proposal ought to have been merged: it is still documentation after the implementation is finished. Irrespective of whether the committee has had to work for it.

On the "closing" side, I think we should be better at triaging. It's less important, of course, because forgotten PRs fall behind are not seen by anybody. But it could help give a valuable feeling of tidiness. I believe a tidy repo makes people feel more at ease with sharing their thoughts. And, just as importantly, it would help Joachim to manage the proposals: with 40+ open proposals, you probably don't know which are active, which need a push, where he could suggest that the committee get involved. If there were only 15 proposals to track, Joachim's time would be more efficiently spent. I don't believe we should hesitate to close a proposal which is not under discussion any more, authors can still reopen when they want to get back to discussing the matter. There are quite a few dormant proposals, also out-of-scope which didn't receive any conversation of late, or need-revision which don't seem to be seeing any update. These could all be closed. What does everybody think? [1] https://github.com/ghc-proposals/ghc-proposals/pull/5 Best, Arnaud Spiwack

Attachments:

attachment.html (text/html — 2.5 KB)

Show replies by date

Simon Marlow

23 Feb 23 Feb

9:24 a.m.

New subject: GHC proposal process: merging and closing

Both points make a lot of sense to me. Cheers Simon On 23 February 2018 at 14:08, Spiwack, Arnaud wrote:

...

Dear all,

Joachim directed me here to raise some remarks about the proposal process that I've brought up.

Out of the hundred or so submitted proposals, only roughly half were closed, including a mere 11 merged.

On the merging end, I noticed, in particular that the backpack proposal[1] has not been merged. The reason being that it had been implemented before the committee had time to evaluate it, hence became out of scope.

Why do we merge proposals? One reason proposal can be referred to by pull requests authors to describe the changes that they're implementing. The other reason that I can see is that proposals can serve as documentation: they can be referred to inside the documentation to explain why things are done the way they are, they can be browsed by curious onlookers who want to understand the trade-offs that went into this particular design, we could even consider linking to them in the manual as longer-form stand-alone pieces of documentation for individual features.

From that point of view the backpack proposal ought to have been merged: it is still documentation after the implementation is finished. Irrespective of whether the committee has had to work for it.

On the "closing" side, I think we should be better at triaging. It's less important, of course, because forgotten PRs fall behind are not seen by anybody. But it could help give a valuable feeling of tidiness. I believe a tidy repo makes people feel more at ease with sharing their thoughts. And, just as importantly, it would help Joachim to manage the proposals: with 40+ open proposals, you probably don't know which are active, which need a push, where he could suggest that the committee get involved. If there were only 15 proposals to track, Joachim's time would be more efficiently spent.

I don't believe we should hesitate to close a proposal which is not under discussion any more, authors can still reopen when they want to get back to discussing the matter. There are quite a few dormant proposals, also out-of-scope which didn't receive any conversation of late, or need-revision which don't seem to be seeing any update. These could all be closed.

What does everybody think?

[1] https://github.com/ghc-proposals/ghc-proposals/pull/5

Best, Arnaud Spiwack

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

9:36 a.m.

Hi Arnaud, thanks for raising this; let me lay out the reasons for doing it the current way (which is intentional, but not unchangeable): * Merging unapproved, but implemented proposals. This would mean that there would be some proposals in the directory https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals that were not vetted, discussed and approved. Is that desirable? It seems it would water down the status of the rest. About documentation: The proposal can still be linked, during its implementation. Are you worried that the pull request will be lost somehow? You also write that the manual should link proposals (I guess that applies to all proposals). I don’t think we would be doing our users a favor here; they expect and deserve a comprehensive and self- contained manual. * Closing: We briefly had this discussion a while ago. The rationale to not close tickets that were not officially rejected is because contributor motivation is a scarce resource, and me just going around closing people’s proposals just because they are not able to press forward a lot. I am nudging stagnant proposals, and eventually mark them as “dormant”, as a more friendly way of closing them. Many authors then close them voluntarily when they have abandoned it. Note that the overview at https://github.com/ghc-proposals/ghc-proposals links to “≡ List of proposals under discussion” which includes only the somewhat active propsoals. Maybe I can close dormant porposals when nothing has happened in $n$ months, with a friendly message that it can be re-opend any time. Cheers, Joachim Am Freitag, den 23.02.2018, 15:08 +0100 schrieb Spiwack, Arnaud:

...

Dear all,

Joachim directed me here to raise some remarks about the proposal process that I've brought up.

Out of the hundred or so submitted proposals, only roughly half were closed, including a mere 11 merged.

On the merging end, I noticed, in particular that the backpack proposal[1] has not been merged. The reason being that it had been implemented before the committee had time to evaluate it, hence became out of scope.

Why do we merge proposals? One reason proposal can be referred to by pull requests authors to describe the changes that they're implementing. The other reason that I can see is that proposals can serve as documentation: they can be referred to inside the documentation to explain why things are done the way they are, they can be browsed by curious onlookers who want to understand the trade-offs that went into this particular design, we could even consider linking to them in the manual as longer-form stand-alone pieces of documentation for individual features.

From that point of view the backpack proposal ought to have been merged: it is still documentation after the implementation is finished. Irrespective of whether the committee has had to work for it.

On the "closing" side, I think we should be better at triaging. It's less important, of course, because forgotten PRs fall behind are not seen by anybody. But it could help give a valuable feeling of tidiness. I believe a tidy repo makes people feel more at ease with sharing their thoughts. And, just as importantly, it would help Joachim to manage the proposals: with 40+ open proposals, you probably don't know which are active, which need a push, where he could suggest that the committee get involved. If there were only 15 proposals to track, Joachim's time would be more efficiently spent.

I don't believe we should hesitate to close a proposal which is not under discussion any more, authors can still reopen when they want to get back to discussing the matter. There are quite a few dormant proposals, also out-of-scope which didn't receive any conversation of late, or need-revision which don't seem to be seeing any update. These could all be closed.

What does everybody think?

[1] https://github.com/ghc-proposals/ghc-proposals/pull/5

Best, Arnaud Spiwack _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Spiwack, Arnaud

10:15 a.m.

New subject: GHC proposal process: merging and closing

Hi Joachim, * Merging unapproved, but implemented proposals.

...

This would mean that there would be some proposals in the directory https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals

that were not vetted, discussed and approved. Is that desirable? It seems it would water down the status of the rest.

I would consider that they were implicitly vetted by whomever merged the CR into GHC master. Or is it too much of a stretch? Obviously they are changes which have somewhat side-stepped the process which probably only happens because the dust hasn't quite settled yet.

...

About documentation: The proposal can still be linked, during its implementation. Are you worried that the pull request will be lost somehow?

Not really. But if a proposal is not vetted, referring to it is less strong an argument when you ask for merge, of course. Merge serves as a witness of vetting. On the other hand, if this was the only reason to merge proposal, we should remove them when they are implemented. What I was trying to get at, is that we probably want proposals to stay, because they serve as documentation even after they have been implemented.

...

You also write that the manual should link proposals (I guess that applies to all proposals). I don’t think we would be doing our users a favor here; they expect and deserve a comprehensive and self- contained manual.

To be fair, I said "could". And the idea is that a proposal contains a lot beyond what the manual will. The entire specification section must make it to the manual. However, the motivations will usually be much shortened, and the alternatives will typically not be in a manual at all. A proposal also has a link to the github discussion which can give really insightful historical perspectives on a feature. So giving a link to the proposal could help someone who, for instance, is considering contributing an extension to a given feature. It's not something that should be prominent. But can feature in a "further reading" section, together with the relevant scientific articles.

...

We briefly had this discussion a while ago. The rationale to not close tickets that were not officially rejected is because contributor motivation is a scarce resource, and me just going around closing people’s proposals just because they are not able to press forward a lot.

I am nudging stagnant proposals, and eventually mark them as “dormant”, as a more friendly way of closing them. Many authors then close them voluntarily when they have abandoned it.

Note that the overview at https://github.com/ghc-proposals/ghc-proposals links to “≡ List of proposals under discussion” which includes only the somewhat active propsoals.

Maybe I can close dormant porposals when nothing has happened in $n$ months, with a friendly message that it can be re-opend any time.

I agree that it is a matter of reading people's psychology right. No mean feat! I would personally go for closing after a while. Certainly with the friendly message!

Joachim Breitner

10:22 a.m.

Hi, Am Freitag, den 23.02.2018, 16:15 +0100 schrieb Spiwack, Arnaud:

...

To be fair, I said "could".

that’s fair :-)

...

And the idea is that a proposal contains a lot beyond what the manual will. The entire specification section must make it to the manual. However, the motivations will usually be much shortened, and the alternatives will typically not be in a manual at all. A proposal also has a link to the github discussion which can give really insightful historical perspectives on a feature. So giving a link to the proposal could help someone who, for instance, is considering contributing an extension to a given feature. It's not something that should be prominent. But can feature in a "further reading" section, together with the relevant scientific articles.

True. How about this: Out-of-scope proposals of value should be moved to the GHC Wiki, where we already store design documents for future benefit. Linking to them from the manual _for additional information that normal users do not need_ is encouraged (again, this is something we already do).

...

I would personally go for closing after a while. Certainly with the friendly message!

I just did another round of nudges. I guess I will close when the author does not respond to the nudges. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Iavor Diatchki

11:59 a.m.

New subject: GHC proposal process: merging and closing

I agree that we should be more aggressive with clearing out proposals. Here is a suggestion: specify in the process, that after some period of discussion proposals should either be sumbitted to the committee, or closed. -Iavor On Fri, Feb 23, 2018 at 7:22 AM Joachim Breitner wrote:

...

Hi,

Am Freitag, den 23.02.2018, 16:15 +0100 schrieb Spiwack, Arnaud:

...
To be fair, I said "could".

that’s fair :-)

...
And the idea is that a proposal contains a lot beyond what the manual will. The entire specification section must make it to the manual. However, the motivations will usually be much shortened, and the alternatives will typically not be in a manual at all. A proposal also has a link to the github discussion which can give really insightful historical perspectives on a feature. So giving a link to the proposal could help someone who, for instance, is considering contributing an extension to a given feature. It's not something that should be prominent. But can feature in a "further reading" section, together with the relevant scientific articles.

True.

How about this: Out-of-scope proposals of value should be moved to the GHC Wiki, where we already store design documents for future benefit.

Linking to them from the manual _for additional information that normal users do not need_ is encouraged (again, this is something we already do).

...
I would personally go for closing after a while. Certainly with the friendly message!

I just did another round of nudges. I guess I will close when the author does not respond to the nudges.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

12:19 p.m.

Hi, I want to avoid codifying what does not need to be codified, but I get the message and will close more aggressively. (I.e. when marked as dormant and no action for another month, I’ll close.) Cheers, Joachim Am Freitag, den 23.02.2018, 16:59 +0000 schrieb Iavor Diatchki:

...

I agree that we should be more aggressive with clearing out proposals. Here is a suggestion: specify in the process, that after some period of discussion proposals should either be sumbitted to the committee, or closed.

-Iavor

On Fri, Feb 23, 2018 at 7:22 AM Joachim Breitner wrote:

...
Hi,

Am Freitag, den 23.02.2018, 16:15 +0100 schrieb Spiwack, Arnaud:

...
To be fair, I said "could".

that’s fair :-)

...
And the idea is that a proposal contains a lot beyond what the manual will. The entire specification section must make it to the manual. However, the motivations will usually be much shortened, and the alternatives will typically not be in a manual at all. A proposal also has a link to the github discussion which can give really insightful historical perspectives on a feature. So giving a link to the proposal could help someone who, for instance, is considering contributing an extension to a given feature. It's not something that should be prominent. But can feature in a "further reading" section, together with the relevant scientific articles.

True.

How about this: Out-of-scope proposals of value should be moved to the GHC Wiki, where we already store design documents for future benefit.

Linking to them from the manual _for additional information that normal users do not need_ is encouraged (again, this is something we already do).

...
I would personally go for closing after a while. Certainly with the friendly message!

I just did another round of nudges. I guess I will close when the author does not respond to the nudges.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Richard Eisenberg

12:20 p.m.

I'm in support of this direction.

...

On Feb 23, 2018, at 12:19 PM, Joachim Breitner wrote:

I want to avoid codifying what does not need to be codified, but I get the message and will close more aggressively.

(I.e. when marked as dormant and no action for another month, I’ll close.)

Joachim Breitner

10:19 a.m.

Hi, I extended my (pretty new) toolbox to gather data about the proposals at https://github.com/nomeata/ghc-proposals-stats to give me a list of proposals with no activity in the last 30 days. This allows me to be efficient in nudging authors to make progress or close their PR. Maybe that alleviates the second point a bit, while still providing a friendly experience to the community. Cheers, Joachim Am Freitag, den 23.02.2018, 09:36 -0500 schrieb Joachim Breitner:

...

Hi Arnaud,

thanks for raising this; let me lay out the reasons for doing it the current way (which is intentional, but not unchangeable):

* Merging unapproved, but implemented proposals.

This would mean that there would be some proposals in the directory https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals

that were not vetted, discussed and approved. Is that desirable? It seems it would water down the status of the rest.

About documentation: The proposal can still be linked, during its implementation. Are you worried that the pull request will be lost somehow?

You also write that the manual should link proposals (I guess that applies to all proposals). I don’t think we would be doing our users a favor here; they expect and deserve a comprehensive and self- contained manual.

* Closing:

We briefly had this discussion a while ago. The rationale to not close tickets that were not officially rejected is because contributor motivation is a scarce resource, and me just going around closing people’s proposals just because they are not able to press forward a lot.

I am nudging stagnant proposals, and eventually mark them as “dormant”, as a more friendly way of closing them. Many authors then close them voluntarily when they have abandoned it.

Note that the overview at https://github.com/ghc-proposals/ghc-proposals links to “≡ List of proposals under discussion” which includes only the somewhat active propsoals.

Maybe I can close dormant porposals when nothing has happened in $n$ months, with a friendly message that it can be re-opend any time.

Cheers, Joachim

Am Freitag, den 23.02.2018, 15:08 +0100 schrieb Spiwack, Arnaud:

...
Dear all,

Joachim directed me here to raise some remarks about the proposal process that I've brought up.

Out of the hundred or so submitted proposals, only roughly half were closed, including a mere 11 merged.

On the merging end, I noticed, in particular that the backpack proposal[1] has not been merged. The reason being that it had been implemented before the committee had time to evaluate it, hence became out of scope.

Why do we merge proposals? One reason proposal can be referred to by pull requests authors to describe the changes that they're implementing. The other reason that I can see is that proposals can serve as documentation: they can be referred to inside the documentation to explain why things are done the way they are, they can be browsed by curious onlookers who want to understand the trade-offs that went into this particular design, we could even consider linking to them in the manual as longer-form stand-alone pieces of documentation for individual features.

From that point of view the backpack proposal ought to have been merged: it is still documentation after the implementation is finished. Irrespective of whether the committee has had to work for it.

On the "closing" side, I think we should be better at triaging. It's less important, of course, because forgotten PRs fall behind are not seen by anybody. But it could help give a valuable feeling of tidiness. I believe a tidy repo makes people feel more at ease with sharing their thoughts. And, just as importantly, it would help Joachim to manage the proposals: with 40+ open proposals, you probably don't know which are active, which need a push, where he could suggest that the committee get involved. If there were only 15 proposals to track, Joachim's time would be more efficiently spent.

I don't believe we should hesitate to close a proposal which is not under discussion any more, authors can still reopen when they want to get back to discussing the matter. There are quite a few dormant proposals, also out-of-scope which didn't receive any conversation of late, or need-revision which don't seem to be seeing any update. These could all be closed.

What does everybody think?

[1] https://github.com/ghc-proposals/ghc-proposals/pull/5

Best, Arnaud Spiwack _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

2643

Age (days ago)

2643

Last active (days ago)

List overview

Download

8 comments

5 participants

participants (5)

Iavor Diatchki
Joachim Breitner
Richard Eisenberg
Simon Marlow
Spiwack, Arnaud