
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html><head><meta content="text/html; charset=utf-8" http-equiv="Content-Type"></head>I personally like this strategy, but as someone who is new to the project and has made only one PR (which was merged rather quickly), how can I help?<br>

<br>

This seems to really only concern those who maintain the code, leaving many unable to do much.<br>

-- <br>

James<br><br><div class="gmail_quote">On May 7, 2018 4:15:59 PM MST, Nyall Dawson <nyall.dawson@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Hi all,<br /><br />It's no surprise to anyone familiar with the QGIS project that we've<br />got an issue with the Pull Request queue. It's been slowly growing<br />over time, recently hitting over 150 open requests! It's a bit of an<br />embarrassment to the project (some of these PRs have been open for<br />years!), and is likely causing us to lose new contributors and code.<br /><br />The usual magic QGIS coding pixies did some work lately and squashed<br />the queue back below 100 requests. But the remaining ones are all the<br />difficult, unfinished or orphaned PRs...<br /><br />PR reviewing is hard. Not everyone can review every open PR due to<br />different familiarity with areas of the codebase. (Which is why I<br />don't think a funding grant to cover this will ever work<br />successfully). And no-one wants to be the 'bad guy" who closes an<br />unmerged PR representing someone else's hard work.<br /><br />So I propose a "32 by 3.2" sprint, where we ALL collaboratively aim to<br />reduce the PR queue to <32 open requests before 3.2 release.<br /><br />I think we could achieve this by:<br /><br />1. Adopting a hard-line approach to the older, orphaned PRs. Even if<br />they have some value or reflect real issues, if no-one is interested<br />in cleaning up the request to get it merge ready then we close it.<br /><br />2. Adopt a "open-one, close-one" guideline for core committers. Heck,<br />I think every core committer has at least 1 or 2 open PRs representing<br />various experiments and WIP in unfinished states. These should either<br />be finished off, or closed and re-opened when the work is actually<br />ready to go. And for test PRs which are "for comment only" I'd suggest<br />a QEP is more likely to get better feedback and is the more<br />appropriate place for this discussion of this nature.<br /><br />3. Closing orphaned or risky PRs which are targeted to 2.18 and which<br />have been fixed in master branch.<br /><br />4. Sharing the hard work so that the magic pixies don't lose their<br />magic powers :)<br /><br />Thoughts?<br /><br />Nyall<br /><hr><br />QGIS-Developer mailing list<br />QGIS-Developer@lists.osgeo.org<br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre></blockquote></div></html>