Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

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