Thanks Gerard for your email and for getting this conversation started in earnest and for the responses. This is a very important set of conversations for us all to be having. Christina Koch recently facilitated a community call focused on maintenance and just put up a [blog post]( https://software-carpentry.org/blog/2017/10/maintainer-follow-up.html) about that conversation yesterday.
On the Data Carpentry side, we've also been exploring a new model of lesson maintanence that is quite similar to what Titus and Abigail have mentioned here. This new model has three parts: 1) A large body of maintainers for each lesson to lighten workload. 2) A "looks good to me" model of contributorship - where anyone can review a PR and Maintainers commit to merging anything with two or more favorable reviews. 3) A curriculum advisory council which offers the Maintainers high level feedback on the direction of the curriculum. If you're interested, there's more information about how we're implementing this model for Genomics [here] ( https://docs.google.com/document/d/1NJrK6so3Vct4SyAZGlQWCi4dfAm2ICT1-oeyP6tcMgg/edit) and [here]( https://docs.google.com/document/d/1E9oigBUNDvN3luIdzKA6jB7P2VTRLs3EJj5_nmUrfNM/edit ). We're just trying it out, so we're figuring out how well it's working and will provide updates. The idea is that as we see what works and what doesn't and get feedback, we can use this as a model to put together a more sustainable maintainer approach for lessons. We started an issue on [Carpentries conversations]( https://github.com/carpentries/conversations/issues/15) and are really looking forward to hearing more from Maintainers and other community members about what has and hasn't been going well with our current maintenance model and what we can do to help make this an enjoyable and rewarding experience for everyone involved. Best, -Tracy On Wed, Oct 4, 2017 at 6:34 AM, C. Titus Brown <[email protected]> wrote: > 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
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
