Notes from Ben's "contribute to ghc" discussion

[Richard Fung]

>
> Indeed we do! If you ever have questions just ask me via IRC or email.
> I'd be very happy to help.


First of all thank you for the help you've given me so far.

Maybe I'm different from others, but my workflow as a newcomer was just
reading https://ghc.haskell.org/trac/ghc/wiki/Newcomers.

My extremely unsophisticated idea is to just update this wiki page so that
it's obvious there are people who are willing to mentor newcomers. It seems
as though we already have mentors or people willing to be mentors, but we
also have people who did not know this was available.

More specifically, I think it would be useful if under the "Finding a
Ticket" section, as an alternative to just picking a ticket, we suggest
people to ask either through email or on IRC for a starter ticket. Then,
hopefully the people who would be willing to mentor this person can suggest
tickets they are equipped to deal with themselves.

By having newcomers ask for a ticket, we can guarantee that if this person
gets a response there would be a mentor available. Also, if someone is too
busy to be a mentor, then that person could just choose not to volunteer so
that nobody should get overburdened, or at least any more overburdened than
they already are.

It might seem silly and I am probably just too shy, but as someone new I am
always very hesitant to email the entire mailing list for help. On the
other hand, I also feel bad for emailing a specific person because I figure
they are likely very busy. If I were assigned someone to ask for help,
especially someone who volunteered himself or herself, I suspect I would
not feel so embarrassed to ask for help. I probably should have asked for
help more on IRC but to be honest I have only used IRC once or twice in my
life, incidentally also for help on Haskell, so it's not something I really
remember.

On Mon, Sep 26, 2016 at 12:13 PM, Ben Gamari <ben at smart-cactus.org> wrote:

> Simon Marlow <marlowsd at gmail.com> 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
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160926/1a72f4c6/attachment-0001.html>