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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
