wking
commented
10 years ago Much of the lessons/ content I referenced in my original comment here is now gone (since e958d8e, Removing legacy lesson material, 2014-04-07), but we are still missing the explicit maintainer listing or per-lesson branches that will help us avoid similar situations in the future. For example, we now have novice/extras, which is the sort of thing that I imagine will be hard to maintain without dedicated minders 1.
There was some discussion about explicit maintainers for bc content on
sciencelab today, and to aid discoverability I thought I'd record the
references to earlier discussions:
- 2013-06: I floated an explicit list of maintainers in a restructured branch of the old swcarpentry/boot-camps repository, asking folks to volunteer to maintain individual lessons [2,3].
- 2013-10: I floated the idea of per-lesson branches [4,5], which have the benefit that there is only one maintainer per branch (whoever owns the repo), and that it's easy to collaborate if multiple folks want to chip in (via pull-requests or shared access) or re-assign if the original maintainer slacks off (just fork their repo).
- 2013-11: @ethanwhite pushed back against the idea of himself as the maintainer of bc's intermediate material 6. Later in that thread, Greg pushed back against SWC-employed maintainers citing funding constraints 7.
On #sciencelab today, @r-gaia-cs proposed listing explicit maintainers for each lesson, and @acabunoc and I approved. @gvwilson is apparently also moderately positive:
13:25 < abbycabs> Just ran into Greg in the kitchen - there's on later this month 13:26 < abbycabs> he's for maintainers -- he says it hasn't worked well in the past, though. But he's optimistic with the larger community
I've looked through my email archives, but I haven't been able to turn up a more detailed discussion of the structure or issues behind past attempts at this. If anyone else has additional references to past discussions or implementations, please add them here so we can avoid repeating ourselves ;).
id:20130626111957.GZ29799@odin.tremily.us
id:20131021183505.GD22986@odin.tremily.us
rgaiacs
gvwilson
On Sat, Mar 29, 2014 at 06:18:50AM -0700, Ethan White wrote:
There's a lot of stuff already in this repository that doesn't get much love (e.g. the whole
lessons/tree?). Is that because the material is all polished up and stable? Or because folks have lost interest in using and maintaining it now that there's new novice/intermediate material? I imagine there are bits of the lessons/ on both sides of that continuum, but I don't know which bit is where. If I guesslessons/misc-installation/tutorial.mdis in the “nobody uses this” camp, do I just submit a PR to remove it and wait for complaints? How long to wait before silence becomes implicit approval?Having explicit maintainers (and there could be several for a given lesson) means we know who cares about the material. When a lesson's last maintainer steps down, they can file a PR removing the lesson, and we can cook that while waiting for someone else to step up. After a month without anyone stepping up, I'd merge the removal (it's all in Git if someone wants to resurrect it later).
Even with explicit nominal maintainers, it can be hard for non-maintainers to differentiate “stable” from “unmaintained and bit-rotted”. However, having a handful of folks to poke (“you guys haven't touched $x in a while, are you still using it?”) is much easier than trying to poke the whole SWC community ;).
This loops back around to #102, which avoids the problem completely by distributing maintainership. If you merge my git://tremily.us/swc-setup-installation-test.git or git://tremily.us/swc-setup-windows-installer.git, you can safely assume that I've stepped up to maintain that material. If you message me about a bug, and I don't get back to you in a reasonable time, you can fix the bug locally (now you are the maintainer) or dump my branch (because you're the sole stakeholder in your multi-tool/lesson assembly).
Since we're not interested in the #102-style workflow for the novice/intermediate lessons (and lots of other stuff under
lessons/?), we need an alternative approach. If we do want to have explicit maintainers, it would be easy to list maintainers for sections of the bc tree in a new, top-levelMAINTAINERS.md. If we don't want explicit maintainers, what is the preferred procedure for removing obsolete material?