Notes from Ben's "contribute to ghc" discussion

Sun Sep 25 00:51:46 UTC 2016

It really is difficult to proceed when the problem is not well defined.

I also find it insulting that you suggest that I (and other
developers) don't care about bringing new users to the project. The
nebulous suggestion that GHC developers have ulterior motives is also
not becoming of a productive discussion.

There's clearly much more to be said but it seems pointless to proceed
any further.

Matt

On Sun, Sep 25, 2016 at 1:38 AM, Christopher Allen <cma at bitemyapp.com> wrote:
> 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