On Wed, Oct 04, 2017 at 03:20:52PM +0200, Erik Bray wrote: > On Wed, Oct 4, 2017 at 8:57 AM, Gerard Capes > <[email protected]> wrote: > > Dear Software Carpenters, > > > > I've had a few PRs open on SC lessons for around 2 weeks. Two of them have > > not received any response at all. One of them had a brief conversation, > > ending with me asking for clarification as to what edits would be required > > to have the PR merged. > > > > Now I know the maintainers are volunteers (I am also a lesson maintainer), > > and have other priorities, but it's frustrating to go to the bother of > > submitting a PR only to get nothing of use back. > > > > So I'm asking two things: > > > > Should Software Carpentry have a response time, where a maintainer should > > assign the PR within 2 days, or at least comment to indicate their expected > > response time? This is the approach I have been taking, but I must concede > > that I get far fewer PRs on the lesson I maintain. > > What can PR submitters do in my situation? > > I don't have too much to add on what April already wrote, but this is > a perennial problem on volunteer-based projects, or even on project > that have paid contributors (a few projects I work on have paid > contributors, but who are still stretched too thin to always be timely > in reviewing PRs). As such, I've had tasks that should have at most > taken a few weeks take *months* just due to the lack of time on the > part of people qualified to review my work. > > I have very mixed feelings about all this. I'm 100% in favor of a > general requirement that all changes go through a review process. But > perhaps there should be a time limit after which at least *trusted* > contributors (by some measure) should be able to merge changes that at > least haven't already received negative response. This can be > problematic too though. Because sometimes no response just means > literally no one else has seen it. It might be nice if GitHub had a > way to loudly call attention to PRs that have yet to even be given a > +1 or -1 by someone...
Hi Erik & others, tl;dr? (a) add maintainers liberally, (b) forgo review, (c) trust people. So, we ran into this problem on the khmer project a while ago - it's unreasonable to expect grad students and postdocs to pay regular attention to code review. Three approaches we've tried/are trying: --- first, add maintainers liberally, e.g. use something like the Pull Request Hack to give people responsibility when they demonstrate capability: https://felixge.de/2013/03/11/the-pull-request-hack.html --- second, use something like Lazy Consensus to forgo review after some period of time, http://nowviskie.org/2012/lazy-consensus/ by saying "well, if no one cares enough to comment after a week, go for it!" --- third, pay someone to review pull requests and fix bugs. We pay Tim Head (@betatim) to "watch" our github repos. This works quite well and (on the scale of things) is quite inexpensive, but is still some $$. --- I don't think forgoing review is a good idea, especially with the current way lessons are managed (merges are essentially "live" immediately, with no staging area/review before release). So #2 is not a good idea for SC/DC IMO. From my perspective, I'm not sure there's a hurry here, other than (apologies) the impatience of people who just want to get on with it. Understandable, but not something that can be fixed easily! best, --titus -- C. Titus Brown, [email protected] _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
