Why are contributions via Github limited to things that don't require review? That won't encourage anyone to get started because they know that as soon as they move on to something substantive, they'll hit the same brick wall. You can't boil a frog by taking it out of the pot of lukewarm water and tossing it into the roiling kettle.
Have you looked at how Rust handles contributions to the compiler? https://github.com/rust-lang/rust They don't rely on bare Github, they use bots to automate and add structure in the ways you're trying to wring out of Phabricator. The automation and community they've built here is above and beyond anything I've seen in any other community, it is _outstanding_ and it behooves us to learn what they do and to take it seriously. Rust has five times the contributors GHC does and the depth of contributions do not trail off as quickly. Rust has been around for less time than many popular Haskell libraries! To see more of how Rust developers and users discuss new features and improvements, this forum is illuminating: https://internals.rust-lang.org/ I work with someone that has contributed to GHCJS more than once, but will not go anywhere near GHC. This is almost entirely because of the opaque process. Another: https://github.com/purescript/purescript 94 contributors, only a couple years old, written in Haskell but has many users who came from JS and don't know any Haskell, used mostly for frontend work. Putting aside Github's new code review functionality (which seems fine but isn't anything terribly impressive), there are lots of ways to skin the code review cat without putting new contributors in a typo-fix PR ghetto. On Sat, Sep 24, 2016 at 6:53 PM, Joachim Breitner <m...@joachim-breitner.de> wrote: > Hi, > > Am Samstag, den 24.09.2016, 18:46 -0500 schrieb Christopher Allen: >> Seems reasonable, but much of the consternation over GHC dev process >> has been about the relative illegibility of it, even for working >> programmers who've hacked on compilers before. It's concerning to see >> a list of items about a "contribute to GHC" discussion that seemingly >> includes nothing that addresses this. >> >> Can you point me to any discussions among GHC devs on this since the >> last time it was raised? > > I’m not sure why this proposal is causing unease here? Regular > contributors are contributors too! > > Also, the idea of accepting trivial commits via GitHub (which are then > pushed by someone with commit access) works much better if the latter > can be done efficient, i.e. in a fire-and-forget, but still safe and > checked, mode. > > And the list does include a few things that are meant to help new > contributors: > * Accepting contributions where a quick review suffices via > GitHub (that’s the item “lightweight pushes”). > * Not imposing style guides that people have to learn first > * Docker images to quickly get started. > * Easier ways of learning about GHC development (by removing old docs, > and leverating SO). > > That list is not meant to be exhaustive, if you have other ideas how to > make GHC hacking more accessible, please tell us! > > I am under the impression that there is some misunderstanding here, > because there really is nothing not be wound up about here. > > Greetings, > Joachim > > > > -- > Joachim “nomeata” Breitner > m...@joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nome...@debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- 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