Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have different worksheets for different roles #21

Closed
acdalal opened this issue Nov 18, 2016 · 3 comments
Closed

Have different worksheets for different roles #21

acdalal opened this issue Nov 18, 2016 · 3 comments

Comments

@acdalal
Copy link

acdalal commented Nov 18, 2016

It was confusing working between two worksheets, one with (sort of) instructions and one with commands. There was also a TON of information on both sheets. It might be easier to follow along and figure out what each person is supposed to be doing if there was a different worksheet with just the instructions for each particular role. So, for instance, the maintainer would get the "maintainer" worksheet with just the "maintainer" commands. When you are waiting for someone else to complete something, your worksheet can indicate this.

You could always make the full set of worksheets available to students at the end of the exercise.

@StoneyJackson
Copy link
Collaborator

This is great feedback. Thanks!

Before fixing anything, I would like to clarify and verify the problem. I'm hearing three issues:

  1. Having to work with two worksheets is confusing and annoying.
  2. There is way to much to read.
  3. It's hard to follow a role.

Does this sound right? Please feel free to add, remove, and/or adjust.

@acdalal
Copy link
Author

acdalal commented Nov 19, 2016

Yes, those 3 issues are exactly what I meant. Thanks!

@StoneyJackson
Copy link
Collaborator

Cool... now let's explore some solutions:

Solving R1:

  1. One script per role with all commands inlined (as suggested by @acdalal).
  2. One script with all roles and all commands inlined. Let's call this a "play".
    (I thought about hyperlinking, but that can get equally confusing as you flip between pages. So I ruled it out.)

Solving R2:

  1. Judicious editing?
  2. Inlining commands could be customized for each situation, removing extra steps that might be needed in general.
  3. Maybe this activity is just too big and should be split into separate activities. Then each activity would have a more manageable amount of text.

Solving R3:

  1. A script per role with inlined commands.
  2. A single script with all roles and commands inlined: a "play".
    (I thought about hyperlinking, but that can get equally confusing as you flip between pages. So I ruled it out.)

Other solutions to these?

It looks like there are two major solutions to R1 and R3. A little pro-con to decide between these is probably in order.

For R2, we might want to analyze how much editing is possible to reduce the text. And if that doesn't look like it will buy us much, then we think about splitting into smaller activities.

@StoneyJackson StoneyJackson mentioned this issue Jun 6, 2018
11 tasks
StoneyJackson added a commit that referenced this issue Jun 8, 2018
# Version 2.0.0

## Goals

- Avoid unsafe operations (e.g., `git rebase`).
- Introduce some additional best practices (e.g., `git commit -v`; checking what files will be committed before committing, and modifying .gitignore if it's wrong.).
- Reduce the number of different commands required to learn, but possibly require more commands to be issued (e.g., `git branch feature; git checkout feature` instead of `git checkout -b feature`; it might seem like the latter is easier, but then you must know the purpose of -b, and when to leave it off).
- Rely on more external resources for instructions and provide more links to other resources.

## To-do

- [x] Create contributor guide
- [x] Create maintainer guide
- [x] Delete old reference
- [x] Rewrite activity
- [x] Link activity to steps in contributor guide.
- [x] Link activity to steps in maintainer guide.
- [x] Rewrite presentation.pptx
- [x] Update README
- [x] Add license to each file
- [x] Address feedback
- [x] Tag master as v1.0.0

## Issues

- Closes #25 because they are now asked to add a license
- Closes #22 because reflection subsections are added to each section
- Closes #21 because there are now different guides for different roles
- Closes #24 because <MY_URL> and <THEIR_URL> are gone; although folks could still get confused by all caps placeholders even though they are explained at the beginning of the guide.
- Closes #18 because no paths are given
- Closes #20 because I gave a new guess to the time requirements.
- Closes #23 because there are now each section ends with reflection questions which are times for group discussions.
- Closes #31 
- Closes #30 
- Closes #29
- Closes #32
- Closes #33 
- Closes #34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants