It really is difficult to proceed when the problem is not well defined. I also find it insulting that you suggest that I (and other developers) don't care about bringing new users to the project. The nebulous suggestion that GHC developers have ulterior motives is also not becoming of a productive discussion.
There's clearly much more to be said but it seems pointless to proceed any further. Matt On Sun, Sep 25, 2016 at 1:38 AM, Christopher Allen <c...@bitemyapp.com> wrote: > My point is that at almost every level, contributing to GHC is a > chore. Phabricator/Github is simply a good place to start for opening > things up, but it's far from the only thing. > > http://www.arcadianvisions.com/blog/2016/ghc-contributing.html has the > ring of verisimilitude to me and most working Haskellers I know. This > bright line between the users of Haskell and the contributors to the > primary compiler is not healthy long-term. > > The consistently dismissive attitude towards these objections is not > good either. > > GHC has a very poor showing compared to other compilers with similar > sets of users (FP, typed, or modern) in terms of onboarding new people > and you won't take these critiques seriously. You do the bare minimum > just so you can say you did something, but not substantive is open for > discussion. This fools no-one! > >>I don't understand this fascination with Rust the Haskell community has. The >>two projects are very different. As you say in the post, GHC is a much older >>project and as a result has much less hype around it. Rust is the definition >>of a "hot new thing" and so it makes sense that there are more contributors. > > Hype draws consumers, not producers! Excellent process, documentation, > and community is what turns those consumers into producers! > > This is so short-sighted and wrong that I don't think there's any > point in my saying more. You've made it clear you don't care. > > On Sat, Sep 24, 2016 at 7:17 PM, Matthew Pickering > <matthewtpicker...@gmail.com> wrote: >> I think this comment is useful because it highlights the point that it >> isn't very clear what "the point" even is. >> >> Is the problem that the code review process happens on phabricator and >> trac rather than github? >> It seems unlikely the project will move to github, phabricator works >> well for existing developers. In fact, phabricator was the best thing >> to ever happen to increase accessibility to newcomers. Thomie create >> some stats about the new contributors and there was a large spike >> after the more to phab. >> >> Is the problem that the way which new features are proposed is opaque? >> Ben worked on a new proposals process to help with this - >> https://github.com/ghc-proposals/ghc-proposals >> >> Is the problem technical? Is the build system not suitable? Is the >> code base poorly organised? >> This should be said but ultimately the project is a volunteer based >> effort. People don't like spending their time doing refactoring. It >> would take someone >> who particularly cared about newcomer contributors to do some of the >> cleanup work. >> >> Ultimately, I'm not sure what exactly what the point is. I read posts >> like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html >> ) and find myself disagreeing with almost every point. The comments in >> the reddit thread provide most of the refutations. The post doesn't >> address the >> fact that the feature was a small syntactic change which as erik >> pointed out, it perhaps the most difficult change to integrate as it >> must certainly pay it's way. >> >> Contributing to any project requires a certain amount of investment. >> Empirically, it seems to me that >> if the user makes the investment to build GHC and fix an issue then >> the last step, setting up phabricator, >> is not a point of friction. There are good instructions on the wiki >> which describe this process. Recently I have witnessed a new >> contributor independently provide a patch and >> when prompted to submit to phabricator, did so within a few hours. >> Phabricator doesn't seem to be a serious issue. >> >> Could you perhaps point to some concrete examples of people who have >> tried to contribute and where the sticking points are? >> As you observe, we are well meaning with this list but not very well >> placed to solve this problem as it is not clear even if there >> is a problem to solve and if there is, what the *exact* problem is. >> >> At the end of the day it is the core contributors who contribute the >> most code so the process should be optimised for them. As you probably >> read in my last email, >> phabricator works well for me but I am interested in helping newcomers >> get involved in the project. I think the best way to do this is >> managing the issue tracker well and providing 1-1 personal assistance >> to people when they need it. After a few patches, it gets much easier. >> >> If this comment makes no sense to you, then it would be even more >> beneficial if you could explain to me how other people perceive the >> process. >> >> Matt >> >> On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen <c...@bitemyapp.com> >> wrote: >>>>I think the we'd want to restrict this to Diffs submitted by contributors >>>>who already possess commit bits and specifically include a "no-review" tag >>>>in the summary. >>> >>> Is this intended to address the issues new contributors have in >>> contributing to GHC? This looks more insider stuff that misses the >>> point if so. >>> >>> If new contributors are not part of a conversation about contributing >>> to GHC, when and where did that conversation happen and what is being >>> done about it? >>> >>> On Sat, Sep 24, 2016 at 4:37 PM, Ben Gamari <b...@smart-cactus.org> wrote: >>>> Phyx <loneti...@gmail.com> writes: >>>> >>>>>>> >>>>>>> ยท Auto-push: Ability to push to Phab and have it committed >>>>>>> automatically if it validates. >>>>>> >>>>>> \o/ >>>>> >>>>> How would this work? Could there be a cooldown period? e.g. commits sit a >>>>> day before being auto-committed? >>>>> >>>>> Validate really only validates Linux x86_64. The situation is already >>>>> quite >>>>> dire for other architectures and OSes, >>>>> I fear making it worse by not allowing people time to object. >>>>> >>>> The solution here is to extend Harbormaster coverage, which is on my >>>> list anyways. My priorities is roughly, >>>> >>>>> Would this be a per person setting? This just raises so many questions. >>>>> And >>>>> I don't quite see what problem it's solving >>>>> because presumably code is tested before it's put on Phab isn't it? >>>> >>>> I think the we'd want to restrict this to Diffs submitted by >>>> contributors who already possess commit bits and specifically include a >>>> "no-review" tag in the summary. The idea here is to provide an >>>> alternative to pushing directly to master, extending the coverage of >>>> Harbormaster without inconveniencing contributors. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> _______________________________________________ >>>> 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 > > > > -- > 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