Giters

Dangoz / honeydew

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

This is a game exercise for two players (or more?). One player will be designated as "the senior", the other as "the junior".

Advice

Several of the steps ask you to be a bit creative, to come up with something that makes sense. You can phone it in if you want, I guess, but I think you'll get more benefit if you try to figure out what might be the right thing to do in a real job. I mean, maybe you get it right, maybe you get it wrong, but school is a good time to start getting your brain moving along the right lines.

Steps

  1. SENIOR makes a copy of this repository that is not a fork of mine. Do this by cloning and then pushing the clone to github.

  2. SENIOR creates a GitHub Project in this repository. Populate at least 3 columns. Make them realistic examples of things that might belong in a software development project. Google for advice if you need to. Do at least one thing with Project automation (i.e. at least one difference from the default). Think about what might be useful.

  3. SENIOR creates an Issue. Maybe it's a fix. Maybe it's a new rule. Maybe it involves adding some new features/content/etc. The Issue should make sense, and be specific about what the purpose is, but be vague about the details of implementation. Try to write a good Issue. The SENIOR should also make sure this Issue is connected to their Project from step 2, and put that Issue in a column, and all that jazz.

  4. Now the JUNIOR can get involved. First they're gonna Fork the senior's repo. And clone it, I suppose.

  5. The JUNIOR will, in a branch, attempt to resolve the senior's issue. But get it wrong, on purpose, please! (but don't tell the senior what you did wrong on purpose, don't spoil the fun). So yeah, do it, like, half-right. Then, try to write a really nice commit message. What would you want to know about this commit, if you were reviewing it?

  6. After the JUNIOR finishes that attempt, they need to push it (of course), and then make a Pull Request, to the master/main branch of their senior's repo. Make sure to tag the senior in a comment to get their attention! You probably can't assign it to them, alas. (PS: AFTER you tag them, you could also message them in Discord or send a messenger pigeon or whatever).

  7. The SENIOR will now take a look at the PR. Look at the diff. And..... rejeeccctttt ittttttttt, ahahahahahah. Find at least one reason. See if you can guess what the junior got wrong on purpose. If not (or if you disagree with them and you think they got it all right), no worry, just make something else up. Be unfair if you have to, that's okay. Your junior is an adult, they can handle it. Anyway, give them feedback in the PR comments, and assign it back to them.

  8. JUNIOR, that jerkass the senior has rejected your PR. What a jerkass. Anyway, I guess we can either fix it or give up, adn giving up leads to unemployment. So, let's fix it. Fix it, push, and make sure the PR gets the update. Honestly, I don't think I've ever done this, so I dunno how to do it. That's pretty embarassing, tbh, so hopefully one of you will show me.

  9. Dear SENIOR, it's tempting to just jerk the junior around forever with change requests, but let's accept their change, and merge it. This should hopefully trigger some automation in the Project, by the way, due to step (3), unless that automation already happened at some other step?

Some More Steps

  1. Back in Step 2 I said you, the SENIOR, should play with the Project Automation. We're going to get more specific. First, make sure you have some kind of column for new things. It could be called Triage, or Newcomers, or Nursery, or something like that. Make sure it has the Project Automation preset for To Do, and that Newly Added issues AND PRs will go here.

  2. Also, SENIOR, make sure that there's a column like Completed or Graveyard or EndzoneTouchdown or something like that, with the Project Automation preset for Done, with all the checkboxes checked.

  3. Let's try most of those things. It's time for the JUNIOR to make a novel Issue. Gotta amuse yourself by coming up with some dumb issue request. :)

  4. Look, SENIOR, a new Issue! Oh, I love those! At least it's properly organized in your Project board. Make sure that it is, in fact, auto-populated into your Projects board! Take a screenshot of the Projects board, so you have something to hand in later. Write a little message into the Issue, saying "I'd love a PR to solve this". Can you assign it back to the person who requested it? If you can, do. And move it out of the ToDo column of your Project (maybe there's a "current sprint" column, or a "stuff I gave to the junior", or something).

  5. The JUNIOR can now do the "implementation" work. In particular, Junior, when you make a commit to "solve" this, you will write "Resolves #X" in the commit message (ideally not in the first line). Figure out what the correct number is for X. The goal is that when your issue is merged, it'll close the Issue you created.

  6. The JUNIOR can also make a PR.

  7. When the PR is ready, the SENIOR should accept it, and merge it.

  8. SENIOR, verify that this Closes this Issue (because of the integration between Git and Issues, and the "Resolves #X" in the commit message), and that this also moves the Projects card over (because of the integration in step 12). Take a screenshot.

  9. I guess I should make you submit SOMETHING, right. Well, how about the two screenshots of the Projects board: one early in step 14, one at the end of step 18.

About