<div dir="ltr">Let me add a couple of points.<div><br></div><div>First, I have noticed is that:</div><div><ul><li>Contributors do not make a habit out of checking pull requests;   I know I don't<br><br></li><li>GitHub is too chatty, so everyone I know just filters notifications.   I suspect this is why anyone being assigned issues just ignores them.   There is just too much traffic.<br></li></ul><div>Mono historically took patches from the mailing list.   Not from github pull requests.   So culturally, this was never aligned, it just kind of happened, and we kind of never evolved or changed with it.</div><div><br></div><div>Perhaps what we need is for these pull requests to be posted here on the list and discussed here on the list.   </div><div><br></div><div>I think this is better, as we have a place where the larger community can comment on patches.   It would surface the discussion to everyone, as opposed to limiting it to those that happen to stumble on the pull requests or visit the page.  </div></div><div><br></div><div>Second, I think there is a room for folks to contribute to this process, even if they are not committers, or active contributors.  Someone that could shepherd a contributor and the contribution.   Many of the patches do not meet the basic requirements for a patch review, and we end up wasting valuable time on them.  </div><div><br>Things that we would need:</div><div><ul><li>An actual detailed explanation of the change.   Many patches are submitted with very little information.<br><br></li><li>Test cases: many patches are contributed without tests to show the problem as it is today nor to ensure that the code does not regress.<br><br></li><li>Style: many patches contain white space changes, unnecessary refactoring and changes that are not suitable to be contributed.<br><br></li><li>Rebasing: many patches are contributed and fixes are piled on top of each other.   The result is not suitable to be merged as it would essentially pollute the commit history.   So someone that can assist the less sophisticated among us to "squash" the commits would help.<br><br></li><li>Patches that change the surface and contain no documentation.<br><br></li><li>Steering developers to discuss the patches on the mailing list and following up directly on the mailing list with the reviewers to ensure that the patches can be merged.<br></li></ul><div>I think the above would help us tremendously to accelerate the patch review process.</div></div><div><br></div><div>Miguel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 16, 2014 at 4:30 PM, Miguel de Icaza <span dir="ltr"><<a href="mailto:miguel@xamarin.com" target="_blank">miguel@xamarin.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">There is no point in starting a discussion where you are going to cherry pick facts for the sake of your argument.<div><br></div><div>As for contributing, which one of *your* pull requests have been pending and not being reviewed?</div><div><br></div><div>Because we would like to provide you with the valuable feedback that you need to turn these contributions into patches.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Miguel</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 16, 2014 at 4:25 PM, David Nelson <span dir="ltr"><<a href="mailto:eatdrinksleepcode@gmail.com" target="_blank">eatdrinksleepcode@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><span><div>"Long term, the ideal situation is one where we can give more people 
commit rights, and review rights.   But until we have developed the 
skills in the community that are needed, we will continue with the 
current setup."<br><br></div></span>This seems to be a chicken-and-egg problem. We need to christen more reviewers in order to handle the volume of PRs and keep the Mono community engaged; but in order to gain enough confidence in a contributor to make them a reviewer, their requests need to be reviewed! How can we "develop the skills in the community" if requests routinely sit idle for over a year?<br><br></div>I got really excited about contributing to Mono about two years ago; I love .NET and C#, but many of my colleagues (not to mention many of the companies for which we consult) are staunchly anti-Windows; I wanted to help demonstrate that Mono could be a viable alternative for non-Windows development. But research into the state of the community left me disappointed: PRs are ignored, roadmaps are horribly out of date, builds are constantly broken...in general, not an environment that encourages community members to contribute their valuable time.<br><br></div>I understand the desire to maintain a high standard for contributed code, and I support maintaining that standard; but a process MUST be developed that encourages community contribution rather than stagnating it.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Oct 16, 2014 at 3:31 PM, Miguel de Icaza <span dir="ltr"><<a href="mailto:miguel@xamarin.com" target="_blank">miguel@xamarin.com</a>></span> wrote:<br></span><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Greg,<div><br></div><div>The best approach is to stay engaged in the pull requests and bring the attention to the mailing list for us to discuss.</div><div><br></div><div>Long term, the ideal situation is one where we can give more people commit rights, and review rights.   But until we have developed the skills in the community that are needed, we will continue with the current setup.</div><div><br></div><div>The bar for mono is high: we can not just take any code and distribute it, since the impact of mistakes is large.</div><div><br></div><div>To give an example, even new Xamarin employees that are hired to work exclusively on the runtime are working through pull requests, and they also have to wait for some of the more senior people to review and approve the patches.   We have very nice fixes that we still postpone until we have the bandwidth of doing a full review.</div><div><br></div><div>In the meantime, if you need quick hacks, you can always fork Mono and distribute your forked version with your changes.</div><span><font color="#888888"><div><br></div><div>Miguel</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 16, 2014 at 3:27 PM, Greg Young <span dir="ltr"><<a href="mailto:gregoryyoung1@gmail.com" target="_blank">gregoryyoung1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This topic has been brought up in a ton of other threads I just want<br>
to centralize the topic.<br>
<br>
I have felt the pain many others have discussed (6-12 months for an<br>
accept of PR, we actually had a separate distribution of mono for a<br>
while).<br>
<br>
Is there background on the issue?<br>
What are the issues that are involved from a xamarin perspective?<br>
How can the community help?<br>
<br>
Cheers,<br>
<br>
Greg<br>
<span><font color="#888888"><br>
--<br>
Studying for the Turing test<br>
_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div></div></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>