<div dir="ltr">I dislike this approach, having to already deal with a project that does patches via mailing lists it is very hard to follow conversations. As soon as multiple people get involved things fall apart. </div><span>
</span><p dir="ltr">I have multiple mailing rules and other things just so I can keep track of comments. And then volume makes patches disappear into a void. </p><span>
</span><p dir="ltr">We already have a lightweight process. Lots of people just attach the patch to trac. And we still accept it. </p><span>
</span><p dir="ltr">Going to trac forces you to give me useful information about what you are trying to fix. A mailing list doesn't force a submitter to give me basic information about the patch. Such as which platform it effects. </p><span>
</span><p dir="ltr">Also you can use <a href="http://phabricator.haskell.org" target="_blank">phabricator.haskell.org</a> without arc. You can manually upload a patch file to it. </p><span>
</span><div>Again,  phabricator's summerary file I find very useful. It may be annoying for drive by commiters, but when I have to come back to this code a year or so later, I need to know why it was added.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 26, 2016, 07:34 Michael Sloan <<a href="mailto:mgsloan@gmail.com" target="_blank">mgsloan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like this solution a lot, Carter!<br>
<br>
Mailing patches directly to the ghc-devs list could be intimidating<br>
for newcomers.  Having a list specific to patch review could make the<br>
process less intimidating.  From a perspective of overall contribution<br>
intimidation, these 2 pages make it seem like a ton of extra work to<br>
contribute to GHC:<br>
<br>
1) <a href="https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs</a><br>
2) <a href="https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures</a><br>
<br>
Of course, I understand that these exist for a reason.  Contributing<br>
to GHC isn't easy, and it does need processes, and those processes<br>
should be followed!<br>
<br>
However, for documentation patches and minor fixes, these pages make<br>
it seem like you really have to put in quite a bit to get started, and<br>
that the process is bureaucratic.  Atop getting accounts setup and<br>
figuring out how to get ghc compiled, the amount of time investment to<br>
get in a simple patch already seems like it is on the order of hours,<br>
if not a full days worth of work.<br>
<br>
At the risk of accumulating spam, perhaps the list shouldn't even<br>
require membership?  Just have it filter based on containing an<br>
attachment (perhaps even require a "*.patch" attachment?)<br>
<br>
I also think that there should be an easy way to put a stop to<br>
iterating via email and sending .patch files, and escalate to a<br>
phabricator review.  Perhaps this could be scripted?  Is there any way<br>
for people to use phabricator without using archanist?  Not a<br>
criticism of the tech, but it is more to learn, and foreign to most.<br>
<br>
<br>
One thing I've learned from maintaining stack, is that it can be<br>
really helpful to accept patches that are imperfect.  Here's how this<br>
works:<br>
<br>
1) Some user wants to fix something, and doesn't quite nail it.  Maybe<br>
makes some style mistakes, spelling errors in comments, or perhaps<br>
writes some part of the code in a less direct way than possible<br>
<br>
2) If the overall change is an improvement and the fixes are easy, I<br>
go ahead and merge the imperfect patch, and then commit my own fixes<br>
to the issues I saw.  I then say something like "Thanks for the<br>
patch!!  I fixed a few things in e5cbda"<br>
<br>
I feel like this is a highly valuable approach.  The contributor<br>
appreciates being thanked, and also appreciates directly seeing the<br>
ways that their patch could have been better.<br>
<br>
This is antithetical to the "google style" of code review, where every<br>
single thing is nit-picked and the author must fix it.  I think that<br>
approach only works well when you already have an established<br>
membership to that culture of code review (particularly if you are<br>
getting paid for it).  With that approach, all of the bad behaviors<br>
get beaten out of contributors, and they eventually learn their<br>
lesson, and either leave or become good contributors.  I think this<br>
can scare some people off, that might otherwise become regular<br>
contributors.<br>
<br>
<br>
Who knows if this will work out, but I think it is really worth a<br>
shot!  Especially if the wiki is updated to indicate that there is now<br>
an "easy mode" for contributing to ghc.<br>
<br>
-Michael<br>
<br>
On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald<br>
<<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br>
> In writing the following huge wall of text, I had and idea that I think many<br>
> folks would find palatable:<br>
><br>
> What if simple small patches (such as hypothetical drive by doc patches )<br>
> had a mailing list where folks could email the simple / small patches as<br>
> email attachments plus a body text that summarizes the patch, what it does,<br>
> and why it's simple!<br>
><br>
> What's even nice about this is its future proof and even agnostic to how the<br>
> contributor made the change set locally! They could use mercurial or fossil<br>
> for all we care. Or github. Or whatever!<br>
><br>
><br>
><br>
> My personal stance is that ghc already way easier to contribute to / get<br>
> involved with than it was 2-5 years ago.  This is even more impressive when<br>
> you consider the number of contributors (who aren't students) that focus on<br>
> ghc work full time has actually DECREASED over that period.<br>
><br>
> Community engagement / management is a totally orthogonal skill from<br>
> contributing. Both take effort.  Guiding new contributors requires both.<br>
><br>
> My personal stance is that ghc keeps on getting better and getting more<br>
> contributors.  And occasionally chatting about ways to make things better<br>
> that we have the bandwidth to do is something that should happen every year<br>
> or so. Like a health checkup.<br>
><br>
> I suspect one funnel for improvement may be figuring out how to make it more<br>
> visible how many contributors / how actively deved various subsystems are.<br>
> I feel like many new folks veer towards subsystems that are already actively<br>
> worked on, which are often the ones that are both the most mature and thus<br>
> hardest to easily contribute to! Perhaps I should see if there's an easy way<br>
> to quantify that in a way that's easy to communicate to new contributors.<br>
> There's an interesting data presentation challenge in that!<br>
><br>
> I've definitely found that for new potential contributors that orienting<br>
> them to focus on subsystem that's important but doesn't get much activity<br>
> leads to more successful first contributions. But that requires someone<br>
> actively helping orient folks, which I like to think I've helped out with at<br>
> points in recent years.  Making this something that's easy to point at /<br>
> discover along with "newcomer tickets" might help a lot<br>
><br>
> Tweaking the way we do tickets or code review I think doesn't change the<br>
> important / fundamental challenges of doing a good patch for a project like<br>
> ghc or llvm.  (I think in some ways that llvm / gcc / clang are the right<br>
> size projects to compare ghc against )<br>
><br>
><br>
><br>
> On Saturday, September 24, 2016, Brandon Allbery <<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>><br>
> wrote:<br>
>><br>
>><br>
>> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty<br>
>> <<a href="mailto:chak@justtesting.org" target="_blank">chak@justtesting.org</a>> wrote:<br>
>>><br>
>>> Why are you so hostile to Chris? I don’t think that this is an<br>
>>> appropriate way to treat somebody who is making a suggestion in good faith.<br>
>><br>
>><br>
>> It may be in good faith. but it's not in good sense. There is a lot in the<br>
>> background that made Rust's setup possible, and he's not bringing that to<br>
>> the table, just assuming it'll somehow happen or that everyone else will<br>
>> drop everything for the next few months and make it happen. And I feel like<br>
>> he's being really pushy about committing already overworked people to this<br>
>> --- and insisting that anyone opposed must have a hidden agenda or otherwise<br>
>> cannot possibly have good reason to be opposed. It's not helpful at all;<br>
>> it's basically a good way to stall ghc for the next few months at least.<br>
>><br>
>> --<br>
>> brandon s allbery kf8nh                               sine nomine<br>
>> associates<br>
>> <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>
>> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a><br>
>> unix, openafs, kerberos, infrastructure, xmonad<br>
>> <a href="http://sinenomine.net" rel="noreferrer" target="_blank">http://sinenomine.net</a><br>
><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>