On Tue, Jan 17, 2017 at 02:25:43PM +1300, [email protected] wrote: > 1) Is this rendering of the existing shell-extras lesson content in > the new template of any use to SWC ? > If so, it's yours to keep (ha-ha!).
This is up to the shell-extras maintainers. > 2) If it is, what would be the process for introducing the new template > lesson into the SWC GitHub repositories ? File a pull request against [1] with your changes. > 2a) having downloaded the template lesson's gh-pages ZIP-file so as > to have a starting place, I've read that new lessons are created > by a GitHub Import, however, the shell-extras lesson that I have > isn't really a "user copy of a lesson" that I'm working on, > because there is no "upstream master copy", as yet anyway, > because the content is still over at the old site where it > hasn't been touched in a while. It sounds like it's not a new lesson either, it's an update to the existing shell-extras lesson. You'd use GitHub Import if you were creating a new lesson with a different scope than the existing shell-extras. > 2b) is SWC's idea of the "user copy of a lesson" repository one in > which the user hosts their ongoing development as a modified > version of a "master" lesson, or is the "user copy of a lesson" > repository just one in which a user would only place a finalised > lesson ? I expect both “active development” and “mostly complete” lessons would fall under the “user copy” phrasing. There's not really a clear line between those two cases anyway ;). > Either way, is it still expected that pull requests would be > made from the "user copy" to the "master" or would the user need > to maintain a branch mimic-ing the master, so that user-local > differences that wouldn't be worth propagating into the master > remain seperate from the master lesson? It's easier for maintainers if you file pull requests with the smallest atomic pivot you can make. For example, if you want to update shell-extras to use the current styles, that should be it's own shell-extras PR (without any content changes). If you want to update the template to allow local file:// use, that would be its own styles PR. If you want to change the lesson content, that would be its own shell-extras PR (without bumping the styles templating). Then the upstream maintainers can pick and choose which changes make sense to them. You can have a master branch in your repository which merges all of the separate atomic pivots, and you can use the site built from that in your own teaching. Then as your PRs are accepted upstream, you have less and less local work to maintain yourself. If any of your PRs are rejected upstream, you get to decide whether you want to drop the change or continue maintaining it locally. > 3) If I was looking to flesh out the "Working Remotely with SSH" > episode as a standalone lesson, how would that fit in with SWC > concept of lessons and episodes? > > 3a) Do you have any examples of a single, or a couple, of episodes > being taken from a lesson, and delivered by themselves, so, for > example, in my case, would the deliverer still maintain the > "Shell Extras" lesson title, but merely alter the episodes so > that they were all about working with the SSH protocol, and if > so, would they then still be consided as a "user copy" of the > "upstream master copy" ? It's up to the shell-extras maintainers to decide what's in-scope for them. For past thoughts on scoping that lesson, see [2,3]. If they think it's in scope, great. If they think it's out of scope, then your SSH-centered approach would be a new lesson (shell-extras-over-ssh?). This is just a special case of “you can carry any changes the upstream isn't interested in locally”. I'm not a maintainer, but I'd rather see the shell-extras episodes remain as indepedent as possible (so you can teach them à la carte). If that is also the shell-extras maintainer opinion, it would mean you have a new lesson. But I'd recommend optimistically filing a shell-extras PR to see how the idea plays, because there's no sense in forking off a new lesson if the shell-extras maintainers are comfortable with the direction you're heading. Cheers, Trevor [1]: https://github.com/swcarpentry/shell-extras [2]: https://github.com/swcarpentry/shell-extras/issues/1 [3]: https://github.com/swcarpentry/shell-extras/issues/3 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
