Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Carter Schonwald]

In writing the following huge wall of text, I had and idea that I think
many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches )
had a mailing list where folks could email the simple / small patches as
email attachments plus a body text that summarizes the patch, what it does,
and why it's simple!

What's even nice about this is its future proof and even agnostic to how
the contributor made the change set locally! They could use mercurial or
fossil for all we care. Or github. Or whatever!



My personal stance is that ghc already way easier to contribute to / get
involved with than it was 2-5 years ago.  This is even more impressive when
you consider the number of contributors (who aren't students) that focus on
ghc work full time has actually DECREASED over that period.

Community engagement / management is a totally orthogonal skill from
contributing. Both take effort.  Guiding new contributors requires both.

My personal stance is that ghc keeps on getting better and getting more
contributors.  And occasionally chatting about ways to make things better
that we have the bandwidth to do is something that should happen every year
or so. Like a health checkup.

I suspect one funnel for improvement may be figuring out how to make it
more visible how many contributors / how actively deved various subsystems
are.  I feel like many new folks veer towards subsystems that are already
actively worked on, which are often the ones that are both the most mature
and thus hardest to easily contribute to! Perhaps I should see if there's
an easy way to quantify that in a way that's easy to communicate to new
contributors. There's an interesting data presentation challenge in that!

I've definitely found that for new potential contributors that orienting
them to focus on subsystem that's important but doesn't get much activity
leads to more successful first contributions. But that requires someone
actively helping orient folks, which I like to think I've helped out with
at points in recent years.  Making this something that's easy to point at /
discover along with "newcomer tickets" might help a lot

Tweaking the way we do tickets or code review I think doesn't change the
important / fundamental challenges of doing a good patch for a project like
ghc or llvm.  (I think in some ways that llvm / gcc / clang are the right
size projects to compare ghc against )



On Saturday, September 24, 2016, Brandon Allbery <allbery.b at gmail.com>
wrote:

>
> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty <
> chak at justtesting.org
> <javascript:_e(%7B%7D,'cvml','chak at justtesting.org');>> 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
> allbery.b at gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b at gmail.com');>
>                                  ballbery at sinenomine.net
> <javascript:_e(%7B%7D,'cvml','ballbery at sinenomine.net');>
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160925/4f0f7895/attachment.html>