Rethinking GHC's approach to managing proposals

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Rethinking GHC's approach to managing proposals

Ben Gamari-3
Hello everyone,

Recently there has been a fair bit of discussion[1,2] around the
mechanisms by which proposed changes to GHC are evaluated. While we have
something of a formal proposal protocol [3], it is not clearly
documented, inconsistently applied, and may be failing to serve a
significant fraction of GHC's potential contributor pool.

Over the last few weeks, I have been doing a fair amount of reading,
thinking, and discussing to try to piece together a proposal scheme
which better serves our community.

The resulting proposal [4] is strongly inspired by the RFC process in
place in the Rust community [5], the leaders of which have thought quite
hard about fostering community growth and participation. While no
process is perfect, I feel like the Rust process is a good starting
point for discussion, offering enough structure to guide new
contributors through the process while requiring only a modest
investment of developer time.

To get a sense for how well this will work in our community, I propose
that we attempt to self-host the proposed process. To this end I have
setup a ghc-proposals repository [6] and opened a pull request for
discussion of the process proposal [4].
           
Let's see how this goes.

Cheers,

- Ben


[1] https://www.reddit.com/r/haskell/comments/4oyxo2/blog_contributing_to_ghc/
[2] https://www.reddit.com/r/haskell/comments/4isua9/ghc_development_outsidein/
[3] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures
[4] https://github.com/ghc-proposals/ghc-proposals/pull/1/files?short_path=14d66cd#diff-14d66cda32248456a5f223b6333c6132
[5] https://github.com/rust-lang/rfcs
[6] https://github.com/ghc-proposals/ghc-proposals

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking GHC's approach to managing proposals

Haskell - Glasgow-haskell-users mailing list
>Recently there has been a fair bit of discussion[1,2] around the
>mechanisms by which proposed changes to GHC are evaluated. While we have
>something of a formal proposal protocol [3], it is not clearly
>documented, inconsistently applied, and may be failing to serve a
>significant fraction of GHC's potential contributor pool.

I think the best thing to do is to fork the source code and modify it according
to one's own needs. Having some sort of committees to decide about the
syntax, etc. is a really bad idea.

A.S.


--
Apostolos Syropoulos
Xanthi, Greece





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking GHC's approach to managing proposals

Ben Gamari-2
Apostolos Syropoulos via Glasgow-haskell-users
<[hidden email]> writes:

>  >Recently there has been a fair bit of discussion[1,2] around the
>>mechanisms by which proposed changes to GHC are evaluated. While we have
>>something of a formal proposal protocol [3], it is not clearly
>>documented, inconsistently applied, and may be failing to serve a
>>significant fraction of GHC's potential contributor pool.
>  
> I think the best thing to do is to fork the source code and modify it according
> to one's own needs. Having some sort of committees to decide about the
> syntax, etc. is a really bad idea.
>
The point here is not to place a committee in charge of designing
features. To the contrary, the point of this proposal is to revamp our
protocol for handling proposals brought by others. The committee
merely serves as a gatekeeper to ensure that GHC's design and
implementation remains coherent and maintainable and its semantics
well-defined.

Cheers,

- Ben

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Rethinking GHC's approach to managing proposals

Haskell - Glasgow-haskell-users mailing list
In reply to this post by Ben Gamari-3
Just to be clear:

* We are actively seeking feedback about the proposal [4] below.
  It's not a fait-accompli.

* You can join the dialogue by (a) replying to this email,
  (b) via the "Conversations" tab of [4], namely
      https://github.com/ghc-proposals/ghc-proposals/pull/1
  Doubtless via reddit too!

  If you don't like something, the more specific and concrete you
  can be about a better alternative, the better.  E.g. Richard's
  comments on the "conversations" tab both ask questions and propose
  answers.  Bravo!

Simon

| -----Original Message-----
| From: ghc-devs [mailto:[hidden email]] On Behalf Of Ben
| Gamari
| Sent: 09 July 2016 21:46
| To: GHC developers <[hidden email]>; ghc-users <glasgow-haskell-
| [hidden email]>
| Subject: Rethinking GHC's approach to managing proposals
|
| Hello everyone,
|
| Recently there has been a fair bit of discussion[1,2] around the
| mechanisms by which proposed changes to GHC are evaluated. While we have
| something of a formal proposal protocol [3], it is not clearly
| documented, inconsistently applied, and may be failing to serve a
| significant fraction of GHC's potential contributor pool.
|
| Over the last few weeks, I have been doing a fair amount of reading,
| thinking, and discussing to try to piece together a proposal scheme
| which better serves our community.
|
| The resulting proposal [4] is strongly inspired by the RFC process in
| place in the Rust community [5], the leaders of which have thought quite
| hard about fostering community growth and participation. While no
| process is perfect, I feel like the Rust process is a good starting
| point for discussion, offering enough structure to guide new
| contributors through the process while requiring only a modest
| investment of developer time.
|
| To get a sense for how well this will work in our community, I propose
| that we attempt to self-host the proposed process. To this end I have
| setup a ghc-proposals repository [6] and opened a pull request for
| discussion of the process proposal [4].
|
| Let's see how this goes.
|
| Cheers,
|
| - Ben
|
|
| [1]
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red
| dit.com%2fr%2fhaskell%2fcomments%2f4oyxo2%2fblog_contributing_to_ghc%2f&
| data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a6608
| d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Hl6GqRWfu7IOQtpE
| jpfsNAkv3mmLgNKm2ciQDoMe6HA%3d
| [2]
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red
| dit.com%2fr%2fhaskell%2fcomments%2f4isua9%2fghc_development_outsidein%2f
| &data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a660
| 8d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bj2AQqQirX3X%2f
| 4%2fFr05eXFuD4yW0r9Nmrmdg7IGEF%2f8%3d
| [3]
| https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures
| [4] https://github.com/ghc-proposals/ghc-
| proposals/pull/1/files?short_path=14d66cd#diff-
| 14d66cda32248456a5f223b6333c6132
| [5] https://github.com/rust-lang/rfcs
| [6] https://github.com/ghc-proposals/ghc-proposals
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking GHC's approach to managing proposals

Iavor Diatchki
Hello,

I think this sounds fairly reasonable, but it is hard to say how well it will work in practice until we try it.

Some clarifying questions on the intended process:
   1.  After submitting the initial merge request, is the person making the proposal to wait for any kind of acknowledgment, or just move on to step 2?
   2. Is the discussion going to happen on one of the mailing lists, if so which?   Is it the job of the proposing person to involve/notify the committee about the discussion?  If so, how are they to find out who is on the committee?
   3. How does one actually perform step 3, another pull request or simply an e-mail to someone?

Typo: two separate bullets in the proposal are labelled as 4.

Cheers,
-Iavor







On Mon, Jul 11, 2016 at 2:36 PM, Simon Peyton Jones via Glasgow-haskell-users <[hidden email]> wrote:
Just to be clear:

* We are actively seeking feedback about the proposal [4] below.
  It's not a fait-accompli.

* You can join the dialogue by (a) replying to this email,
  (b) via the "Conversations" tab of [4], namely
      https://github.com/ghc-proposals/ghc-proposals/pull/1
  Doubtless via reddit too!

  If you don't like something, the more specific and concrete you
  can be about a better alternative, the better.  E.g. Richard's
  comments on the "conversations" tab both ask questions and propose
  answers.  Bravo!

Simon

| -----Original Message-----
| From: ghc-devs [mailto:[hidden email]] On Behalf Of Ben
| Gamari
| Sent: 09 July 2016 21:46
| To: GHC developers <[hidden email]>; ghc-users <glasgow-haskell-
| [hidden email]>
| Subject: Rethinking GHC's approach to managing proposals
|
| Hello everyone,
|
| Recently there has been a fair bit of discussion[1,2] around the
| mechanisms by which proposed changes to GHC are evaluated. While we have
| something of a formal proposal protocol [3], it is not clearly
| documented, inconsistently applied, and may be failing to serve a
| significant fraction of GHC's potential contributor pool.
|
| Over the last few weeks, I have been doing a fair amount of reading,
| thinking, and discussing to try to piece together a proposal scheme
| which better serves our community.
|
| The resulting proposal [4] is strongly inspired by the RFC process in
| place in the Rust community [5], the leaders of which have thought quite
| hard about fostering community growth and participation. While no
| process is perfect, I feel like the Rust process is a good starting
| point for discussion, offering enough structure to guide new
| contributors through the process while requiring only a modest
| investment of developer time.
|
| To get a sense for how well this will work in our community, I propose
| that we attempt to self-host the proposed process. To this end I have
| setup a ghc-proposals repository [6] and opened a pull request for
| discussion of the process proposal [4].
|
| Let's see how this goes.
|
| Cheers,
|
| - Ben
|
|
| [1]
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red
| dit.com%2fr%2fhaskell%2fcomments%2f4oyxo2%2fblog_contributing_to_ghc%2f&
| data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a6608
| d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Hl6GqRWfu7IOQtpE
| jpfsNAkv3mmLgNKm2ciQDoMe6HA%3d
| [2]
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red
| dit.com%2fr%2fhaskell%2fcomments%2f4isua9%2fghc_development_outsidein%2f
| &data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a660
| 8d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bj2AQqQirX3X%2f
| 4%2fFr05eXFuD4yW0r9Nmrmdg7IGEF%2f8%3d
| [3]
| https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures
| [4] https://github.com/ghc-proposals/ghc-
| proposals/pull/1/files?short_path=14d66cd#diff-
| 14d66cda32248456a5f223b6333c6132
| [5] https://github.com/rust-lang/rfcs
| [6] https://github.com/ghc-proposals/ghc-proposals
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users