I suppose I'll take this opportunity to bring this thread back on topic and have everyone read my thoughts guilt free.
As a newcomer who recently submitted my first patch, I disagree with Chris's points. I'm just a junior developer who has never worked on a compiler before, so maybe the experience will be different for people from other backgrounds. I guess you're allowed to disagree with me even if you're from a similar background. In my (short) experience, Github vs Phabricator, using Arc, and the points mentioned in the linked blog like coding style and comments were all non issues. Again, this is just my experience and others might feel differently, but if so I encourage them to raise their points and hopefully also explain in detail the issues encountered. For me the only issue was being able to understand the code base. Sadly, this was actually a huge barrier because, rather embarrassingly, after months of reading through the code, in the end I only managed to submit a patch after Simon told me exactly what I needed to do. Even more depressingly, the other Simon (Marlow) was unhappy because it caused a performance regression so the patch was rejected! Sad life.. In other words, I found the difficulty in actually being able to contribute a meaningful patch is far greater than any difficulty in learning to use the tools and process required to submit a patch. Of course this is to be expected from a code base as large, old, and complicated as GHC's, and I'm not too sure what can be done from a technical standpoint to address this, besides better documentation. From a process standpoint though, if I didn't have personal assistance from Simon and Ben (Thank you!!!) I imagine I would have given up much sooner, despite having been relatively motivated. I don't know if this would be possible of course considering GHC developers are very busy as it is, but it would be great if newcomers could be assigned a mentor to contact when in need of help. Maybe I am just weird, but I actually felt bad emailing everyone for help, so I would typically go much longer than comfortable before asking for help. As you can imagine, as the struggle increases, the likelihood of giving up also does, and I will admit I thought about giving up many times. I realize this would probably be difficult to scale, but hopefully as new developers come, they would also be able to mentor others. I think this is similar to what is done in the industry by many companies as well. In summary, difficulty of understanding code base >>> difficulty of using tools and following documentation. On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen <c...@bitemyapp.com> wrote: > I'd be willing to help with work required to open up GHC development > more along multiple lines including: > > Bots/automation for Github > > Talking to Rust devs about what works, what doesn't > > Talking to GHC devs about what works, what doesn't, > comparing/contrasting with other processes such as Rust's > > Papering all this up into a "where we are, where we'd like to go" document > > Writing documentation and tutorials for getting new developers on board > > Manually on-boarding new developers > > I am willing to do this work in addition to my 9-5 work using Haskell, > the book(s) which are a full-time job unto themselves, and the open > source work I do. > > I will not do any of this as long as this is the attitude of GHC > developers. I can not in good conscience encourage people to > contribute to a project controlled and represented with such hostility > and dismissiveness. The needs of the community and of new and casual > contributors have to be taken seriously. This is not for their sake > alone, it's to ease the workload of the maintainers and to mend the > worsening culture gap. > > > On Sat, Sep 24, 2016 at 8:19 PM, Brandon Allbery <allber...@gmail.com> > wrote: > > > > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty > > <c...@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 > > allber...@gmail.com > ballb...@sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
