Skip to content
This repository has been archived by the owner on Jan 3, 2018. It is now read-only.

Split setup instructions #738

Closed
wants to merge 1 commit into from

Conversation

rgaiacs
Copy link

@rgaiacs rgaiacs commented Sep 24, 2014

Work in progress. Don't merge it yet.

This is an prove of concept to address #729.

@karthik What do you think?

Attend to address swcarpentry#729 by splitting the setup instructions to
make easy for instructor to find the file that he/she need to
edit.

Some changes in the README.md to make it smaller and creation
of README-LONG.md for the long version of instructions to
setup the bootcamp homepage.
@wking
Copy link
Contributor

wking commented Sep 24, 2014

On Tue, Sep 23, 2014 at 05:05:47PM -0700, Raniere Silva wrote:

  • Split setup instructions

-- File Changes --

A README-LONG.md (589)
M README.md (540)

I don't think the README splitting should go in the same commit as the
setup splitting. There's also some trailing whitespace here, which
I'm sure you just copy/pasted, but it's nice to clean it up while
you're touching it ;).

A _includes/setup/firefox-sql.html (27)

There are duplicate “instead”s here, copied from the original source.
An additional commit (or follow-up PR) to clean that up would be good.

A _includes/setup/skeleton.html (111)

Love it. For a follow-up commit, flags for the OSes would be nice too
;).

A _includes/setup/windows-editor.html (13)

Some of the text (e.g. “or have other tools like Git launch it for
you”) would be nice to adjust depending on what the workshop has
enabled. For example, once we get Mercurial setup instructions,
enabling Mercurial but disabling Git should replace the example editor
launcher. Food for follow-up commits.

And it would be even nicer if all of this setup knowledge lived in a
separate #102-style repository from all the lesson code, since there's
only a very weak link between them, but that's just me wishing ;).

@gvwilson
Copy link
Contributor

I'm -1 on this: we got rid of precisely this organization months ago because people didn't like it. (See @jdblischak's comment on #729.)

@wking
Copy link
Contributor

wking commented Sep 24, 2014

On Tue, Sep 23, 2014 at 05:58:09PM -0700, Greg Wilson wrote:

I'm -1 on this: we got rid of precisely this organization months ago
because people didn't like it. (See @jdblischak's comment on #729.)

See also #310 and #316. The comments there were just about duplicate
instructions (in the original #310 post). Links back to “the split
layout is confusing” arguments would be nice. I remember some of the
discussion, but I can't turn it back up now. Ideally there should be
a way to satisfy both @karthik and others who prefer the many-files
approach as well as folks who were confused by its intial
implementation. If we can collect that feedback in one place it would
be easier to try and see a way out.

@wking
Copy link
Contributor

wking commented Sep 24, 2014

On Tue, Sep 23, 2014 at 06:32:59PM -0700, W. Trevor King wrote:

Links back to “the split layout is confusing” arguments would be
nice.

Some of that discussion is in #415, starting with 1.

@wking
Copy link
Contributor

wking commented Sep 24, 2014

On Tue, Sep 23, 2014 at 06:57:57PM -0700, W. Trevor King wrote:

Some of that discussion is in #415, starting with 1.

1: #415 (comment)

The only discuss@ thread I've found so far is @jduckles request for
comment 1, but there were no replies.

My current feeling is that the single-file, no-template approach
(#316) helped folks avoid looking at templates (which could be
intimidating for folks unfamiliar with templates?). But since #415
we've had templates again, and folks haven't complained because they
can just tweak their 'lessons' config to enable/disable certain
blocks. No need to look at the templates anymore, unless you need
even more flexibility. I like this PR, because it makes it easier
to separate the template logic in the skeleton file, and keep the
install instructions each isolated in their own files. I think it
should be even less scary than the current approach, because folks
tweaking a particular set of install instructions won't even need to
see:

{% if page.lessons contains 'Bash' %}

{% endif %}

They'll just open up _includes/setup/overview-bash.html. That seems
more user-friendly to me.

@gvwilson
Copy link
Contributor

gvwilson commented Nov 5, 2014

@r-gaia-cs is this still relevant given the planned reorganization of the repo?

@rgaiacs
Copy link
Author

rgaiacs commented Nov 5, 2014

I'm closing this due the reorganization of the repo.

@rgaiacs rgaiacs closed this Nov 5, 2014
wking added a commit to wking/workshop-template that referenced this pull request Mar 11, 2016
…tions

Ivan brought this idea back up in maintainers@ recently [1].  I think
the last time it was raised seriously was [2], which has reasonable
links into earlier discussion.  The main argument against tags was
that it was too hard to find the source for a particular line you
wanted to tweak [3].  This commit restores our old liquid templating
to show/hide sections *without* splitting the sections out into
sub-files (e.g. bc#738 had _includes/setup/linux-editor.html).  If we
keep everything in the index file, we can have tags and instructors
can either adjust the tags or easily find/edit/delete as they see fit.

A few notes on the implementation:

* I've gone with double quotes in the YAML front matter for
  consistency with the other entries, but stuck with the original
  (from swcarpentry/bc) single quotes for the liquid conditionals.

* I've kept "check" and "VM" out of the default tools list to match
  the current display, but we may want to enable everything and write
  a stronger message about removing stuff you don't need to avoid
  repeating the problems we had with check being visible by default
  [4].  Because folks will have to tweak the tools list if they want
  to enable the "check" or "VM" sections, I've added comments at the
  beginning of each section pointing instructors back up at the YAML
  front matter.

* I've moved the "check" section out of the Python section, because
  while the tool doesn't currently test R packages, it does test Git,
  Bash, text editors, etc., and it could certainly be extended to test
  R if someone with R knowledge wanted to chip in (although it's
  harder to *run* the script on Windows without bundling Python) [5].

[1]: http://lists.software-carpentry.org/pipermail/maintainers_lists.software-carpentry.org/2016-March/000179.html
     Subject: Re: [Maintainers] Vote needed for setup instructions
     Date: Thu, 10 Mar 2016 12:05:33 -0500
     Message-ID: <CAJpTZ0DPYKgu2fbi6dZ3XvZVyed0MwmS-jTR-e-Y3uYoZKoctQ@mail.gmail.com>
[2]: swcarpentry/DEPRECATED-bc#738
[3]: swcarpentry/DEPRECATED-bc#729 (comment)
[4]: carpentries#278
[5]: carpentries#136 (comment)
wking added a commit to wking/workshop-template that referenced this pull request Mar 11, 2016
…tions

Ivan brought this idea back up in maintainers@ recently [1].  I think
the last time it was raised seriously was [2], which has reasonable
links into earlier discussion.  The main argument against tags was
that it was too hard to find the source for a particular line you
wanted to tweak [3].  This commit restores our old liquid templating
to show/hide sections *without* splitting the sections out into
sub-files (e.g. bc#738 had _includes/setup/linux-editor.html).  If we
keep everything in the index file, we can have tags and instructors
can either adjust the tags or easily find/edit/delete as they see fit.

A few notes on the implementation:

* I've gone with double quotes in the YAML front matter for
  consistency with the other entries, but stuck with the original
  (from swcarpentry/bc) single quotes for the liquid conditionals.

* I've kept "test" and "VM" out of the default tools list to match the
  current display, but we may want to enable everything and write a
  stronger message about removing stuff you don't need to avoid
  repeating the problems we had with the installation-test link being
  visible by default [4].  Because folks will have to tweak the tools
  list if they want to enable the "test" or "VM" sections, I've added
  comments at the beginning of each section pointing instructors back
  up at the YAML front matter.

* I've moved the "test" section out of the Python section, because
  while the tool doesn't currently test R packages, it does test Git,
  Bash, text editors, etc., and it could certainly be extended to test
  R if someone with R knowledge wanted to chip in (although it's
  harder to *run* the script on Windows without bundling Python) [5].
  The new header separates the test section from the previous section.

[1]: http://lists.software-carpentry.org/pipermail/maintainers_lists.software-carpentry.org/2016-March/000179.html
     Subject: Re: [Maintainers] Vote needed for setup instructions
     Date: Thu, 10 Mar 2016 12:05:33 -0500
     Message-ID: <CAJpTZ0DPYKgu2fbi6dZ3XvZVyed0MwmS-jTR-e-Y3uYoZKoctQ@mail.gmail.com>
[2]: swcarpentry/DEPRECATED-bc#738
[3]: swcarpentry/DEPRECATED-bc#729 (comment)
[4]: carpentries#278
[5]: carpentries#136 (comment)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants