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