On Contributing To Laravel

Hello!

First, thanks to all of you for at least being interested in Laravel! I love working on the framework and am glad other people are enjoying it.

One thing that has been bothering me is I have seen a few people say they don't contribute to Laravel because it seems like PRs get closed or shot down without much explanation. It's hard to tell how many people are actually experiencing this issue. However, even a few cases is something that really bothers me and I want to improve. On one hand, any project of significant size will have to turn away issues and PRs, but we want to try to at least make sure everyone feels like they are getting a "fair hearing".

First, if you have had a PR or issue get closed with no explanation or in a rude way, could you please PM me with a link so I could check it out and revisit the issue?

Secondly, I would also be welcome to suggestions on how to manage issues in general. PRs are a little easier to manage because there is actionable code to either merge or not merge. However, sometimes issues don't have an apparent good solution at the time, or maybe me as the maintainer is not sure if it is an edge case, or an installation or configuration issue, or a genuine issue with the framework.

Currently, I am the only one who manages PRs and I can stay on top of them well without getting behind. We often only have 15-20 open PRs across the **entire** Laravel GitHub organization. My biggest challenge is the "Issues" tab on GitHub. It gets a lot of activity and its hard to filter out genuine issues from support requests, configuration problems, general questions, etc. I must admit I rarely visit the issues tab and instead let Graham Campbell try to bubble up important issues to me privately so I can take a look at them. He is sort of serving as issue "curator" if you will and trying to filter through them so I don't have to read each one.

If anyone has better suggestions for how to manage issues and PRs so that it is less frustrating for people please let me know! Would love to discuss!

**------------EDIT------------**

Thanks for all the detailed and honest feedback. I already have a few ideas for how we can improve things going forward. Quite a few of the complaints have been around Graham Campbell. I think Graham contributes a lot to the framework technically and definitely has a valuable place within the ecosystem. He knows **a lot** about PHP, Composer, and the ecosystem as a whole.

However, I think I am to blame for a lot of the frustration. I have been asking Graham to manage issues when really I think he shines best in other areas of contribution. We can make some changes where Graham can still contribute in a very valuable way, just perhaps not as the only person doing front-line issue support, which is probably better suited for a team of people that is more gifted with "customer support" type skills.

We need to expand the amount of people who are helping review these issues, and I've already reached out to one other person to help out in this area as well. I think when the people reviewing issues are overworked (Graham is a full-time student, intern, etc), we are going to get the short, terse responses that frustrate people. If we can spread the issue team out a little bit I think that will help everyone be in a better mood and not feel like they have to have a mad rush to close or work as many issues as possible.

36 thoughts on “On Contributing To Laravel”

  1. I’ve never contributed to Laravel as whenever I’ve read PR’s/Issues in the past, I’ve noticed Graham Campbell being rude and dismissive of peoples help. So why bother. He’s done the same on various projects on github (non-laravel), so I always associate laravel with poor support based on what I’ve seen.

    I know that’s not a proper reflection of the framework and I know you put huge amounts of work into it, but he does tarnish the brand, at least in my perspective.

    Get someone more friendly to help out with issues and PRs, and people might feel more welcome to contribute.

    Reply
  2. The thing that gets me is the ‘holding off for now’ comments on PRs and issues, an explanation would be useful. If its an implementation issue, then letting the author know would be useful.

    Reply
  3. Hey Taylor, for what it’s worth we (Magento) are watching this thread. While it’s a challenge to handle PRs and architectural questions in a public forum, it is essential, and I’m glad to see you putting this out there. Everyone benefits.

    Reply
  4. I am compelled to say that in my case, seeing Graham Campbell do his thing from the side has been a real turn off for contributing.

    A few days ago something bothered me and so I said f… it, and opened my first issue. It was immediately closed. Which all by itself is awesome, immediate response that is. But Graham closed it with something in the spirit of thanks bro, but better read the contribution guide next time.

    It wasn’t all that awful like stuff I’ve seen from the sidelines, and maybe, just maybe, if I hadn’t seen anything from the sidelines to begin with, I would’ve just stopped at – “that seems unjustified”, and moved on. But I can’t ignore what I already know, so it just feels like – “I knew this would happen, shouldn’t have bothered to begin with”.

    I imagine people ranting when their issues are the ones getting closed is not something new, but I am trying to remain as objective as I can, and even if I’m wrong about the issue itself, there’s just something wrong with the attitude. It’s just too easy to compare to other popular repos (that have a reputation of dealing with issues in a polite and timely manner) and their people’s attitude, and realize that.

    Reply
  5. Hey !

    I’ve contributed a couple of trivial PRs to laravel, and I think you can address this by sprinkling bits of kindness to every comment, issue and PR. “Thank you for taking the time to write this. I think this block blabla”. “Hey, this doesn’t seem like a framework issue, can you try and …”. I think that by simply thanking people, giving them context and appreciation for taking the time to create an issue, PR or whatever you can change things around.

    Dropping one liners to an issue is not very helpful for us on the other end, specially when they feel dismissive or rude. I’ve tried to help by commenting on some issues but is very discouraging when Graham intervenes so condescendingly (https://github.com/laravel/framework/issues/7671#issuecomment-76635939 “if you are not doing this my way you are doing it wrong”).

    Keeping track of all the issues across the organization sounds like a lot of work just for you so I agree you should rely on people you trust for this. However, I think those contributors should have “community” in their mind when they close or comment on an issue, instead of being right or getting the open issue counter down.

    I think it’s a really good thing that you are asking for feedback on this. I thank you for that and for your work on Laravel.
    Cheers!

    Reply
  6. I think you are good Totwell. I submitted a few PR. Some rejected some accepted. At the end of the day it seemed like you are smart and trying to make the best framework. So I can’t get mad if you reject.

    Reply
  7. Hello,

    I think it’s a good idea to start talking about this. I’m part of the people who believe the attitude in PRs/issues are most of the time negative.

    Here are a couple of links (non-exhaustive list as there are so many):

    https://github.com/laravel/docs/pull/1075
    https://github.com/laravel/docs/pull/1330
    https://github.com/laravel/docs/pull/1523
    https://github.com/laravel/docs/pull/1592
    https://github.com/laravel/docs/pull/1945
    https://github.com/laravel/laravel/pull/3603
    https://github.com/laravel/laravel/pull/3223
    https://github.com/laravel/laravel/pull/3232

    To compare with the Symfony repositories, the replies are most of the time in a positive tone. Comments like ‘Thanks’, ‘Thank you for your contribution’, can go a long way.

    Reply
  8. I’ve submitted a couple, and I’ll echo the comments from most in the thread. It was unpleasant, rude, and I felt like my contribution was unwanted.

    The worst part was Graham Campbell kept replying with only “cs”. I followed the (very sparse) style guide, which basically just said psr2. When I asked for guidance on what didn’t fit, so I could improve it, as it looked right to me, I was told to

    “Look at the entire source code”.

    I’m still shocked that someone said that seriously, and it wasn’t absurdist comedy.

    Reply
  9. I respect people who dedicate their free time to open source so any issues I have are posted on Github as a last resort. First, I meticulously read the official docs then post to Stackoverflow before raising an issue on Github.

    To my dismay, I’ve had the same Graham Campbell close them with no reason or with a rude unhelpful response. It sometimes makes me feel that I must be stupid and missed something but looking through his activity he has a track record of it. Yes, close the issues if they are not relevant but post a small explanation or link or something.

    Here are some of my issues:

    https://github.com/laravel/framework/issues/14321
    https://github.com/laravel/framework/issues/10630

    Reply
  10. I haven’t submitted a PR but just based on what I’ve heard here’s some ideas that might help both sides:

    *A list of answers to common rejection reasons with a more detailed explanation as to why. Also a good starting point for potential contributors to read. Almost like a FAQ of common rejection reasons that admins can link to instead of writing out long responses every time.

    *No more one word or emoji answers, either write a reason or link to the list answer from above. A little more time consuming but seems like that’s the number one gripe here and it’s an easy fix.

    *Probably have someone help Graham, even if it’s just following up on his decisions with a helpful explanation.

    That being said, I personally like that PRs have a high bar to be accepted, and I think it would ruin the framework to stop doing that just because someone’s feelings might be hurt. There’s a reason Laravel is so good and so popular compared to other php frameworks, and I think one big reason is that we have the right person making final decisions. We aren’t customers of Laravel and you don’t owe us anything. If you don’t change the way you reject PRs, yeah you’re going to discourage them in general, so maybe change that up, but don’t compromise on acceptance standards for them please.

    Reply
  11. Unfortunately I have had these experiences as well. I fully respect that my issue should be closed if it doesn’t apply, or goes against the phylosophy of the framework. However, dismissing and closing with little, snide, or no explanation is not helpful. I would like to understand the reasoning why my contribution was deemed unworthy, so that I can adjust my modus operandi in the future and hopefully contribute more effectively.

    In my experience, once Graham closes an issue, but you try to ask follow-up questions to get clarification, or correct an incorrect assumption, those items are not revisited or responded to.

    Unfortunately I don’t have any concrete examples handy, as it has been some time since I submitted a PR or opened an issue.

    I will say though, that some PRs and issues I have submitted did get addressed, which is good. And I have opened some PRs and issues that probably weren’t valid, I recognize that as well.

    I still think Laravel is the best framework out there (for me, it fits my way of thinking the best), and I’m very greatful to have it as a resource! Thanks for listening to what the community has to say, Taylor, that’s huge!

    Reply
  12. It might be worth it to create an issue “triage team” of 4-5 people that can monitor the issues section and help determine if they are just user error, an actual bug, or a feature request and have the ability to categorize as such or create a PR on their own to fix the issue.

    There is always going to be a gap for new users who are too afraid/inexperienced to confidently create a PR so maybe we make a team to help out with that process? That would lighten the issues load and give you something more concrete to look at instead of “this doesn’t work”.

    Reply
  13. I’ve submitted a couple of PRs to Laravel, but haven’t had the effort to the past few months after taking on a new role as senior developer, and the fact I’d have to go through the almighty gatekeeper that is Graham Campbell.

    I love the framework and using it, but tying to contribute and submitting a PR only for Graham to close it—some times without an explanation—is infuriating and demoralising. Then to try and get _reasons_ out of Graham that aren’t snappy and dismissive is like trying to get blood out of stone. They’re essentially, “Because.” Coincidentally, the PRs that Taylor has approved were done so without fuss, or after constructive criticism.

    Reply
  14. Just get rid of Graham Campbell. He’s not helpful. You need to elaborate to be helpful and he appears to refuse to elaborate.

    Reply
  15. I’ve fallen for Laravel not only for the awesome code, but also for the nice, friendly and safe community around it. I started using it around version 3 when (besides Taylor) guys like Daylee Rees where the face of this community. Never was I afraid to ask a question. Everyone was really helpful. It turned Laravel into my full day development environment.

    That all stopped when I bumped into Graham. Never have I bumped into such an condescending style of feedback. No respect whatsoever.

    For me, he turned Laravel from an all day experiment and work project to a do-what-have-to-be-done framework and forced me to get my development excitement in other dev segments.

    Not saying he’s a bad person. I don’t even know him. But with the wrong tone you can completely destroy someone’s passion. He did just that.

    EDIT: Maybe a separate issue: But I do have the feeling this is web development. I follow a lot of developers (Web, App and Embedded) on Twitter. Condescending behavior seems to be a big issue for web developers.

    Reply
  16. I have happily contributed a few PRs to the framework. Some of those have been merged or closed with meaningful feedback, but sometimes I’ve felt that the communication was poor. This PR for example https://github.com/laravel/laravel/pull/3287, which may not be critical or significant, but a minor improvement IMO, was closed without any comment, even when I asked the reason. The same happened for this similar PR: https://github.com/laravel/laravel/pull/3286. Talking about the issues, I’ve had one closed without a proper explanation: https://github.com/laravel/framework/issues/9196.

    Overall I agree with most of the commenters here, there is a genuine will from the community, but Graham has not been very positive.

    Reply
  17. I’m a writer, programmer, instructor and have written and delivered programming courses for years. I’ve also written and collaborated on software manuals, api documentation and user documentation.

    I have found a number of relatively minor issues to unfortunate omissions within the Laravel documentation, and keep my own copy of it for editing and use. I delve deep into code before and during documenting, and I have a good track record of satisfaction.

    Yet when I ran through the PRs for the documentation, and other PRs, I felt that the general attitude was negative. At least at the time before I gave up caring about it. I don’t fault Otwell for this beyond the fact that he is the defacto project manager. I’ve never felt that he is terribly dismissive, but there are others that I will not name.

    It left me with the impression that the request for PRs for documentation and other things is mostly for appearances sake, as though PRs were a form of insult to the collaborating team. My experience and attention to detail notwithstanding, I am left with the feeling that it is simply best not to contribute unless you are in a certain circle of people. It seems like a closed system to outsiders.

    Reply
  18. > We can make some changes where Graham can still contribute in a very valuable way, just perhaps not as the only person doing front-line issue support, which is probably better suited for a team of people that is more gifted with “customer support” type skills.

    I think this is an excellent idea and good news. I have no doubt that he is a highly intelligent and knowledgeable programmer, and it’s admirable that he gives his time to help with Laravel. But I’ve personally been frustrated by dealing with issues that he dismissively closed without explanation, or a very unhelpful one. It’s been a while since I’ve dealt with that, but it sounds like it may still be an issue.

    I think moving Graham to other valuable tasks and bringing on someone else to handle issues would be a very good idea.

    Reply
  19. I have nothing technical to add but just want to say I am upvoting because this sort of transparency is so vital to the community, potentially creating trust as it will if there is follow-through and I’m so glad to see it happening. utotwel, so glad to see you are big enough to go this route.

    Reply
  20. I love this post. Nothing to add, but I think the steps you’re taking (trying to get more folks on-board with issue review) are in the right direction.

    Reply
  21. Honestly, I stopped trying to contribute because of Graham Campbell. He might be right about my PR sucking, but the way he comes across is very offputting.

    Reply
  22. > I think when the people reviewing issues are overworked (Graham is a full-time student, intern, etc), we are going to get the short, terse responses that frustrate people.

    I don’t think it’s fair to characterize Graham as being “overworked.” He actively brags about being “the most active user on Github” (see [his website](https://gjcampbell.co.uk/) and [CV](https://cdn.gjcampbell.co.uk/cv/2016-07-23.pdf)). If Graham is overworked, *that is his problem*. He should back off and hand the reins over to someone else.

    But I don’t believe he’s overworked. I think he enjoys “being active”, which I imagine is counted by having the most comments and the most PRs closed and the most commits, *none of which are indicative of quality*.

    He may know “a lot” about PHP, but I haven’t seen much evidence of that. Most of what I’ve seen in the last year or so from Graham are abrasive, rude, arrogant comments.

    I’ve been an active contributor in the #laravel IRC chat room for the last 6 months, and I understand how hard it is to deal with people who come in and ask stupid questions or who come in and have absolutely no idea what they’re talking about. You have to pick and choose who to help. You have to have a lot of patience. You have to be able to calm down and be compassionate and understand that not everybody you’re talking to knows as much as you do about PHP or Composer or namespaces or MVC frameworks or basic OOP principles. You have to be willing to mentor them and point them in the right direction.

    If they’re in over their heads, I don’t say “you’re wrong, go away.” I say, “Hey, it sounds like you need to brush up on some of the basics. Why don’t you check out some Laracasts tutorials, and then come back and we’ll chat.” Those two sentences took me maybe 5 extra seconds to write, and now this person that I’m talking to has the opportunity to get excited about the Laravel community and the platform as a whole.

    There’s a guy who has come into the #laravel chat every day for at least 3 months now. He’s a noob. He has no idea what he’s doing. But he comes in every day, and he tries really hard. And I find that admirable. It’s frustrating to have to explain namespaces to him for the 4th time in two weeks, but he tries. And he’s enthusiastic, and he goes out and tells his friends that the Laravel community is awesome, and then we get a bigger, more robust community. I, and many others in the channel, take the time to help, rather than simply say “you’re wrong” and kick them out.

    And, by the way, I have a full time job, do consulting on the side, and spent the last year planning a wedding, yet I can find the time to mentor and support those who are willing to learn and contribute. (Another reason the “overworked” argument falls flat for me.)

    Graham’s behavior is toxic to the community in ways that very few other active contributors’ behavior are. He may very well “know **a lot** about PHP, Composer, and the ecosystem as a whole”, but knows absolutely nothing about building a sustainable community that grows together.

    You, on the other hand, have done an admirable job, Taylor. Seriously, the Laravel community (excepting Graham) is fantastic. But if you keep Graham around like this without enforcing some sort of behavioral improvement, then it’s going to get harder and harder and harder for things to improve and for the community to grow organically.

    Think about it this way. Of the 55 comments that you’ve received here as of this post, at least 50 of them have mentioned Graham as the principal source of frustration.

    If I owned a restaurant, and 55 people came up to me, the owner, and gave me feedback about the store, and 50 of those people told me the manager was a jerk, was rude, and refused to accommodate their orders, there’s a fantastic chance this manager wouldn’t be working at my restaurant much longer. This situation is a little more complicated than that, but the analogy is still relevant.

    Reply
  23. I’ve submitted a few (tiny) pull requests but I have had the benefit of being to quickly chat with you before sending them up.

    I think people are being pretty harsh about Graham but it is true that people need to feel comfortable submitting patches, and I wont disagree that he can seem pretty harsh.

    To be fair though, Graham does do a job of policing a lot of issues that aren’t really Laravel issues. I scan the issues and see a lot of people trying to submit code they “think” should be in Laravel, or they are asking general questions.

    Graham also tries to get people to tag the php version and things that many people leave out of the issues. Honestly I think Laravel needs to have some volunteers or core contributors that are willing to police the issue tracker which isn’t always a fun job.

    Reply
  24. First a big **thank you** for being open to this issue /u/utotwel

    I literally posted about this only a few days ago (and nice to see you responded to the parent comment there too):
    https://www.reddit.com/r/laravel/comments/4tw2wi/laravel_seems_pretty_well_structured/d5lwnzh

    I’m not going to add anymore fuel to the GC fire, you have plenty already. I have tried to submit detailed issues (closed for no reason). I know issues are tricky, they end up becoming a support centre (I opened the issue in spark’s repo regarding keeping the issues a place for issues and not discussion). But I feel like my closed issues, especially considering I am not just reporting “this ain’t working”, but actually digging into the source and finding the reason for the bugs, deserves more than being just closed.

    I do want to add, not everyone contributes in the same way, I’m not active on chat/github, but I do try to help out on stackoverflow’s laravel tag daily, with dozens and dozens of answers – especially focusing on newer laravel users to the ecosystem. I would really like to contribute to laravel directly, even just documentation, but personally it’s come to a “why bother?”.

    I’m an experienced dev, with close to 10 years of real life industry experience – do I want to be shot down by some young snot that clearly has near zero real world insight.

    I will continue to support laravel the best I know how, subscribed to spark, stackoverflow, etc

    Thanks again for taking the time to be open to improving your organisation.

    Reply
  25. The #1 barrier for me is there’s no way to get feedback about whether an issue will be accepted or not, or if the proposal is even valuable. Given the behavior I’ve seen from GC, my instinct tells me that there’s a high chance the PR will get dismissed outright.

    I don’t want to put potentially dozens of hours of work into a new feature (or even a couple hours worth of work into a minor improvement) if it’s just a roll of the dice as to whether or not it will be accepted.

    I get that some PRs are likely abysmal and need to be rejected without an explanation, but the more competent contributors are often the ones with the least amount of time on their hands, so there should be some way of “green lighting” a proposal or converting an issue into a “needs doing” status that anyone can pick up.

    Reply
  26. I think /u/totwel is giving /u/grahamjcampbell a bit of a free pass by trying to explain his rude behavior. I understand he is trying to be diplomatic and not throw him under the bus after all his contributions. However, judging by the comments here, it’s pretty apparent that his conduct on Github has been hurting the Laravel brand.

    I hope Graham reads this thread and take a long hard look at himself and thinks about how he conducts himself with other people. Especially since he may be meeting some of them at Laracon US.

    Being a good coder, being busy, etc does not give you the license to be abrasive to people.

    Reply
  27. What unbelievable cry babies in this thread. Graham does a fine job managing issues and PRs – you can’t take someone being rude about your code? It is stunning how apparently weak the community is: “Graham was rude so I won’t contribute to Laravel again.” Genuinely pathetic behaviour! His comments may be terse but to get so upset about them is bizarre.

    Reply
  28. A bit late to the party, but I reckon I should throw in my 2¢ here regarding GC.

    Granted, I used to (try to) contribute to Laravel before. In fact, my first PR ever was for Laravel IIRC. Yes, I had to deal with the “Graham firewall” right from day one. And yes, I got so disappointed and maybe even frustrated. WTF Laravel? If the only collaborator you have is this dismissive/arrogant/defensive/toxic to work with, why the fuck should I contribute again?

    But then, I authored several projects on my own, some of which are lucky enough to gain decent popularity, and I started to find myself in the same shoes. Imagine you have to scan hundreds of issues a day. Imagine most of them are actually very dum… erm, basic questions. Imagine no one bothers reading the contributing guide which is always there and which has been reminded of a thousand times. Imagine each and every one of them considering their issue the most critical on earth and demanding full, instant, notice. Imagine having to read awful code while holding a very specific set of high standards. Imagine you’re Graham, basically. I’m sure you’ll be more understanding then.

    Don’t get me wrong, I’m not defending Graham. I don’t know him personally – the best we had is some GitHub/Twitter exchanges. Again, most of the feedbacks we have here are correct and constructive. But I’m against “getting rid of him,” not even from the “issue police team,” as some of us here have suggested. Graham is a very talented developer and collaborator, whose contribution into Laravel is undeniable. Having someone to help him is the best approach here IMHO.

    P/S I’ve realized I’m just echoing what Taylor edited, but I’m posting this anyway – maybe a this can somehow contribute to the decision regarding the framework’s collaboration path.

    P/S 2: I’ve stopped contributing to Laravel since, but this has nothing to do with Graham; it’s just me getting too busy. In all honesty, I do believe having him as the “issue police” forces contributors to write better code, which is only good for the project (and the contributors themselves, if I may add).

    Reply
  29. Although I’ve had frustrations and concerns in the past (http://twitter.com/Omega_/status/622075371056312320?s=09), overall I’d say Graham has done a good job preserving the line between framework and user space code that Taylor is trying to maintain.
    I also know for a fact that Graham is more than capable of green lighting features (https://github.com/laravel/framework/pull/9746#issuecomment-124848912)

    I don’t want Graham in a position where he now can’t assert himself without being type cast. Being critical is his gift and after this thread, there will be people who will try to resort to politics just to win a dispute where he is involved.

    Taylor, I think one very subtle issue during triage that I’ve had in the past is not getting the assistance needed to align terminology with the project, despite best efforts to use documentation as a baseline.
    In that situation, the number one component tends to be eloquent. So what might really go a long way is to have an attitude of being a co-designer with anyone who opens a ticket on the project. Put that little bit of extra time into vetting not just the idea or commit, but also your own assumptions. This applies to everyone, not just Graham.

    I hope that he continues doing what he does best and if after today it’s with a little more polish, then I’d say that’s fine – but only if it’s not at the loss of quality.

    Reply
  30. I actually find Graham much friendlier than Taylor in my experience. Looking at this thread now, it seems I’m unique

    Reply
  31. I haven’t seen this mentioned here yet, but looking through your current issue list there seems to be no use of labels. Having a well defined list of labels and then assigning them to issues has a number of benefits.

    Firstly it provides feedback to the issue creator,
    Secondly it allows for curating/filtering of issues

    The problem is defining a good set of labels to start with. 😉

    Reply
  32. I too have had to hack through the “Graham firewall”. While all of my PR’s were ultimately merged, I feel they might not have been had I not **defended** them.

    In general, I understand what your *Edit* is saying about him. In our industry, you will sometimes look past personality differences for someone who “knows a lot”.

    In this specific case, however, Graham is not just representing himself. He also represents Laravel. If he’s over-tightening the contribution process in any way, then he’s choking your open-source project.

    Reply
  33. I am an absolute noob at Laravel- but I can attest to the general “experienced dev only” vibe to most of my posts I have made on forums. There is a general feeling for a beginner that you still need to learn a lot before you can try this. The official Laravel docs often breakdown for an absolute beginners and one is sent down a Google search rabbit hole

    Reply
  34. Hi /u/utotwel

    Just curious to what actionable outcomes came from this discussion. I am trawling the issue tracker now for a solution to something I can’t quite figure out, and issue after issue (granted I am looked at only 5.3 tagged items) are closed without reason – even noticing comments like “I think @GrahamCampbell may have closed this prematurely.” (https://github.com/laravel/framework/issues/15005)

    Edit: Side note – themsaid seems to be doing an excellent job.

    Reply

Leave a Comment