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

[Michael Sloan]

I like this solution a lot, Carter!

Mailing patches directly to the ghc-devs list could be intimidating
for newcomers.  Having a list specific to patch review could make the
process less intimidating.  From a perspective of overall contribution
intimidation, these 2 pages make it seem like a ton of extra work to
contribute to GHC:

1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs
2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures

Of course, I understand that these exist for a reason.  Contributing
to GHC isn't easy, and it does need processes, and those processes
should be followed!

However, for documentation patches and minor fixes, these pages make
it seem like you really have to put in quite a bit to get started, and
that the process is bureaucratic.  Atop getting accounts setup and
figuring out how to get ghc compiled, the amount of time investment to
get in a simple patch already seems like it is on the order of hours,
if not a full days worth of work.

At the risk of accumulating spam, perhaps the list shouldn't even
require membership?  Just have it filter based on containing an
attachment (perhaps even require a "*.patch" attachment?)

I also think that there should be an easy way to put a stop to
iterating via email and sending .patch files, and escalate to a
phabricator review.  Perhaps this could be scripted?  Is there any way
for people to use phabricator without using archanist?  Not a
criticism of the tech, but it is more to learn, and foreign to most.


One thing I've learned from maintaining stack, is that it can be
really helpful to accept patches that are imperfect.  Here's how this
works:

1) Some user wants to fix something, and doesn't quite nail it.  Maybe
makes some style mistakes, spelling errors in comments, or perhaps
writes some part of the code in a less direct way than possible

2) If the overall change is an improvement and the fixes are easy, I
go ahead and merge the imperfect patch, and then commit my own fixes
to the issues I saw.  I then say something like "Thanks for the
patch!!  I fixed a few things in e5cbda"

I feel like this is a highly valuable approach.  The contributor
appreciates being thanked, and also appreciates directly seeing the
ways that their patch could have been better.

This is antithetical to the "google style" of code review, where every
single thing is nit-picked and the author must fix it.  I think that
approach only works well when you already have an established
membership to that culture of code review (particularly if you are
getting paid for it).  With that approach, all of the bad behaviors
get beaten out of contributors, and they eventually learn their
lesson, and either leave or become good contributors.  I think this
can scare some people off, that might otherwise become regular
contributors.


Who knows if this will work out, but I think it is really worth a
shot!  Especially if the wiki is updated to indicate that there is now
an "easy mode" for contributing to ghc.

-Michael

On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> 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> 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
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>