Notes from Ben's "contribute to ghc" discussion

Sun Sep 25 00:38:34 UTC 2016

My point is that at almost every level, contributing to GHC is a
chore. Phabricator/Github is simply a good place to start for opening
things up, but it's far from the only thing.

http://www.arcadianvisions.com/blog/2016/ghc-contributing.html has the
ring of verisimilitude to me and most working Haskellers I know. This
bright line between the users of Haskell and the contributors to the
primary compiler is not healthy long-term.

The consistently dismissive attitude towards these objections is not
good either.

GHC has a very poor showing compared to other compilers with similar
sets of users (FP, typed, or modern) in terms of onboarding new people
and you won't take these critiques seriously. You do the bare minimum
just so you can say you did something, but not substantive is open for
discussion. This fools no-one!

>I don't understand this fascination with Rust the Haskell community has. The two projects are very different. As you say in the post, GHC is a much older project and as a result has much less hype around it. Rust is the definition of a "hot new thing" and so it makes sense that there are more contributors.

Hype draws consumers, not producers! Excellent process, documentation,
and community is what turns those consumers into producers!

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.

On Sat, Sep 24, 2016 at 7:17 PM, Matthew Pickering
<matthewtpickering at gmail.com> wrote:
> I think this comment is useful because it highlights the point that it
> isn't very clear what "the point" even is.
>
> Is the problem that the code review process happens on phabricator and
> trac rather than github?
> It seems unlikely the project will move to github, phabricator works
> well for existing developers. In fact, phabricator was the best thing
> to ever happen to increase accessibility to newcomers. Thomie create
> some stats about the new contributors and there was a large spike
> after the more to phab.
>
> Is the problem that the way which new features are proposed is opaque?
> Ben worked on a new proposals process to help with this -
> https://github.com/ghc-proposals/ghc-proposals
>
> Is the problem technical? Is the build system not suitable? Is the
> code base poorly organised?
> This should be said but ultimately the project is a volunteer based
> effort. People don't like spending their time doing refactoring. It
> would take someone
> who particularly cared about newcomer contributors to do some of the
> cleanup work.
>
> 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.
>
> Contributing to any project requires a certain amount of investment.
> Empirically, it seems to me that
> if the user makes the investment to build GHC and fix an issue then
> the last step, setting up phabricator,
> is not a point of friction. There are good instructions on the wiki
> which describe this process. Recently I have witnessed a new
> contributor independently provide a patch and
> when prompted to submit to phabricator, did so within a few hours.
> Phabricator doesn't seem to be a serious issue.
>
> Could you perhaps point to some concrete examples of people who have
> tried to contribute and where the sticking points are?
> As you observe, we are well meaning with this list but not very well
> placed to solve this problem as it is not clear even if there
> is a problem to solve and if there is, what the *exact* problem is.
>
> At the end of the day it is the core contributors who contribute the
> most code so the process should be optimised for them. As you probably
> read in my last email,
> phabricator works well for me but I am interested in helping newcomers
> get involved in the project. I think the best way to do this is
> managing the issue tracker well and providing 1-1 personal assistance
> to people when they need it. After a few patches, it gets much easier.
>
> If this comment makes no sense to you, then it would be even more
> beneficial if you could explain to me how other people perceive the
> process.
>
> Matt
>
> On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen <cma at bitemyapp.com> wrote:
>>>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.
>>
>> 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?
>>
>> On Sat, Sep 24, 2016 at 4:37 PM, Ben Gamari <ben at smart-cactus.org> wrote:
>>> Phyx <lonetiger at gmail.com> writes:
>>>
>>>>>>
>>>>>> ·        Auto-push: Ability to push to Phab and have it committed
>>>>>> automatically if it validates.
>>>>>
>>>>> \o/
>>>>
>>>> How would this work? Could there be a cooldown period? e.g. commits sit a
>>>> day before being auto-committed?
>>>>
>>>> Validate really only validates Linux x86_64. The situation is already quite
>>>> dire for other architectures and OSes,
>>>> I fear making it worse by not allowing people time to object.
>>>>
>>> The solution here is to extend Harbormaster coverage, which is on my
>>> list anyways. My priorities is roughly,
>>>
>>>> Would this be a per person setting? This just raises so many questions. And
>>>> I don't quite see what problem it's solving
>>>> because presumably code is tested before it's put on Phab isn't it?
>>>
>>> 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. The idea here is to provide an
>>> alternative to pushing directly to master, extending the coverage of
>>> Harbormaster without inconveniencing contributors.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>>
>>
>> --
>> Chris Allen
>> Currently working on http://haskellbook.com
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Chris Allen
Currently working on http://haskellbook.com