updates based on the forked version that was delivered for week 1 of FAC10

[jsms90]

Hey @NataliaLKB

I'm currently sorting out the location of all the morning challenges & workshops that are in the FAC curriculum. So I've raised some issues on this repo retrospectively & I'm submitting one giant PR, from the forked version that's currently being used in master-reference.

I know it's very short notice, but it would be great if you had a chance to look over this, and hopefully merge, before FAC10 start their curriculum planning on Tuesday 🙏

So, this PR will:

• edit a few small typos
  fixes a few typos #76
• remove content that is now assumed knowledge for FAC students, based on their pre-reqs & precourse material & moved the "github flow" section to the beginning
  fixes update content based on the current pre-reqs & precourse #75
• remove mention of this being separated into 2 tutorials - both are now delivered in week 1 of the curriculum
  fixes Condense 2 tutorials into 1 #74

---

Note: As you can see from the latest commits, this is no longer quite the same as the forked version that I delivered for FAC10. I will make sure this is explained to the week 1 mentors during the curriculum planning session. But in case you're interested:

• I have reintroduced the "Committing" section - I mistakenly believed this content was covered in lesson 1 of Udacity's git & github course (in the precourse), but Udacity doesn't actually go over this until lesson 2 & it is really good to tell them these "best practices" from the beginning
• removed any mention of contacting me about issues
• expanded on the github flow section - I integrated the branches bit from your original Terminology section (removed) & the Multiple people working on the same files bit from your original Why Version Control section (removed)

[NataliaLKB]

💯

[NataliaLKB]

Most developers use git as their version control system

Should be a link maybe to here: https://rhodecode.com/insights/version-control-systems-2016

[NataliaLKB]

resources section

Should link to the resource section

[jsms90]

Nice link!

[NataliaLKB]

A couple comments, but great work! Thanks for the PR

[NataliaLKB]

@jsms90 I should have given you merge access now. I know that at Founders & Coders usually you have someone else merge your PRs (at the Guardian you merge your own when its been approved).

For this case please merge as you see fit as the only comments I had were small and I know you need to have this for tomorrow so if you don't have time to fulfill the comments then don't worry about it.

[NataliaLKB]

Great! Merging now

[jsms90]

❤️ Thanks so so much. I know that was super short notice.

...Could I maybe ask another favour? 😅

I'm using this issue to help FAC10 & FACN1 in their curriculum planning, by defining the role of the original authors of our curriculum's material. Specifically authors' desires around who owns and who maintains the workshops they have created.

I'm sure that I already know which option you would pick, but would rather not choose for you.

I would very much appreciate it if you have the time to look at this flowchart, which should help you pick Option 1, 2 or 3, and then edit this comment to reflect that decision?

🙏 🙏 🙏

[NataliaLKB]

Done!

Though, all open source is open to the communities that use them so it seems to reason that all of them would accept contributions. Not sure what the point of defining options 1, 2 or 3 as the only real different is where a repo lives.

Just my thoughts. You don't have to listen to me (I am big on saving time and not creating more work that doesn't seem necessary)

[jsms90]

Absolutely!! I do completely see your point. This is exactly the discussion that has been happening in this issue. But it's long 😅 so I'll summarise!

I was originally suggesting only option 2, for the reasons outlined at the top of that issue. But I agree that it seems unnecessary to take the ownership of repos away from people, particularly if the original author is happy to actively maintain it.

I think my suggestion of giving up ownership may have upset some people. I can understand why. And it would actually be really cool to encourage everyone who goes through FAC to be creating and sharing their own open source resources. Hence the options.

But there is still a need for option 2. Not everyone who is happy to create material for FAC necessarily wants to be expected to then continue to maintain it forever more. Certainly not as actively as FAC will soon be requiring of people. It's very time consuming and some have already chosen option 1. I also know of occasions when repo owners have been less than welcoming/helpful to students who raise issues, which then puts students off from raising more issue in future.

As for option 2, there is a difference of opinion amongst course coordinators as to whether the workshops should even be in separate repos at all. Instead, they would live in a folder in the master-reference repo. If that were to happen, then option 1 and 2 are essentially the 2 choices that someone can choose.

It's just not very simple 😅

[NataliaLKB]

So typically in the open source things I have been involved with basically the "rules" have been:

1. Raise issue.
2. You raise the PR changing the thing as well unless the maintainer has time and has specifically said they are doing it
3. Maintainer approves and merges PR

OR

1. You raise issue
2. The maintainer decides they don't want that change in their repo
3. You fork it and make the change in your forked version always giving credit to the beginning (you always try to contribute first as this second option is not ideal)

Suggestion two without discussing it first with the maintainer is simply not respectful. I would imagine thats where some of the issues with it would come from. Obviously if there was a discussion first and it was agreed then its completely fine!

In regards to this git tutorial, it was made ages ago for Founders & Coders. It was a lot of work so I would prefer it stay on my account and people can contribute as they see fit by making PRs. I also give the link out to other groups I am involved with all the time and even some of my co-workers have used it. If someone wants to make a completely new tutorial for Founders & Coders, be my guest!

Does that make sense?

[NataliaLKB]

Instead, they would live in a folder in the master-reference repo

I wouldn't like this. The reason why is because I would want to expose students to the idea of using other people's repos and projects from the beginning. And showing explicitly how much an alumni can contribute. Open source is great and it would be awesome to just keep sending that message.

[NataliaLKB]

Anyway, just my opinions so really do feel free to ignore me!

[jsms90]

Are you kidding? I'm hardly interested in ignoring you 😉 I'm desperate for us to have these conversations. I think they are necessary, especially in an organisation that's trying to make something that's open source. Even more so because a project like the master-reference is bound to become very big very quickly. I want to involve as many people as possible in conversations around ownership because I think it's pretty important that we get it right. Otherwise we aren't creating something that serves our community.

If it had been up to me, I would clearly have made a decision that wasn't right for everyone, because I hadn't thought of all the angles. But that's the benefit of having a community around you, and not doing things by yourself 🎉

---

So yeah, what you said above sounds like what I understand of the process. But:

2. You raise the PR changing the thing as well unless the maintainer has time and has specifically said they are doing it

If you've not already been added as a collaborator of the repo, you can only make that PR in the first place by having forked it first. In which case, there is very little difference between option 1 and 2. It just depends on when you first hear back from the author.

As I understand it, that is (part of) why DWYL's contributing process specifies that you should wait for your issue to be responded to, before you start completing the work.

[NataliaLKB]

If you've not already been added as a collaborator of the repo, you can only make that PR in the first place by having forked it first. In which case, there is very little difference between option 1 and 2. It just depends on when you first hear back from the author.

I do think thats a big difference 😅 !

As I understand it, that is (part of) why DWYL's contributing process specifies that you should wait for your issue to be responded to, before you start completing the work.

This is always a sensible thing to do! But it doesn't exclude you making the PR. It just means usually there is a discussion first 💯

Anyway fun conversations! Thanks for instigating @jsms90 👍 😄

[jsms90]

I do think thats a big difference

...huh?

What I meant to say was that, if the person raising the issue doesn't need to wait until the author has responded before they fork & PR, then that person's workflow is:

1. Raise the issue
2. Fork the repo
3. Make the changes
4. Submit the PR

If you start work immediately, you're very very unlikely to get a response from the author first. So option 2 is unlikely to happen in that order. As you said, if the author comes back to you afterwards and says they don't want your change, then you can speak to them about whether they would be ok with you keeping your altered version on your profile & using it. But at that point the fork already exists.

So is it not always advisable to wait for the author's response before you start work? (Genuine question. My experience with this is very limited.)

Anyway, none of this even remotely describes what I did with your repo in week 1 of FAC10 because I didn't even raise an issue. Pretty much ruining any sense of a collaborative process from the start 😓