Notes from Ben's "contribute to ghc" discussion

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

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

Manuel M T Chakravarty-4
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.

Chris may not have contributed to GHC, but apart from co-authoring the currently most popular Haskell book, he has consistently contributed to helping people who are new to the language (on Slack, IRC, in blog posts, etc). He has suck a ton of time into moving the language forward.

Moreover, he knows a thing or two about helping newcomers in an effective manner. And he is right in his critique that it is hard to contribute to GHC.

For example, I recently wrote a patch concerning compatibility with macOS Sierra and even posted about it on this list:


It’s a small patch, and I just don’t have the time to jump through all the hoops to get it into the repo.

And now before you accuse me of not having contributed to GHC, maybe check the git logs first.

In summary, if you don’t want to consider that maybe it is harder to contribute to GHC than it has to be and making it easier maybe would lead to more contributions, that is one thing. However, I do insist that suggestions made in good faith on this list are treated politely and not being brutally shot down.

Simon, I imagine you agree with me here.

Manuel

Brandon Allbery <[hidden email]>:


On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen <[hidden email]> wrote:
This is so short-sighted and wrong that I don't think there's any
point in my saying more. You've made it clear you don't care.

And --- note that I am not a ghc developer --- have made it clear that you do not care how much extra work you make for already massively overworked ghc developers.
You're not contributing. You're not helping. You're derailing.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


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

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

Brandon Allbery
In reply to this post by Michael Sloan

On Sat, Sep 24, 2016 at 9:05 PM, Michael Sloan <[hidden email]> wrote:
As a side observer, I find Christopher's comments to be spot on.

They're missing quite a bit, actually. Like how Rust had a bunch of contributors even before they started, and Mozilla Corp. backing them. Rust's solution is only viable if someone wants to bring those to the table along with it; it's just not possible otherwise. There aren't enough people *now* to build a whole new infrastructure.

I work with another open source project that is as short on contributors as ghc is. It's part of my day job, even, and it's a regular topic at team meetings. One comes to understand why this is not something that can be done on a whim. (And my employer isn't big enough to do the heavy lifting or provide bodies --- even ignoring that we feel it's best for us and our customers that this project remain independent, not controlled by or beholden to any company, which makes contributing somewhat difficult as a political matter although we do our best.)

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

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

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

Brandon Allbery
In reply to this post by Manuel M T Chakravarty-4

On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

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

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

Christopher Allen
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

Talking to GHC devs about what works, what doesn't,
comparing/contrasting with other processes such as Rust's

Papering all this up into a "where we are, where we'd like to go" document

Writing documentation and tutorials for getting new developers on board

Manually on-boarding new developers

I am willing to do this work in addition to my 9-5 work using Haskell,
the book(s) which are a full-time job unto themselves, and the open
source work I do.

I will not do any of this as long as this is the attitude of GHC
developers. I can not in good conscience encourage people to
contribute to a project controlled and represented with such hostility
and dismissiveness. The needs of the community and of new and casual
contributors have to be taken seriously. This is not for their sake
alone, it's to ease the workload of the maintainers and to mend the
worsening culture gap.


On Sat, Sep 24, 2016 at 8:19 PM, Brandon Allbery <[hidden email]> wrote:

>
> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty
> <[hidden email]> 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
> [hidden email]                                  [hidden email]
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Richard Fung
I suppose I'll take this opportunity to bring this thread back on topic and have everyone read my thoughts guilt free.

As a newcomer who recently submitted my first patch, I disagree with Chris's points. I'm just a junior developer who has never worked on a compiler before, so maybe the experience will be different for people from other backgrounds. I guess you're allowed to disagree with me even if you're from a similar background.

In my (short) experience, Github vs Phabricator, using Arc, and the points mentioned in the linked blog like coding style and comments were all non issues. Again, this is just my experience and others might feel differently, but if so I encourage them to raise their points and hopefully also explain in detail the issues encountered.

For me the only issue was being able to understand the code base. Sadly, this was actually a huge barrier because, rather embarrassingly, after months of reading through the code, in the end I only managed to submit a patch after Simon told me exactly what I needed to do. Even more depressingly, the other Simon (Marlow) was unhappy because it caused a performance regression so the patch was rejected! Sad life..

In other words, I found the difficulty in actually being able to contribute a meaningful patch is far greater than any difficulty in learning to use the tools and process required to submit a patch.

Of course this is to be expected from a code base as large, old, and complicated as GHC's, and I'm not too sure what can be done from a technical standpoint to address this, besides better documentation. From a process standpoint though, if I didn't have personal assistance from Simon and Ben (Thank you!!!) I imagine I would have given up much sooner, despite having been relatively motivated.

I don't know if this would be possible of course considering GHC developers are very busy as it is, but it would be great if newcomers could be assigned a mentor to contact when in need of help. Maybe I am just weird, but I actually felt bad emailing everyone for help, so I would typically go much longer than comfortable before asking for help. As you can imagine, as the struggle increases, the likelihood of giving up also does, and I will admit I thought about giving up many times.

I realize this would probably be difficult to scale, but hopefully as new developers come, they would also be able to mentor others. I think this is similar to what is done in the industry by many companies as well.

In summary, difficulty of understanding code base >>> difficulty of using tools and following documentation.

On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen <[hidden email]> 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

Talking to GHC devs about what works, what doesn't,
comparing/contrasting with other processes such as Rust's

Papering all this up into a "where we are, where we'd like to go" document

Writing documentation and tutorials for getting new developers on board

Manually on-boarding new developers

I am willing to do this work in addition to my 9-5 work using Haskell,
the book(s) which are a full-time job unto themselves, and the open
source work I do.

I will not do any of this as long as this is the attitude of GHC
developers. I can not in good conscience encourage people to
contribute to a project controlled and represented with such hostility
and dismissiveness. The needs of the community and of new and casual
contributors have to be taken seriously. This is not for their sake
alone, it's to ease the workload of the maintainers and to mend the
worsening culture gap.


On Sat, Sep 24, 2016 at 8:19 PM, Brandon Allbery <[hidden email]> wrote:
>
> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty
> <[hidden email]> 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
> [hidden email]                                  [hidden email]
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


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

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

Michael Sloan
In reply to this post by Brandon Allbery
Sorry, but I see little sense in what you are bringjng to this discussion.  Chris's points sre explaining some systemic reasons WHY there is a dearth of contributors, and attempting to make a constructive plan to address them.  Why should GHC not try to emulate a community that has fantasic cohesion, unity, and participation?

It is irrelevant why Rust has an advantage. Lets please emulate their successful strategies instead of in-fighting.

To me it seems you are just attacking his view with bluster and ad hominem, with undertones of a personal vendetta against Rust.

On Saturday, September 24, 2016, Brandon Allbery <[hidden email]> wrote:

On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;chak@justtesting.org&#39;);" target="_blank">chak@...> 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
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;allbery.b@gmail.com&#39;);" target="_blank">allbery.b@...                                  <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ballbery@sinenomine.net&#39;);" target="_blank">ballbery@...
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

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

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

Brandon Allbery

On Sat, Sep 24, 2016 at 9:44 PM, Michael Sloan <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

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

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

Jason Dagit-3
In reply to this post by Christopher Allen


On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:


On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



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

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

Joachim Breitner-2
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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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

Harendra Kumar


On 25 September 2016 at 12:48, Joachim Breitner <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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 [hidden email] 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
<[hidden email]> wrote:

>
>
> On 25 September 2016 at 12:48, Joachim Breitner <[hidden email]>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Elliot Cameron-2
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 <[hidden email]> 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 [hidden email] 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
<[hidden email]> wrote:
>
>
> On 25 September 2016 at 12:48, Joachim Breitner <[hidden email]>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


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

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] 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
<[hidden email]> wrote:
>
>
> On 25 September 2016 at 12:48, Joachim Breitner <[hidden email]>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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 <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;allbery.b@gmail.com&#39;)">allbery.b@...> wrote:
>
> On Sat, Sep 24, 2016 at 9:44 PM, Michael Sloan <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;mgsloan@gmail.com&#39;)">mgsloan@...> 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
> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;allbery.b@gmail.com&#39;)">allbery.b@...                                  <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;ballbery@sinenomine.net&#39;)">ballbery@...
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


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

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

Simon Marlow-7
In reply to this post by GHC - devs mailing list
I would rather we didn't accept contributions via github, even for small patches, and instead put more effort into streamlining the Phabricator workflow.
  • Adding another input method complicates the workflow, users have to decide which one to use
  • Github is not integrated with our other infrastructure, while Phabricator is
  • Mutliple sources of contributions makes life harder for maintainers

Let's make the Phabricator workflow easier.

  • Why not put arc in the repo, or provide a script that automatically downloads it and sets it up?
  • I also like the idea of auto-push if validate succeeds.  Or a button that you can press on the diff that would do the same thing, so you can get code review first.
  • +1 to making the manual easier to build.  The same goes for Haddocks; it's really hard to make a simple patch to the docs and test it right now.
One other thing that came up but wasn't mentioned in the notes: let's be more prompt about reverting patches that break validate, even if they only break a test.  Now that we have better CI support, we can easily identify breaking patches and revert them.

Cheers

Simon


On 24 September 2016 at 02:44, Simon Peyton Jones via ghc-devs <[hidden email]> wrote:

Friends

 

Here are the notes I took from session 2 of the Haskell Implementors Meeting.  The bolding is my choice of emphasis.

 

Simon

 

·        Doc bugs.    Two kinds

o   Typos.   Friction stops me

o   Explanations needed e.g. read/show

·        Lightweight pushes

·        Make user manual into its own repo, to make it easier to take pull requests.  But that makes it harder when making synchronised changes to GHC and user manual.

·        Auto-push: Ability to push to Phab and have it committed automatically if it validates.

·        Style guides.  Is having a defined style solving a problem we don’t really have?  One piece of guidance: adhere to the style of the surrounding code.  Low priority.

·        Docker images.   We should have one.

·        Remove old documentation!

·        Cross compilation is difficult.

·        Have a GHC StackOverflow on haskell.org   (Jacob Zalewski [hidden email] 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”.


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



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

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

Matthew Pickering
In reply to this post by Matthew Pickering
Thank you for this comment Anthony.
I thought about it over the last day and think you have it spot on.
This is the key sentence:

> The truth is that it what I complained about is *not a problem*
> for GHC devs in so far as they are happy doing GHC development!

It seems that the point that you are getting at is that currently the
development process is heavily optimised for existing developers.
There are quite a few moving parts but once you get a handle on them
all it works well for me at least. The argument seems
to be that we should (much) more heavily optimise for new
contributors. (I think this is what Chris is saying as well).

What I am trying to say is that we should meet in the middle.
We should keep using phabricator as for regular contributors github is
too painful to use for a project of GHC's size (as rust exemplifies
with the custom bots). In order to improve the newcomer's experience
it would be beneficial to consolidate as much as possible to one
domain so that new contributors have only one place to look. Does this
sound sensible to you?

I would also like to take this chance to apologies to Chris for
cutting off the discussion we were having. I would appreciate it if
you would directly respond to the suggestions in
this message.

Matt

On Sun, Sep 25, 2016 at 2:13 AM, Anthony Cowley <[hidden email]> wrote:

> On Sat, Sep 24, 2016 at 8:17 PM, Matthew Pickering
> <[hidden email]> wrote:
>> I think this comment is useful because it highlights the point that it
>> isn't very clear what "the point" even is.
>>
> [snip]
>>
>> Ultimately, I'm not sure what exactly what the point is. I read posts
>> like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html
>> ) and find myself disagreeing with almost every point. The comments in
>> the reddit thread provide most of the refutations. The post doesn't
>> address the
>> fact that the feature was a small syntactic change which as erik
>> pointed out, it perhaps the most difficult change to integrate as it
>> must certainly pay it's way.
>
>
> Matthew, if you are going to claim that you champion the concerns of
> new contributers, you must do more than dismiss criticism without
> offering a single word of reply. As I was involved in the discussion
> you linked and remember it very differently than you, I went back to
> try to understand what you possibly could have read. The top-level
> replies are:
>
> - Me clarifying that I like GHC
> - Someone who likes arc and notes, but hates the build system
> - Someone who argued that a syntactic change would be the "deep end of
> the difficulty pool" because they apparently did not realize the patch
> was already done.
> - Someone arguing that consistent style is not important
> - A strangely worded suggestion that there exist refutations but it
> would be inappropriate to mention them
> - Agreement that GHC dev is off-putting
> - Agreement that GHC dev is off-putting
> - GHC is a great compiler
> - Someone who likes GHC dev
> - A pro GitHub post
> - Someone complaining about how I was treated
>
> So, you read those comments in response to a specific, itemized,
> literally bullet-pointed complaint that getting changes into GHC by an
> outsider requires an ill-defined marathon of mailing lists and forums
> in which GHC devs do not participate very much, and what you took away
> from it was that the post was largely refuted.
>
> GHC is a fine research compiler and several people do tremendous work
> on it. But please do not keep asking what the problem is if you are
> going to completely ignore it when it is written down time and time
> again. The truth is that it what I complained about is *not a problem*
> for GHC devs in so far as they are happy doing GHC development!
> Mystery solved, we can all move on with our lives productively using
> GHC or contributing to it. Chris's reaction to the title of the talk
> is entirely understandable to me, as I had interpreted it the same
> way.
>
> Anthony
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

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

>>I think the we'd want to restrict this to Diffs submitted by
>>contributors who already possess commit bits and specifically include
>>a "no-review" tag in the summary.
>
> Is this intended to address the issues new contributors have in
> contributing to GHC? This looks more insider stuff that misses the
> point if so.
>
To reiterate Joachim's point, this is a feature to try to make it easier
for contributors who would normally push directly `master` to instead
use Phabricator and hence go through CI.

The tree being broken is bad for everyone: users, new- and
regular-contributors alike. I think it's fair to say that this change
will improve everyone's experience, even if it's aimed at regular
contributors.

> If new contributors are not part of a conversation about contributing
> to GHC, when and where did that conversation happen and what is being
> done about it?
>
It is important to remember that the ideas that were described at the
head of this thread arose at a discussion at ICFP; I think it's fair to
say that there is significantly more GHC-hacking experience per head in
this group than average. Consequently, it's quite understandable if the
ideas discussed there may have focused more on regular contributors than
new contributors.

However, I would like to emphasize that this does /not/ mean that we
have no interest in hearing from beginning contributors. I would love to
hear from those who feel lost in the current scheme.

I spoke with a number of new contributors at ICFP who reported varying
degrees of success. I would love to hear more experiences!

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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

Ben Gamari-2
In reply to this post by Jason Dagit-3
Jason Dagit <[hidden email]> writes:

> On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen <[hidden email]>
> 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.
>
Indeed we do! If you ever have questions just ask me via IRC or email.
I'd be very happy to help. Even while I may not know the answer I (or
anyone else in #ghc) will likely be able to send you to someone who
does.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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

Ben Gamari-2
In reply to this post by Simon Marlow-7
Simon Marlow <[hidden email]> writes:

> I would rather we *didn't* accept contributions via github, even for small
> patches, and instead put more effort into streamlining the Phabricator
> workflow.
>
>
>    - Adding another input method complicates the workflow, users have to
>    decide which one to use
>
I think we would want to try to sell the GitHub route as "if you would
like to contribute then we would strongly prefer you use Phabricator,
but if you must and it's a small patch, we will accept it via GitHub."

>    - Github is not integrated with our other infrastructure, while
>    Phabricator is
>
True, but I suspect for the small documentation patches that we are
currently consider this shouldn't matter so much.

>    - Mutliple sources of contributions makes life harder for maintainers
>
It does certainly put yet another task on our plates, but I would argue
that it's actually easier than accepting patches via Trac, which we
already do.

> Let's make the Phabricator workflow easier.
>
>    - Why not put arc in the repo, or provide a script that automatically
>    downloads it and sets it up?
>
I'm not sure how much of a difference placing arc in the repo will make;
the user will still at very least need to install PHP manually.

>    - I also like the idea of auto-push if validate succeeds.  Or a button
>    that you can press on the diff that would do the same thing, so you can get
>    code review first.
>
To be clear, I'm a bit weary of opening up the auto-push feature to new
contributors. While regular contributors know what changes can be safely
pushed and which require review, we have no guarantee that a new
contributor has developed these sensibilities.

>    - +1 to making the manual easier to build.  The same goes for Haddocks;
>    it's really hard to make a simple patch to the docs and test it right now.
>
The users guide should be quite possible to do.

I don't believe there is any reliable way to allow a contributor to
build the haddocks without having built GHC (since you need GHC master to
parse `base`, et al.); that being said, we could have Harbormaster
upload built documentation somewhere and then leave a link to it on the
Diff.

> One other thing that came up but wasn't mentioned in the notes: let's be
> more prompt about reverting patches that break validate, even if they only
> break a test.  Now that we have better CI support, we can easily identify
> breaking patches and revert them.
>
Agreed.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
123