RyanColl / Jeremys-dumb-honeydo

0 stars 0 forks source link

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?