Guys, Rafael was slowed down by a new absorbing $dayjob. His contributions have remained a hot item and yes, we shouldn't close anything that is being discussed. As for 2 LGTM being discouraging for new contributors; I think that is up to us. They need one reviewer even without defined process to have their code merged, github, review-board or otherwise. As a reviewer it is my (and your) responsibility to draw attention to new contributors which is or at least can be an extra welcome greeting. So in conclusion we can guide any new contributors but only as we made first contact. The 2 LGTM requirement is actually a stimulants in my view. Maybe not as much for them as for ourselves
0,02€ On Wed, Aug 26, 2015 at 12:35 PM, Sebastien Goasguen <run...@gmail.com> wrote: > > > On Aug 26, 2015, at 12:20 PM, Rohit Yadav <bhais...@apache.org> wrote: > > > > Hi all, > > > > I’ve identified few issues around the recent changes that I don’t know > > how we can fix or improve but I hope to get feedback from the > > community. > > > > I understand that you may disagree with what I’m sharing which is > > alright, even in your disagreement I hope that you don’t take an > > offence on that, that is certainly not my aim. I personally want to > > the community to be felt welcoming so that we can attract and retain > > new contributors and have a nice environment for everyone. > > > > Some observations and comments: > > > > - Generally those of us who have worked for long in the community or > > have colleagues from dayjob working in the ACS community - we have > > better chances in getting their PRs merged; for new contributors this > > pattern is not encouraging and certainly not welcoming if their PRs > > get closed. > > > > - The recent drive to use Github PRs seems to be really working great > > for us, but still the requirements of at least 2 +1s/LGTM, unit tests > > and pedantic bike-shedding has cost us new developers/contributors and > > kills the joy of programming for some; for experienced and > > commercially backed developers this makes sense. I personally try to > > be pragmatic and lenient on code reviews as long as smoke tests > > (Travis) pass. > > > > - Contributions are process-oriented that cost time and effort; there > > have been initiative to satisfy the tool but not the human, and not > > optimizing on developer time. > > > > - What should we do to get more developer contributors and how to > > attract hobbyists or casual contributors. > > > > Rohit, that’s a very valid point. > > Personally, I don’t think we should close PRs that may be valid but just > not ripe for a release. > > Your recent comment on Rafael PR about embedded jetty for instance is a > good example. I can’t review this, and since I don’t run CloudStack in prod > I don’t want to force things that operators may not want or may not be > ready yet. So this PR got stuck waiting for Pierre-Yves who talked about it. > Did this slow down Rafael contribution I don’t know, we should ask him. > > Maybe we could merge that type of things, just not in master. > > Can you point us to other PR that you saw that made you write this note. > We could all have a look. > > > > Regards. > > -- Daan
