How, precisely, can we improve?

[Richard Eisenberg]

Like many of you, I'm sure, I'm saddened by the occasional tone of the recent 
exchange about contributions to GHC.

I'd like to move the conversation forward -- and I'd like to do so on a 
technical basis.

So, I ask:
How, precisely, can we improve?

I think it would be best to have answers to this question start their own 
thread, as I expect several good answers to this question.

As I ask this, I am not making the assumption that we cannot, nor is this meant 
to be rhetorical. I am asking a question in search of precise, technical 
answers.

"Be more like Rust" is not an answer to this question, as it is imprecise. (I'm 
not at all maligning the overall goal of emulating a successful process. It's 
just that "be more like Rust" is not actionable.)

"Accept PRs on GitHub" *is* an answer to this question, but one we have 
revisited several times in recent memory. (I believe 
https://mail.haskell.org/pipermail/ghc-devs/2015-September/009744.html is the 
most recent.) Perhaps we can revisit this yet again, but it would be great if 
new technical content can be injected into the debate. I hope the rejection of 
the proposal linked there is not considered "dismissive", as the proposal 
generated vigorous debate -- the opposite of dismissiveness. (For what it's 
worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no 
experience setting up or maintaining infrastructure for an open source project 
and have happily deferred to those who have such experience and who have come 
out against this idea.)

"Have process (X) for accepting new language features" *is* an answer to my 
question. This is in flight and I hope addresses the concern in the community. 
It seems to me that this step addresses the grievances described in "The 
Process" part of http://www.arcadianvisions.com/blog/2016/ghc-contributing.html

"Have a formal mentorship system" *is* another answer to my question, and one I 
think we can readily adopt. Can you (for all values of "you") suggest a 
concrete model with a link? It seems to me that folks who ask for help get the 
help they need. But this surely requires the courage and wherewithal to ask for 
the help. Perhaps there is a better way to advertise our availability and 
desire to mentor. I, personally, have onboarded (or attempted to) several 
contributors and enjoy doing so. Though my ability to mentor wanes when I have 
gotten busy, I have always prioritized helping out the newest contributors, 
letting other, more confident actors' emails slip if necessary. If I have 
erred, I am sorry.

"Don't be dismissive" is not an answer to my question, as it is both imprecise 
and not technical. The most recent thread indeed had posts that seemed quite 
dismissive, but these posts emanated from people with a variety of viewpoints. 
It was hardly GHC HQ (whatever that means). What, precisely, has been 
dismissed? It looks to me that we (regular GHC contributors) take the 
community's concerns seriously. Fixes may be slow in coming, but that's not 
dismissiveness. Of course I'm biased here, but I am truly and earnestly asking 
for clarification.

Emboldened by the technical, respectful discussion recently on the merits (and 
usage patterns) of stack (starting at 
https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124847.html), I 
look forward to a similarly technical, respectful discussion on our 
contribution process.

Thanks for all that you (for all values of "you") do to help grow our community 
and make it stronger.

Richard

-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst. Prof. of Computer Science
Bryn Mawr College
Bryn Mawr, PA, USA
cs.brynmawr.edu/~rae 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Getting rid of -XImpredicativeTypes

[Dan Doel]

I don't use the extension, because it's more pleasant to use newtypes with
polymorphic contents. But here are some questions:

1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those
just disappear, or are they also enabled anyway? (I would guess the former.)

2) There was a sketch drawn up around a year ago (I think) aiming to
actually fix ImpredicativeTypes. I don't recall who was working on it, but
I think when I mentioned it in the context of something else, you didn't
seem to be aware of it. I guess it's safe to say that nothing ever came of
it, at least inasmuch as no one ever showed you their proposal for a
properly functioning ImpredicativeTypes?

Anyhow, if it can't be fixed, I think not having the extension is superior
to its current state. And really, I think even if fixing it were on the
roadmap, it'd be better to get rid of it until it were actually fixed.

-- Dan

On Sun, Sep 25, 2016 at 2:05 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Friends
>
>
>
> GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to
> support impredicative polymorphism.  But it is vestigial…. if it works,
> it’s really a fluke.  We don’t really have a systematic story here at all.
>
>
>
> I propose, therefore, to remove it entirely.  That is, if you use
> -XImpredicativeTypes, you’ll get a warning that it does nothing (ie.
> complete no-op) and you should remove it.
>
>
>
> Before I pull the trigger, does anyone think they are using it in a
> mission-critical way?
>
>
>
> Now that we have Visible Type Application there is a workaround: if you
> want to call a polymorphic function at a polymorphic type, you can
> explicitly apply it to that type.  For example:
>
>
>
> {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-}
>
> module Vta where
>
>   f x = id @(forall a. a->a) id @Int x
>
>
>
> You can also leave out the @Int part of course.
>
>
>
> Currently we have to use -XImpredicativeTypes to allow the @(forall a.
> a->a).Is that sensible?  Or should we allow it regardless?   I rather
> think the latter… if you have Visible Type Application (i.e.
> -XTypeApplications) then applying to a polytype is nothing special.   So I
> propose to lift that restriction.
>
>
>
> I should go through the GHC Proposals Process for this, but I’m on a
> plane, so I’m going to at least start with an email.
>
>
>
> Simon
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Carter Schonwald]

In writing the following huge wall of text, I had and idea that I think
many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches )
had a mailing list where folks could email the simple / small patches as
email attachments plus a body text that summarizes the patch, what it does,
and why it's simple!

What's even nice about this is its future proof and even agnostic to how
the contributor made the change set locally! They could use mercurial or
fossil for all we care. Or github. Or whatever!



My personal stance is that ghc already way easier to contribute to / get
involved with than it was 2-5 years ago.  This is even more impressive when
you consider the number of contributors (who aren't students) that focus on
ghc work full time has actually DECREASED over that period.

Community engagement / management is a totally orthogonal skill from
contributing. Both take effort.  Guiding new contributors requires both.

My personal stance is that ghc keeps on getting better and getting more
contributors.  And occasionally chatting about ways to make things better
that we have the bandwidth to do is something that should happen every year
or so. Like a health checkup.

I suspect one funnel for improvement may be figuring out how to make it
more visible how many contributors / how actively deved various subsystems
are.  I feel like many new folks veer towards subsystems that are already
actively worked on, which are often the ones that are both the most mature
and thus hardest to easily contribute to! Perhaps I should see if there's
an easy way to quantify that in a way that's easy to communicate to new
contributors. There's an interesting data presentation challenge in that!

I've definitely found that for new potential contributors that orienting
them to focus on subsystem that's important but doesn't get much activity
leads to more successful first contributions. But that requires someone
actively helping orient folks, which I like to think I've helped out with
at points in recent years.  Making this something that's easy to point at /
discover along with "newcomer tickets" might help a lot

Tweaking the way we do tickets or code review I think doesn't change the
important / fundamental challenges of doing a good patch for a project like
ghc or llvm.  (I think in some ways that llvm / gcc / clang are the right
size projects to compare ghc against )



On Saturday, September 24, 2016, Brandon Allbery 
wrote:

>
> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty <
> c...@justtesting.org
> > wrote:
>
>> Why are you so hostile to Chris? I don’t think that this is an
>> appropriate way to treat somebody who is making a suggestion in good faith.
>
>
> It may be in good faith. but it's not in good sense. There is a lot in the
> background that made Rust's setup possible, and he's not bringing that to
> the table, just assuming it'll somehow happen or that everyone else will
> drop everything for the next few months and make it happen. And I feel like
> he's being really pushy about committing already overworked people to this
> --- and insisting that anyone opposed must have a hidden agenda or
> otherwise cannot possibly have good reason to be opposed. It's not helpful
> at all; it's basically a good way to stall ghc for the next few months at
> least.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com 
>  ballb...@sinenomine.net
> 
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

Ideally, sure, having Mozilla backing would be great and thoroughly
appreciated!

I understand that change takes effort.  I think the core problem is
participant psychology.  How do we encourage people to take ownership for
these problems?  Perhaps more importantly, how does power get delegated
such that things get done by new enthusiastic contributors?

I am not very involved in GHC development (yet!  we'll see - I've got a lot
to do elsewhere), so I don't have a very concrete proposal.  To me, seems
imminently reasonable to directly emulate the approach of similar
opensource projects,which have healthy, inspiring participation.  I am not
saying that GHC dev is sickly - we all appreciate the massive amount of
effort you guys undertake on a regular basis.  I am saying that we should
strive to reduce participation friction and lower the barrier to entry.

Lowering the barrier to entry is not trivial, it can also be accompanied by
a reduction in quality.  However, I think in the long run having many more
contributors, many more eyes on the code, will be a net boon, even if
individual contribution quality is initially lower than the current high
bar of excellence.

Directly emulating projects like Rust can cut through the indecision and
give a direct way to reuse the efforts that community has already
undertaken to solve these systemic issues.

On the code review side of things, I have my preferences (github), due to
its popularity and my personal familiarity with it, but I also understand
that there is a lot of momentum and expertise around phabricator.  If we
can knock down these barriers without a herculean effort, why not give it a
try?

-Michael Sloan

On Sat, Sep 24, 2016 at 6:56 PM, Brandon Allbery > wrote:
>
> On Sat, Sep 24, 2016 at 9:44 PM, Michael Sloan > wrote:
>>
>> It is irrelevant why Rust has an advantage. Lets please emulate their
>> successful strategies instead of in-fighting.
>
>
> Does that include having Mozilla Corp. backing them? What is your
suggestion
> for this?
>
> I understand that you think this is an important cause for the dearth of
> contributors --- I've watched enough would-be contributors bounce off the
> code base (long before even considering the tooling) and give up to have
> major doubts, as underlined by Richard's recent message --- but throwing
> everything out and building a new infrastructure is not something that
> happens by itself. It needs *people* and it needs *time*. And it's harder
> (and needs more people and more time) when you have a couple decades'
worth
> of history (which Rust did not). If you have a solution to this problem,
I'm
> sure people would like to hear it.
>
> --
> brandon s allbery kf8nh   sine nomine
associates
> allber...@gmail.com 
ballb...@sinenomine.net 
> unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Getting rid of -XImpredicativeTypes

[Edward Z. Yang]

A ghc-proposals is a good way to solicit feedback and publicize more
widely.  At least a proposal is worth it (and I am in favor of removing
ImpredicativeTypes, FWIW).

Edward

Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-09-25 18:05:38 
+:
> Friends
> 
> GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to 
> support impredicative polymorphism.  But it is vestigial if it works, 
> it's really a fluke.  We don't really have a systematic story here at all.
> 
> I propose, therefore, to remove it entirely.  That is, if you use 
> -XImpredicativeTypes, you'll get a warning that it does nothing (ie. complete 
> no-op) and you should remove it.
> 
> Before I pull the trigger, does anyone think they are using it in a 
> mission-critical way?
> 
> Now that we have Visible Type Application there is a workaround: if you want 
> to call a polymorphic function at a polymorphic type, you can explicitly 
> apply it to that type.  For example:
> 
> 
> {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-}
> 
> module Vta where
> 
>   f x = id @(forall a. a->a) id @Int x
> 
> You can also leave out the @Int part of course.
> 
> Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). 
>Is that sensible?  Or should we allow it regardless?   I rather think the 
> latter... if you have Visible Type Application (i.e. -XTypeApplications) then 
> applying to a polytype is nothing special.   So I propose to lift that 
> restriction.
> 
> I should go through the GHC Proposals Process for this, but I'm on a plane, 
> so I'm going to at least start with an email.
> 
> Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Getting rid of -XImpredicativeTypes

[Carter Schonwald]

Sounds good to me. Such a change actually probably be good for reducing ghc
support load around flags that don't work and increase reasons why using
explicit type application will be awesome / more expressive than what I
would otherwise be able to do with proxy arguments


Tldr +1
A) reduces amount of community support load around unsupported flags
B) makes visible type application extension meaningfully stronger / more
powerful than proxy value approaches

On Sunday, September 25, 2016, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Friends
>
>
>
> GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to
> support impredicative polymorphism.  But it is vestigial…. if it works,
> it’s really a fluke.  We don’t really have a systematic story here at all.
>
>
>
> I propose, therefore, to remove it entirely.  That is, if you use
> -XImpredicativeTypes, you’ll get a warning that it does nothing (ie.
> complete no-op) and you should remove it.
>
>
>
> Before I pull the trigger, does anyone think they are using it in a
> mission-critical way?
>
>
>
> Now that we have Visible Type Application there is a workaround: if you
> want to call a polymorphic function at a polymorphic type, you can
> explicitly apply it to that type.  For example:
>
>
>
> {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-}
>
> module Vta where
>
>   f x = id @(forall a. a->a) id @Int x
>
>
>
> You can also leave out the @Int part of course.
>
>
>
> Currently we have to use -XImpredicativeTypes to allow the @(forall a.
> a->a).Is that sensible?  Or should we allow it regardless?   I rather
> think the latter… if you have Visible Type Application (i.e.
> -XTypeApplications) then applying to a polytype is nothing special.   So I
> propose to lift that restriction.
>
>
>
> I should go through the GHC Proposals Process for this, but I’m on a
> plane, so I’m going to at least start with an email.
>
>
>
> Simon
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Getting rid of -XImpredicativeTypes

[Simon Peyton Jones via ghc-devs]

Friends

GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to 
support impredicative polymorphism.  But it is vestigial if it works, it's 
really a fluke.  We don't really have a systematic story here at all.

I propose, therefore, to remove it entirely.  That is, if you use 
-XImpredicativeTypes, you'll get a warning that it does nothing (ie. complete 
no-op) and you should remove it.

Before I pull the trigger, does anyone think they are using it in a 
mission-critical way?

Now that we have Visible Type Application there is a workaround: if you want to 
call a polymorphic function at a polymorphic type, you can explicitly apply it 
to that type.  For example:


{-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-}

module Vta where

  f x = id @(forall a. a->a) id @Int x

You can also leave out the @Int part of course.

Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a).   
 Is that sensible?  Or should we allow it regardless?   I rather think the 
latter... if you have Visible Type Application (i.e. -XTypeApplications) then 
applying to a polytype is nothing special.   So I propose to lift that 
restriction.

I should go through the GHC Proposals Process for this, but I'm on a plane, so 
I'm going to at least start with an email.

Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Adding ConApp to Core

[Carter Schonwald]

Also this whole multi arg thing was something I was hoping to talk with
Stephanie and or Richard about at hac phi next month.

On Sunday, September 25, 2016, Carter Schonwald 
wrote:

> I'm in favor as well.
>
> I've some experiments I'd like to do on ghc (and that work would support
> me focusing on!!!) that become dramatically simpler  to get the the Simons
> seal of approval if core already gets multiple arg / simultaneous arg
> saturated application (a la type are calling or sequent core  ).
> :)
> -Carter
>
> On Saturday, September 24, 2016, Manuel M T Chakravarty <
> c...@justtesting.org
> > wrote:
>
>> I like this. Having the DataCon only in IdDetails always felt a bit off.
>>
>> Manuel
>>
>> Simon Peyton Jones via ghc-devs :
>>
>> Andres, Richard, Stephanie
>>
>> The more I think about our idea of introducing ConApp the more I like
>> it.  I wrote it up in a ticket
>>
>> https://ghc.haskell.org/trac/ghc/ticket/12618
>>
>> Simon
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Adding ConApp to Core

[Carter Schonwald]

I'm in favor as well.

I've some experiments I'd like to do on ghc (and that work would support me
focusing on!!!) that become dramatically simpler  to get the the Simons
seal of approval if core already gets multiple arg / simultaneous arg
saturated application (a la type are calling or sequent core  ).
:)
-Carter

On Saturday, September 24, 2016, Manuel M T Chakravarty <
c...@justtesting.org> wrote:

> I like this. Having the DataCon only in IdDetails always felt a bit off.
>
> Manuel
>
> Simon Peyton Jones via ghc-devs  >:
>
> Andres, Richard, Stephanie
>
> The more I think about our idea of introducing ConApp the more I like it.
> I wrote it up in a ticket
>
> https://ghc.haskell.org/trac/ghc/ticket/12618
>
> Simon
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Jakub Zalewski]

Hi all,
I agree with Elliot that the idea of a mentor is really cool, but may not
be feasible at the moment. While the "on-demand" support (irc, reddit) from
the community is great, I believe that a potential new contributor should
be able to go as far as possible on their own because:
- newcomers may be hesitant to ask dumb questions about GHC (I know I was).
- newcomers may get turned away as the task will seems more complicated
that it is.
- the number of people working full-time on GHC is low.

For that, there needs to be a single and accessible place, where newcomers
can go and learn about ghc internals, the overall process, and what should
the do next to contribute.

Currently, there is wiki on trac, which is sometimes correct, sometimes
outdated, sometimes slightly chaotic, and sometimes difficult to use. In
addition to wiki, every member in the community is actively encouraged to
try out new features in ghc and blog about their experience, which works
perfectly fine for a tightly knit community, but presents an insurmountable
barrier of entry for newcomers.

I proposed using stack overflow, as they are adding a new feature called
[documentation](http://stackoverflow.com/documentation), which allows to
maintain a list of examples for a given tag. For instance, there is a stack
overflow documentation for [haskell](
http://stackoverflow.com/documentation/haskell/topics). Furthermore, I
believe that most potential newcomers will be familiar with using stack
overflow.

Next week, I will start cleaning up the wiki, as there are some pages and
guides for newcomers which are out of date and cause unnecessary headaches
for people that are unfamiliar with ghc. I will figure out and fill any
missing information regarding checking out the source and I will check if
there are any wiki entries that need to be deduplicated.

Best wishes,
Jakub

On Sun, 25 Sep 2016 at 20:47, Elliot Cameron  wrote:

> Oh how the chatroom hath slain its thousands, and email its ten thousands!
> Flattening real, hard-working, deep-thinking people into a few paragraphs
> of letters does such injustice to propinquity that it's a wonder it ever
> works at all!
>
> It's for that very reason I want to voice my approval of the idea of
> mentors. The thing that IRC cannot give you is a (real) name and a real
> face. The true fabric underlying any process or system is the people that
> make it happen. If the relationships of the people are broken, no virtual
> system will ever be able to recover the loss. I can't help but believe that
> the best way to improve the community of contributors is to improve the
> relationships of the people in it. Therefore, having a process of providing
> mentorship could be the most effective way to address the myriad technical
> difficulties of contributing to GHC. Love covers a multitude of wrongs. A
> friendly helper could easily make up for the technical infelicities or
> inexperience. In the long term, the improved strength of community could
> begin to address any technical issues as well.
>
> That said, I am not sure if mentorship is a burden the current "in-crowd"
> would be able to bear. But even with minimal hand-holding the improvement
> to propinquity could have significant effect.
>
> Lastly, as one who is building his business, in part, on the advantage of
> Haskell, I want to express my deep gratitude to both sides of the debate.
> Chris, your efforts to improve the "on-boarding" process are truly
> herculean and a massive investment to the community. Thank you! Matthew,
> and other core devs, your hard work and world-class insight make Haskell
> the technology that it is today and I cannot thank you enough.
>
> Elliot Cameron
>
> On Sun, Sep 25, 2016 at 4:35 AM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
>> If we loop this discussion back to the original post. There is a
>> suggestion in there which seems to be what you are looking for.
>>
>> >  Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
>> jakz...@gmail.com offers to do this! – thank you).  It has a useful new
>> Documentation feature.   Eg this would be good for “how do I look up a
>> RdrName to get a Name… there seem to be six different functions that do
>> that”.
>>
>> It is also probably lost that I said there was a phabricator module
>> 'ponder' which gives this kind of functionality so it should be quick
>> and easy to setup.
>>
>> Matt
>>
>> On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar
>>  wrote:
>> >
>> >
>> > On 25 September 2016 at 12:48, Joachim Breitner <
>> m...@joachim-breitner.de>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> > It will be great to have something like that. Something that you
>> >> > figure out digging at ghc trac wiki pages, mailing lists, google
>> >> > search etc will be a few minutes job for a mentor. It may be a bit
>> >> > taxing on the mentors but they can limit how many newbies they are
>> >> > mentoring and also breed new 

Re: Notes from Ben's "contribute to ghc" discussion

[Elliot Cameron]

Oh how the chatroom hath slain its thousands, and email its ten thousands!
Flattening real, hard-working, deep-thinking people into a few paragraphs
of letters does such injustice to propinquity that it's a wonder it ever
works at all!

It's for that very reason I want to voice my approval of the idea of
mentors. The thing that IRC cannot give you is a (real) name and a real
face. The true fabric underlying any process or system is the people that
make it happen. If the relationships of the people are broken, no virtual
system will ever be able to recover the loss. I can't help but believe that
the best way to improve the community of contributors is to improve the
relationships of the people in it. Therefore, having a process of providing
mentorship could be the most effective way to address the myriad technical
difficulties of contributing to GHC. Love covers a multitude of wrongs. A
friendly helper could easily make up for the technical infelicities or
inexperience. In the long term, the improved strength of community could
begin to address any technical issues as well.

That said, I am not sure if mentorship is a burden the current "in-crowd"
would be able to bear. But even with minimal hand-holding the improvement
to propinquity could have significant effect.

Lastly, as one who is building his business, in part, on the advantage of
Haskell, I want to express my deep gratitude to both sides of the debate.
Chris, your efforts to improve the "on-boarding" process are truly
herculean and a massive investment to the community. Thank you! Matthew,
and other core devs, your hard work and world-class insight make Haskell
the technology that it is today and I cannot thank you enough.

Elliot Cameron

On Sun, Sep 25, 2016 at 4:35 AM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> If we loop this discussion back to the original post. There is a
> suggestion in there which seems to be what you are looking for.
>
> >  Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
> jakz...@gmail.com offers to do this! – thank you).  It has a useful new
> Documentation feature.   Eg this would be good for “how do I look up a
> RdrName to get a Name… there seem to be six different functions that do
> that”.
>
> It is also probably lost that I said there was a phabricator module
> 'ponder' which gives this kind of functionality so it should be quick
> and easy to setup.
>
> Matt
>
> On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar
>  wrote:
> >
> >
> > On 25 September 2016 at 12:48, Joachim Breitner <
> m...@joachim-breitner.de>
> > wrote:
> >>
> >> Hi,
> >>
> >> > It will be great to have something like that. Something that you
> >> > figure out digging at ghc trac wiki pages, mailing lists, google
> >> > search etc will be a few minutes job for a mentor. It may be a bit
> >> > taxing on the mentors but they can limit how many newbies they are
> >> > mentoring and also breed new mentors to keep the cycle going.
> >>
> >> I hope and assume that already now that every possible contributor who
> >> has questions like this and asks (e.g. on irc) will get a helpful
> >> answer. Is that insufficient?
> >
> >
> > Maybe. Though irc seems to be quite popular among Haskell community and
> > other open source communities I have never been able to utilize it
> somehow.
> > I don't know if there is something wrong with it or with me. I installed
> an
> > irc client logged into it once or twice but never got hooked to it. Such
> > questions on ghc-devs maybe a nuisance for a lot of other people or at
> least
> > that's what I felt as a newbie. I usually tend to do a lot of homework
> > before sending a question to ghc-devs. Maybe a ghc-newbies like mailing
> list
> > (one more list!) can give the impression of a lower barrier for sending
> > stupid or operational questions.
> >
> > -harendra
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

If we loop this discussion back to the original post. There is a
suggestion in there which seems to be what you are looking for.

>  Have a GHC StackOverflow on haskell.org   (Jacob Zalewski jakz...@gmail.com 
> offers to do this! – thank you).  It has a useful new Documentation feature.  
>  Eg this would be good for “how do I look up a RdrName to get a Name… there 
> seem to be six different functions that do that”.

It is also probably lost that I said there was a phabricator module
'ponder' which gives this kind of functionality so it should be quick
and easy to setup.

Matt

On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar
 wrote:
>
>
> On 25 September 2016 at 12:48, Joachim Breitner 
> wrote:
>>
>> Hi,
>>
>> > It will be great to have something like that. Something that you
>> > figure out digging at ghc trac wiki pages, mailing lists, google
>> > search etc will be a few minutes job for a mentor. It may be a bit
>> > taxing on the mentors but they can limit how many newbies they are
>> > mentoring and also breed new mentors to keep the cycle going.
>>
>> I hope and assume that already now that every possible contributor who
>> has questions like this and asks (e.g. on irc) will get a helpful
>> answer. Is that insufficient?
>
>
> Maybe. Though irc seems to be quite popular among Haskell community and
> other open source communities I have never been able to utilize it somehow.
> I don't know if there is something wrong with it or with me. I installed an
> irc client logged into it once or twice but never got hooked to it. Such
> questions on ghc-devs maybe a nuisance for a lot of other people or at least
> that's what I felt as a newbie. I usually tend to do a lot of homework
> before sending a question to ghc-devs. Maybe a ghc-newbies like mailing list
> (one more list!) can give the impression of a lower barrier for sending
> stupid or operational questions.
>
> -harendra
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Harendra Kumar]

On 25 September 2016 at 12:48, Joachim Breitner 
wrote:

> Hi,
>
> > It will be great to have something like that. Something that you
> > figure out digging at ghc trac wiki pages, mailing lists, google
> > search etc will be a few minutes job for a mentor. It may be a bit
> > taxing on the mentors but they can limit how many newbies they are
> > mentoring and also breed new mentors to keep the cycle going.
>
> I hope and assume that already now that every possible contributor who
> has questions like this and asks (e.g. on irc) will get a helpful
> answer. Is that insufficient?


Maybe. Though irc seems to be quite popular among Haskell community and
other open source communities I have never been able to utilize it
somehow.  I don't know if there is something wrong with it or with me. I
installed an irc client logged into it once or twice but never got hooked
to it. Such questions on ghc-devs maybe a nuisance for a lot of other
people or at least that's what I felt as a newbie. I usually tend to do a
lot of homework before sending a question to ghc-devs. Maybe a ghc-newbies
like mailing list (one more list!) can give the impression of a lower
barrier for sending stupid or operational questions.

-harendra
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Joachim Breitner]

Hi,

> It will be great to have something like that. Something that you
> figure out digging at ghc trac wiki pages, mailing lists, google
> search etc will be a few minutes job for a mentor. It may be a bit
> taxing on the mentors but they can limit how many newbies they are
> mentoring and also breed new mentors to keep the cycle going.

I hope and assume that already now that every possible contributor who
has questions like this and asks (e.g. on irc) will get a helpful
answer. Is that insufficient?

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Harendra Kumar]

It will be great to have something like that. Something that you figure out
digging at ghc trac wiki pages, mailing lists, google search etc will be a
few minutes job for a mentor. It may be a bit taxing on the mentors but
they can limit how many newbies they are mentoring and also breed new
mentors to keep the cycle going.

-harendra

On 25 September 2016 at 11:46, Jason Dagit  wrote:

>
>
> On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen 
> wrote:
>
>> I'd be willing to help with work required to open up GHC development
>> more along multiple lines including:
>>
>> Bots/automation for Github
>>
>> Talking to Rust devs about what works, what doesn't
>>
>
> Last year I approached some folks in the rust community because I wanted
> to learn how to contribute to the rust compiler. In my experience, the
> really special thing they had was an identified pool of contributors who
> were willing and able to provide mentoring. I got hooked up with a mentor
> and that made all the difference. I had a real live person I could talk to
> about the process, the process-meta, and that person had context with me.
> Pretty much everything else was just details.
>
> GHC dev probably has mentors too, but I don't know because I've never
> thought to check or ask.
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Jason Dagit]

On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen 
wrote:

> I'd be willing to help with work required to open up GHC development
> more along multiple lines including:
>
> Bots/automation for Github
>
> Talking to Rust devs about what works, what doesn't
>

Last year I approached some folks in the rust community because I wanted to
learn how to contribute to the rust compiler. In my experience, the really
special thing they had was an identified pool of contributors who were
willing and able to provide mentoring. I got hooked up with a mentor and
that made all the difference. I had a real live person I could talk to
about the process, the process-meta, and that person had context with me.
Pretty much everything else was just details.

GHC dev probably has mentors too, but I don't know because I've never
thought to check or ask.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs