Proposal process status

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

Proposal process status

Ben Gamari-3

Hello everyone,

As you hopefully know, a few weeks ago we proposed a new process [1] for
collecting, discussing, and deciding upon changes to GHC and its Haskell
superset. While we have been happy to see a small contingent of
contributors join the discussion, the number is significantly smaller
than the set who took part in the earlier Reddit discussions.

In light of this, we are left a bit uncertain of how to proceed. So,
we would like to ask you to let us know your feelings regarding the
proposed process:

  * Do you feel the proposed process is an improvement over the status
    quo?

  * Why? (this needn't be long, just a sentence hitting the major points)

  * What would you like to see changed in the proposed process, if
    anything?

That's all. Again, feel free to reply either on the GitHub pull request
[1] or this thread if you would prefer. Your response needn't be long;
we just want to get a sense of how much of the community feels that 1)
this effort is worth undertaking, and 2) that the proposal before us is
in fact an improvement over the current state of affairs.

Thanks for your help!

Cheers,

- Ben


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

_______________________________________________
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: Proposal process status

Thomas Miedema
  * What would you like to see changed in the proposed process, if
    anything?

Simon Peyton Jones as Benevolent Dictator For Life (BDFL)

If the BDFL had made a simple YES/NO decision on ShortImports [1] and ArgumentDo [2], we wouldn't be here talking about process proposals, Anthony wouldn't be mad, everything would be fine. We don't need another Haskell committee.

* Keep using Trac for proposals, but use the description field of a ticket for the specification, instead of separate wiki page.

* Add better filtering possibilities to Trac (say someone wants to only subscribe to tickets where syntax extensions are discussed). Adding better filtering possibilities will also benefit bug fixers (say someone wants to only subscribe to bugs on Windows or with keyword=PatternSynonyms).

* Don't let hotly debated feature requests go without a resolution. 


_______________________________________________
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: Proposal process status

Yuras Shumovich
In reply to this post by Ben Gamari-3

Looks like reddit is a wrong place, so I'm replicating my comment here:

On Wed, 2016-07-20 at 11:36 +0200, Ben Gamari wrote:

> Hello everyone,
>
> As you hopefully know, a few weeks ago we proposed a new process [1]
> for
> collecting, discussing, and deciding upon changes to GHC and its
> Haskell
> superset. While we have been happy to see a small contingent of
> contributors join the discussion, the number is significantly smaller
> than the set who took part in the earlier Reddit discussions.
>
> In light of this, we are left a bit uncertain of how to proceed. So,
> we would like to ask you to let us know your feelings regarding the
> proposed process:
>
>   * Do you feel the proposed process is an improvement over the
> status
>     quo?

Yes, definitely. The existing process is too vague, so formalizing it
is a win in any case.


>
>   * Why? (this needn't be long, just a sentence hitting the major
> points)
>
>   * What would you like to see changed in the proposed process, if
>     anything?


The proposed process overlaps with the Language Committee powers. In
theory the Committee works on language standard, but de facto Haskell
is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
adds new extension to Haskell. So I'd like the process to enforce
separation between experimental extensions (not recommended in
production code) and language improvements. I'd like the process to
specify how the GHC Committee is going to communicate and share powers
with the Language Committee.

Thanks,
Yuras.

>
> That's all. Again, feel free to reply either on the GitHub pull
> request
> [1] or this thread if you would prefer. Your response needn't be
> long;
> we just want to get a sense of how much of the community feels that
> 1)
> this effort is worth undertaking, and 2) that the proposal before us
> is
> in fact an improvement over the current state of affairs.
>
> Thanks for your help!
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/1
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-user
> s
_______________________________________________
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: Proposal process status

Iavor Diatchki
In reply to this post by Ben Gamari-3
Hello Ben,

I posted this when you originally asked for feed-back, but perhaps it got buried among the rest of the e-mails.

I think the proposal sounds fairly reasonable, but it is hard to say how well it will work in practice until we try it, and we should be ready to change it if needs be.

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 Wed, Jul 20, 2016 at 2:36 AM, Ben Gamari <[hidden email]> wrote:

Hello everyone,

As you hopefully know, a few weeks ago we proposed a new process [1] for
collecting, discussing, and deciding upon changes to GHC and its Haskell
superset. While we have been happy to see a small contingent of
contributors join the discussion, the number is significantly smaller
than the set who took part in the earlier Reddit discussions.

In light of this, we are left a bit uncertain of how to proceed. So,
we would like to ask you to let us know your feelings regarding the
proposed process:

  * Do you feel the proposed process is an improvement over the status
    quo?

  * Why? (this needn't be long, just a sentence hitting the major points)

  * What would you like to see changed in the proposed process, if
    anything?

That's all. Again, feel free to reply either on the GitHub pull request
[1] or this thread if you would prefer. Your response needn't be long;
we just want to get a sense of how much of the community feels that 1)
this effort is worth undertaking, and 2) that the proposal before us is
in fact an improvement over the current state of affairs.

Thanks for your help!

Cheers,

- Ben


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

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal process status

Ben Gamari-3
In reply to this post by Yuras Shumovich
Yuras Shumovich <[hidden email]> writes:

> Looks like reddit is a wrong place, so I'm replicating my comment here:
>
Thanks for your comments Yuras!

>>   * Do you feel the proposed process is an improvement over the
>> status quo?
>
> Yes, definitely. The existing process is too vague, so formalizing it
> is a win in any case.
>
Good to hear.

>>   * What would you like to see changed in the proposed process, if
>>     anything?
>
> The proposed process overlaps with the Language Committee powers. In
> theory the Committee works on language standard, but de facto Haskell
> is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
> adds new extension to Haskell. So I'd like the process to enforce
> separation between experimental extensions (not recommended in
> production code) and language improvements. I'd like the process to
> specify how the GHC Committee is going to communicate and share powers
> with the Language Committee.
>
To clarify I think Language Committee here refers to the Haskell Prime
committee, right?

I think these two bodies really do serve different purposes.
Historically the Haskell Prime committee has been quite conservative in
the sorts of changes that they standardized; as far as I know almost all
of them come from a compiler. I would imagine that the GHC Committee
would be a gate-keeper for proposals entering GHC and only some time
later, when the semantics and utility of the extension are
well-understood, would the Haskell Prime committee consider introducing
it to the Report. As far as I understand it, this is historically how
things have worked in the past, and I don't think this new process would
change that.

Of course, let me know if I'm off-base here.

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: Proposal process status

Ben Gamari-3
In reply to this post by Iavor Diatchki
Iavor Diatchki <[hidden email]> writes:

> Hello Ben,
>
> I posted this when you originally asked for feed-back, but perhaps it
> got buried among the rest of the e-mails.
>
Indeed it seems that way. Sorry about that!

> I think the proposal sounds fairly reasonable, but it is hard to say how
> well it will work in practice until we try it, and we should be ready to
> change it if needs be.
>
Right. I fully expect that we will have to iterate on 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?
>
The discussion phase can happen asynchronously from any action by the
Committee. Of course, the Committee should engauge in discussion early,
but I don't think any sort of acknowledgement is needed. An open pull
request should be taken to mean "let's discuss this idea."

>    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?

The proposed process places the discussion in a pull request. The idea
here is to use well-understood and widely-used code review tools to
faciliate the conversation.

The Committee members will be notified of the open pull request by the
usual event notification mechanism (e.g. in GitHub one can subscribe to
a repository).

>    3. How does one actually perform step 3, another pull request or simply
> an e-mail to someone?
>
The opening of the pull request would mark the beginning of the
discussion period. When the author feels that the discussion has come to
something of a conclusion, they will request that the GHC Committee
consider the proposal for acceptable by leaving a comment on the pull
request.

> Typo: two separate bullets in the proposal are labelled as 4.
>
I believe this should be fixed now. Thanks!

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: Proposal process status

Alexander Berntsen
In reply to this post by Ben Gamari-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 20/07/16 11:36, Ben Gamari wrote:
> * What would you like to see changed in the proposed process, if
> anything?
No GitHub. In order to fully utilise GitHub, one needs to run
proprietary programs. Additionally, GitHub is proprietary software
server-side.

While I don't feel too strongly about which of the proposed
alternatives are chosen, since they are both free software, augmenting
Phabricator would probably be the best choice, since this avoids
adding another piece of infrastructure to use and administer.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXj6s4AAoJENQqWdRUGk8BI9oP/RCV14jmpHpbJ1Cr42Nr+yam
cXrjSmKGfHNDGbBRqfORBTaAGkRbXvVJAWYiaUXddl1FUmB40JWg+sDQ/a2PVp28
10QB361+FzqSir+7wkJd27GH3mki1Hmsm/wKHISDal2P40QWSRVKZh8xr1vvWzje
MVL42AvBV/P9nF40bEI+axO11A7/PnkHCzQqspK/DdtwRWLZ5ny3XYI1owH/zy9m
Roo2+Zw0jIxKL18l6edLoPEiunsj7B9iHwf+TglODgyBbIdqAndxuQuJinOYEz+q
FooDD3Qv+qhrRAUnTXXQ+pXO7hYqXTLqeEQKekhaj8zgo2OqzY96RM7Q2OQ0xuaR
mYDe99Bg9SC5fqYZX4yVSr8anw+dGqT2FDeqWg3OBg0wDH+QZ7mhlqXbdXENaFcx
0TtIEYTf7QGZioE3B21DcfQSoXoWOPvEWE7qityPLBIln/FcA/B0obtBVNooErdA
c2WM7BdNnE6+nBuxMC39FhX1Tr61Ao3BtGKJJyeANcLxefrGu+6T1udM7IsKfPAC
obZllRLNrTTR9xyD/8ebVpI8wstxcjmaGCFN8kA74byMwoX/fMN/Ol7N47Ee3BWE
l4OqPSxAACZrwkRLoovX/PhulOxX5E/go4aio9fDZT8i5HKxocb66GmixBxALejA
Vjegvti1Nfj6cAAWmNT1
=apBk
-----END PGP SIGNATURE-----
_______________________________________________
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: Proposal process status

Richard Eisenberg-4

> On Jul 20, 2016, at 12:47 PM, Alexander Berntsen <[hidden email]> wrote:
>
> On 20/07/16 11:36, Ben Gamari wrote:
>> * What would you like to see changed in the proposed process, if
>> anything?
> No GitHub. In order to fully utilise GitHub, one needs to run
> proprietary programs. Additionally, GitHub is proprietary software
> server-side.

While I indeed sympathize with your desire to avoid proprietary, closed software, I'd like to point out that avoiding GitHub because it's closed has a real cost:
 * It requires more work (a very limited resource) to maintain our own instance of whatever alternate solution we come up with.
 * GitHub is very current in our community. Moving away from GitHub may increase barriers to contributions.

Of course, our use of GitHub would appear to increase barriers to those who avoid closed software. This fact means that we need to balance the desires of some potential contributors (who prefer to avoid closed software) with other potential contributors (who prefer to use GitHub).

To be clear, I'm not trying to shoot down Alexander's point -- just trying to point out that there are shades of gray here.

Also, what proprietary programs are needed to fully utilize GitHub? I just use git and ssh, both pieces of free software.

Richard
_______________________________________________
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: Proposal process status

Ben Gamari-3
In reply to this post by Alexander Berntsen
Alexander Berntsen <[hidden email]> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 20/07/16 11:36, Ben Gamari wrote:
>> * What would you like to see changed in the proposed process, if
>> anything?
> No GitHub. In order to fully utilise GitHub, one needs to run
> proprietary programs. Additionally, GitHub is proprietary software
> server-side.
>
I know, it's rather frustrating. I also have fairly strong feelings
about open-source purity, but in this case I just don't see any way to
improve the current situation under this constraint.

I agree that Phabricator is the logical choice for self-hosting in our
situation, but sadly it just doesn't have the features at the moment to
make the process convenient and accessible (which is the motivation for
the change in the first place).


> While I don't feel too strongly about which of the proposed
> alternatives are chosen, since they are both free software, augmenting
> Phabricator would probably be the best choice, since this avoids
> adding another piece of infrastructure to use and administer.

The Phabricator developers already do a fair amount for us without
charging for their time. We can ask them to add the features that we
need but this will take time, if it happens at all, unless we put money
on the table. Unless someone is willing to put money down I'm not sure
Phabricator will be an option in the foreseeable future.

It does look like Gitlab is an impressive option but really then we are
back to the problem of fragmented development tools. Using Trac,
Phabricator, Gitlab, and mailing lists all in one project seems a bit
silly.

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: Proposal process status

Alexander Berntsen
In reply to this post by Richard Eisenberg-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 20/07/16 19:00, Richard Eisenberg wrote:
> While I indeed sympathize with your desire to avoid proprietary,
> closed software, I'd like to point out that avoiding GitHub
> because it's closed has a real cost
I don't value those points over my freedom. But those who don't value
their freedom might value them, so thanks for listing them.

> Also, what proprietary programs are needed to fully utilize GitHub?
> I just use git and ssh, both pieces of free software.
For proposals, we'll be doing lots of discussions and review. Those
parts of GitHub rely heavily on proprietary client-side JavaScript.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXj69RAAoJENQqWdRUGk8Bnv8P+wc2CV4CEifkebXniGte7oOm
yJ3fB/wOhm5sgGVOOAVNiv3VfvQb8t3qsouFkYyaVJXfLMGhK1PehC3Y38mI28HU
NA1FK9CVyBU3YHQmyyqegJGyjj+DEVrN/rmydgU3xCPCRflB/gvMdv0PMUhlIj8v
2tTjXguElLxAncnsU4YIVWcmvN+Wssikv8H/FWksJTsuZdFXkC1VzLbGJHGc0plt
s8v6OWWFxXqv3ujFy1e4yTv+VoBeKEbEVPhsxGvU7q4IkrVGLUOEnR0LPV3+H+Um
1XWez8VIBMIobnDE/0ZR++6AXc08iOhTR1Cgd+6YW0SGDP54HqG/Oj1Hop7kdAy6
7j62Csr8DAjUOfJyWng+vmIOd66g/Cu3OxQlmtiznjnStDQKmPpLTe3srYWC2w0T
iIR8sKqmFb4QnohDH6bG4JPCtwVIM2RXg8xzcfbHMihqa1DZqS8DCrtx80Ga5UHP
Ln0/j6ig5erQFJU7XM5CvnUDIMu0wQp8bP4VbTqRM4dvFVoBxOk8D9vZFh2LlSNM
/sYkD0oRHeFFoXRiL5XuTLufntA/BR+n/fFGoHL2ZtLEWk+Phe70PvLT/vqXJtZk
AtwlNXCr1uD/4rhCxdNAoVuV8o+8F+Iq0l4kFGqtH8hZdRN9+HpISWO3HgaeyIVD
tJbo1M5Eo3+Ky7o25uiQ
=cPxT
-----END PGP SIGNATURE-----
_______________________________________________
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: Proposal process status

Alexander Berntsen
In reply to this post by Ben Gamari-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 20/07/16 19:04, Ben Gamari wrote:
> I know, it's rather frustrating. I also have fairly strong feelings
>  about open-source purity, but in this case I just don't see any
> way to improve the current situation under this constraint.
I don't think that starting to rely on proprietary software *is* an
improvement, but the opposite.

> It does look like Gitlab is an impressive option but really then
> we are back to the problem of fragmented development tools. Using
> Trac, Phabricator, Gitlab, and mailing lists all in one project
> seems a bit silly.
I don't understand why using GitLab is more silly than using GitHub,
when considering fragmentation.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXj6/uAAoJENQqWdRUGk8Bk4UP/RsWT2YjFTxFR0mPxx0gQgFd
jq9lp8DlJsZJ33I7OF4kuFLxjbMoybRDRbr9rDSWXVhor25mxogXa+5VU6/PXj5I
IKsh495k8BZDDajlUuPPvC0jymHtJI2urVWls9Da/uVOu/xeuutK+fvuosLsuPAh
0AaoncvDV9LaGDYxOEGIQa5ucEiDwE5k+PbPyxH9lCWXH8ULKGG+tPIh+0/wCCbx
pxoQhire9LLWUXtkMQ654mgurQ76BD97b4Hab42ommtwNwFnxS4Oqw/Q7n2dzmdc
WSiHu6S8twcWgqiJNr+OVcNuXcRHmFHYnS0VvI9tTYvvE5cZAenjJrXE1ncyoZkh
yTPulCx18GxNafzEsGxw7LYSmMIb2/QKWEkRDh7kkP+fOFvXPTl7QhUjz5RGJ90s
RgbDD9M17fRJ96yGwogFSzSVZP1KTiYCOMnqk8KjDQgwXOqQFCDKUS1dawpeARCi
M6zJsVkuVjJCsb/lKzlq71w1yJuOMS6gO92SajqRFfJ+j8q+GTP6/DnY+vUDvoxq
klNAhqQGJKLgvy47fS6MN9hv8K4yj4NmDY8vSruOOJ1RBlruNiUoEXFKSfRZVwpk
FjEZYar7/rdOIVsI5W7Tt4Qip3LGnpqzdHH3lehxWaDtWgwrV0hnMToVapOsm0Rs
n2OTI95HXi21nm7jYV+X
=I8EH
-----END PGP SIGNATURE-----
_______________________________________________
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: Proposal process status

amindfv
In reply to this post by Ben Gamari-3


> El 20 jul 2016, a las 12:45, Ben Gamari <[hidden email]> escribió:
>
> Iavor Diatchki <[hidden email]> writes:
>
>> Hello Ben,
>>
>> I posted this when you originally asked for feed-back, but perhaps it
>> got buried among the rest of the e-mails.
> Indeed it seems that way. Sorry about that!
>
>> I think the proposal sounds fairly reasonable, but it is hard to say how
>> well it will work in practice until we try it, and we should be ready to
>> change it if needs be.
> Right. I fully expect that we will have to iterate on 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?
> The discussion phase can happen asynchronously from any action by the
> Committee. Of course, the Committee should engauge in discussion early,
> but I don't think any sort of acknowledgement is needed. An open pull
> request should be taken to mean "let's discuss this idea."
>
>>  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?
>
> The proposed process places the discussion in a pull request. The idea
> here is to use well-understood and widely-used code review tools to
> faciliate the conversation.

This part runs strongly against the grain of what I'd prefer: email is lightweight, decentralized, standard, and has many clients. We can read discussion of Haskell proposals any way we like. Github on the other hand only allows us to read issues by going to Github, and using whatever interface Github has given us (which personally I find very annoying, esp. on mobile). In addition, reading proposals offline becomes very difficult. Many of us read discussion when commuting, where, e.g. in NYC, there isn't cell service.

For reviewing code that implements a proposal, I'm a lot more flexible (although again I'm not a fan of Github)

For the people who like having history tracked with git: gitit is a possibility, and is written in Haskell.

Tom



> The Committee members will be notified of the open pull request by the
> usual event notification mechanism (e.g. in GitHub one can subscribe to
> a repository).
>
>>  3. How does one actually perform step 3, another pull request or simply
>> an e-mail to someone?
> The opening of the pull request would mark the beginning of the
> discussion period. When the author feels that the discussion has come to
> something of a conclusion, they will request that the GHC Committee
> consider the proposal for acceptable by leaving a comment on the pull
> request.
>
>> Typo: two separate bullets in the proposal are labelled as 4.
> I believe this should be fixed now. Thanks!
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal process status

Niklas Larsson


> 20 juli 2016 kl. 19:38 skrev [hidden email]:
>
>
>
>> El 20 jul 2016, a las 12:45, Ben Gamari <[hidden email]> escribió:
>>
>> Iavor Diatchki <[hidden email]> writes:
>>
>>> Hello Ben,
>>>
>>> I posted this when you originally asked for feed-back, but perhaps it
>>> got buried among the rest of the e-mails.
>> Indeed it seems that way. Sorry about that!
>>
>>> I think the proposal sounds fairly reasonable, but it is hard to say how
>>> well it will work in practice until we try it, and we should be ready to
>>> change it if needs be.
>> Right. I fully expect that we will have to iterate on 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?
>> The discussion phase can happen asynchronously from any action by the
>> Committee. Of course, the Committee should engauge in discussion early,
>> but I don't think any sort of acknowledgement is needed. An open pull
>> request should be taken to mean "let's discuss this idea."
>>
>>> 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?
>>
>> The proposed process places the discussion in a pull request. The idea
>> here is to use well-understood and widely-used code review tools to
>> faciliate the conversation.
>
> This part runs strongly against the grain of what I'd prefer: email is lightweight, decentralized, standard, and has many clients. We can read discussion of Haskell proposals any way we like. Github on the other hand only allows us to read issues by going to Github, and using whatever interface Github has given us (which personally I find very annoying, esp. on mobile). In addition, reading proposals offline becomes very difficult. Many of us read discussion when commuting, where, e.g. in NYC, there isn't cell service.
>
> For reviewing code that implements a proposal, I'm a lot more flexible (although again I'm not a fan of Github)
>
> For the people who like having history tracked with git: gitit is a possibility, and is written in Haskell.
>
> Tom
>

It's possible both follow and contribute to issues in a github repo via email. I do it all the time for Idris.

// Niklas

>
>
>> The Committee members will be notified of the open pull request by the
>> usual event notification mechanism (e.g. in GitHub one can subscribe to
>> a repository).
>>
>>> 3. How does one actually perform step 3, another pull request or simply
>>> an e-mail to someone?
>> The opening of the pull request would mark the beginning of the
>> discussion period. When the author feels that the discussion has come to
>> something of a conclusion, they will request that the GHC Committee
>> consider the proposal for acceptable by leaving a comment on the pull
>> request.
>>
>>> Typo: two separate bullets in the proposal are labelled as 4.
>> I believe this should be fixed now. Thanks!
>>
>> Cheers,
>>
>> - Ben
>>
>> _______________________________________________
>> 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
_______________________________________________
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: Proposal process status

Ben Gamari-3
In reply to this post by Alexander Berntsen
Alexander Berntsen <[hidden email]> writes:

> On 20/07/16 19:04, Ben Gamari wrote:
>> I know, it's rather frustrating. I also have fairly strong feelings
>>  about open-source purity, but in this case I just don't see any
>> way to improve the current situation under this constraint.
>
> I don't think that starting to rely on proprietary software *is* an
> improvement, but the opposite.
>
This is a bit of a judgement call. I know this is a long-contested
issue, but personally for me it puts me at ease if,

 * the proprietary code is running on someone else's machine

 * I can use the application with open tools (a web browser of your
   choice, git, and an email client)

 * I can get my data out if needed


>> It does look like Gitlab is an impressive option but really then
>> we are back to the problem of fragmented development tools. Using
>> Trac, Phabricator, Gitlab, and mailing lists all in one project
>> seems a bit silly.
>
> I don't understand why using GitLab is more silly than using GitHub,
> when considering fragmentation.

When put this way my argument does indeed sound a bit silly. :-)

Perhaps it's not. I think the difference is that we would
be consolidating on a platform which much of the Haskell community
already uses in their non-GHC development.

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: Proposal process status

Adam Foltzer
I really appreciate you putting so much work into this. It is very important, and I believe could do much to increase awareness of and participation in these processes.

I've left most of my thoughts as line comments on the proposal document, but since discussion of platform choice is taking place here, I'll quote the Motivations section:
  1. Higher than necessary barrier-to-entry.
For the purposes of this proposal, whether we would prefer a competing alternative is secondary to the fact that a Github account has become a very low common denominator for people wishing to participate in the development of open source projects. If we decide to proceed with a non-Github platform, we need to make a compelling case that the alternate choice does not raise the barrier to entry, or else we need to decide that we have different priorities for this effort.

Thanks,
Adam

On Wed, Jul 20, 2016 at 12:56 PM, Ben Gamari <[hidden email]> wrote:
Alexander Berntsen <[hidden email]> writes:

> On 20/07/16 19:04, Ben Gamari wrote:
>> I know, it's rather frustrating. I also have fairly strong feelings
>>  about open-source purity, but in this case I just don't see any
>> way to improve the current situation under this constraint.
>
> I don't think that starting to rely on proprietary software *is* an
> improvement, but the opposite.
>
This is a bit of a judgement call. I know this is a long-contested
issue, but personally for me it puts me at ease if,

 * the proprietary code is running on someone else's machine

 * I can use the application with open tools (a web browser of your
   choice, git, and an email client)

 * I can get my data out if needed


>> It does look like Gitlab is an impressive option but really then
>> we are back to the problem of fragmented development tools. Using
>> Trac, Phabricator, Gitlab, and mailing lists all in one project
>> seems a bit silly.
>
> I don't understand why using GitLab is more silly than using GitHub,
> when considering fragmentation.

When put this way my argument does indeed sound a bit silly. :-)

Perhaps it's not. I think the difference is that we would
be consolidating on a platform which much of the Haskell community
already uses in their non-GHC development.

Cheers,

- Ben

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal process status

Jack Hill
On Wed, 20 Jul 2016, Adam Foltzer wrote:

>  1. Higher than necessary barrier-to-entry.
> For the purposes of this proposal, whether we would prefer a competing alternative is secondary to the fact that a Github account has become a very low
> common denominator for people wishing to participate in the development of open source projects. If we decide to proceed with a non-Github platform, we
> need to make a compelling case that the alternate choice does not raise the barrier to entry, or else we need to decide that we have different priorities
> for this effort.

Hi all,

I'm a bit of an outsider here as I'm not involved in GHC development (but
I am interested in how it goes). I've struggled with my own desire to
avoid using proprietary software like GitHub, and the desire to work with
those who favor it, so I am interested in how these competing desires can
be addressed.

Would the barrier to entry to a non-GitHub system be reduced by using
GitHub for user authentication/accounts (like http://exercism.io/ ), or is
knowing how to use other software too much of a barrier (I guess that
would depend on the software…)?

Thanks,
Jack
_______________________________________________
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: Proposal process status

Alexander Berntsen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 20/07/16 23:41, Jack Hill wrote:
> Would the barrier to entry to a non-GitHub system be reduced by
> using GitHub for user authentication/accounts
For what it's worth, GitLab supports this[0]. You can also use
Twitter, or whatever.

[0]  <http://docs.gitlab.com/ee/integration/omniauth.html>
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXj/B7AAoJENQqWdRUGk8BJZcQAJQc/v7UWFdFEVVHlE9Mp/PR
ddlT5ngNJEagxzv5vZpEAk3oVTq2jyMaHP/KM+RGwR8l025jdP/groZ73g2X1qTn
EMLg+orKO5SGMeHK0jdypBQCMEhwNI3kDvh/Nu3ZOdM2yBWHbHHkW/3CD6T4n+zo
UpSDfmlkpOXfOtssqngjlnYJ0/roldrJGY1RCGmtrljFmvWTlmBBTTA/HqxB1mQy
doA9uJnwI8Cr7MTpoV7W8yOzv8IkfiOgO7Q3kUv8rrRtij7uN4wqM0+/eyFEmapO
BGMWM5RixmffjIyKILFUr0WkgYk8WtgXfqA8+kcYYeKQB+er7Jppbzw+IeSdyJ0g
UyM7140uBtLAqHUCpvXx8Yp36qRmEtf5Bqscz9+4oQoAWLeYAvHWaIcifj1fqtUd
HQuMdES0Pm1PcXPBu1WNd31QUeb0UsM7N1STvgAv/Iwi2SH/OFk4JyPgjSrtPDc+
KoD5LunsWBotipZr1reia7pW0mjhwPf8e6rI7FOhZjNFyNesoQWxIDFTp3IBxSYZ
oyz7bdGRP1H1MsxwBeVpPN5IzWA4EkCiWKcCb6lGFvg9lqSFfFY36HGwoHehkvo/
cSV9agY4V4ZSl0wIp3sy5eCPcUmaBR/JHCiDrhpVl+x8kRaYVbjvoS09Kty0J3nj
upaF1qaI20+1Jdv0pyab
=n/aA
-----END PGP SIGNATURE-----
_______________________________________________
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: Proposal process status

Ben Gamari-2
In reply to this post by Jack Hill
Jack Hill <[hidden email]> writes:

> Hi all,
>
> I'm a bit of an outsider here as I'm not involved in GHC development (but
> I am interested in how it goes). I've struggled with my own desire to
> avoid using proprietary software like GitHub, and the desire to work with
> those who favor it, so I am interested in how these competing desires can
> be addressed.
>
> Would the barrier to entry to a non-GitHub system be reduced by using
> GitHub for user authentication/accounts (like http://exercism.io/ ), or is
> knowing how to use other software too much of a barrier (I guess that
> would depend on the software…)?
>
To some extent. The size of the barrier posed by an alternate
system isn't a discrete quantity and is highly dependent upon one's
frame of reference. Many people won't wander from GitHub at all; other
won't even register for a GitHub account. People vary widely in their
preferences, which is what makes this problem so difficult.

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: Proposal process status

Carter Schonwald
In reply to this post by Ben Gamari-3


On Wednesday, July 20, 2016, Ben Gamari <[hidden email]> wrote:
Yuras Shumovich <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;shumovichy@gmail.com&#39;)">shumovichy@...> writes:

> Looks like reddit is a wrong place, so I'm replicating my comment here:
>
Thanks for your comments Yuras!

>>   * Do you feel the proposed process is an improvement over the
>> status quo?
>
> Yes, definitely. The existing process is too vague, so formalizing it
> is a win in any case.
>
Good to hear.

>>   * What would you like to see changed in the proposed process, if
>>     anything?
>
> The proposed process overlaps with the Language Committee powers. In
> theory the Committee works on language standard, but de facto Haskell
> is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
> adds new extension to Haskell. So I'd like the process to enforce
> separation between experimental extensions (not recommended in
> production code) and language improvements. I'd like the process to
> specify how the GHC Committee is going to communicate and share powers
> with the Language Committee.
>
To clarify I think Language Committee here refers to the Haskell Prime
committee, right?

I think these two bodies really do serve different purposes.
Historically the Haskell Prime committee has been quite conservative in
the sorts of changes that they standardized; as far as I know almost all
of them come from a compiler. I would imagine that the GHC Committee
would be a gate-keeper for proposals entering GHC and only some time
later, when the semantics and utility of the extension are
well-understood, would the Haskell Prime committee consider introducing
it to the Report. As far as I understand it, this is historically how
things have worked in the past, and I don't think this new process would
change that.

Of course, let me know if I'm off-base here.

As one of the 20 members of the Haskell (Prime) 2020 committee id like to interject on this front: the preliminary discussions the committee has had thus far had a clear agreement that we shall aim to be a bit more progressive about what shall be included in the standard. The main bar will be the extent to which features or capabilities can be articulated without over specifying implementation details and can tractably have compatible but different compilers for the standard.

  I think some of the other prime committee members can articulate this a bit better than I, so don't hold me to this precise phrasing ;)


 

Cheers,

- Ben

_______________________________________________
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: Proposal process status

Sven Panne-2
In reply to this post by Adam Foltzer
2016-07-20 23:16 GMT+02:00 Adam Foltzer <[hidden email]>:
[...] I'll quote the Motivations section:
  1. Higher than necessary barrier-to-entry.
For the purposes of this proposal, whether we would prefer a competing alternative is secondary to the fact that a Github account has become a very low common denominator for people wishing to participate in the development of open source projects. If we decide to proceed with a non-Github platform, we need to make a compelling case that the alternate choice does not raise the barrier to entry, or else we need to decide that we have different priorities for this effort.

+1 for that. Just to give a few numbers, just gathered from Hackage by some grep/sed/wc "technology": 6799 of the 9946 packages (i.e. 68%) use GitHub. The numbers are even higher when one considers the top 100 downloaded packages only: 92% of them use GitHub. So like it or not, the Haskell community already relies *heavily* on GitHub, and it seems that most people don't have a problem with that or consider the alternatives inferior.

As Ben already said, using some proprietary SW is no real problem as long as you can get all your data out of it (in a non-proprietary format). And I don't understand the point about "proprietary client-side JavaScript" at all: Should we stop using 99% of the Internet because some server sends us some JavaScript we have no license for? And what about all those routers/switches/etc. in between which connect you to the rest of the world: They definitely run proprietary SW, and nobody cares (for a good reason).

Don't get me wrong: I'm very much for Open Source, but let's not go over the top here. Let's use a tool basically everybody knows and focus on the content, not on the technology.

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