First-contributions: Add a section in the README for syncing your fork, instead of constantly forking and deleting

[syakubov]

I believe this tutorial is incomplete, and can be made more comprehensive without necessarily becoming too complicated for beginners.

🐞 Problem


The tutorial should include the steps from the following pages:
https://help.github.com/en/articles/configuring-a-remote-for-a-fork
https://help.github.com/en/articles/syncing-a-fork

🎯 Goal


This would be helpful for people who would like to contribute to a project long term instead of just having a first contribution. I think that deleting the fork and forking from master over and over again just to commit small contributions is a waste of time, and could be made more efficient by just working from the initial fork. This is an issue I came across when contributing to my first OSS project.

💡 Possible solutions

Simply update the README with a section for reusing the initial fork and merging changes.

📋 Steps to solve the problem

If people approve of this idea and would like to see it implemented, I don't mind updating it myself and submitting it for review.

[Roshanjossey]

We actually have that section in our additional materials

https://github.com/firstcontributions/first-contributions/blob/master/additional-material/git_workflow_scenarios/keeping-your-fork-synced-with-this-repository.md.

We kept multiple things out of the tutorial because we wanted to keep it small and users can do this in minutes.

I bet it'd help if it had more visibility. Do you have any suggestions in that direction?

[cynolycus]

Hello, Roshan. I'm not the original issue contributor, but as it is my first time stumbling upon this repo, I feel qualified enough to comment.

The only "problem" is that the link to the Additional Resources stands alone and is easily overlooked at a glance. Even a one-line directive advertising how someone new to git can "go on to master more advanced features" or such would be enough to draw some more attention to it.

Perhaps I should make a PR to that effect? :)

[Roshanjossey]

Hi @cynolycus, anybody can comment here.

Thank you for jumping in and submitting the pull request.

We're on the same page that that link needs more attention.

Still, I'd rather us chat about it and decide how we want to change it and how to word it rather than making the changes. For example, in your changes, I don't understand why we have to mention translations there.

[cynolycus]

Hello, Roshan! I may have jumped in prematurely. There is certainly no need to keep the bit about translations, but I thought it may be a good opportunity to mention it.
I apologize, I may have misunderstood when I created the PR, but I saw an option for "Allow edits from maintainers", which I took to mean it would permit you to make any appropriate modifications before merging.

I don't mind removing the piece about translations; what other thoughts do you have about the content or placement of these changes? I wanted to keep the same flow and voice as the rest of the document, so naturally your input is appreciated.

[Roshanjossey]

Hi @cynolycus, please don't apologize. You didn't do anything wrong.

Yes, I can make changes to the pull request before merging or make changes after merging. That is not an issue.

I'm just saying that it's better to discuss the wording in this thread. Not just for me to suggest changes but also for anybody else who might be interested in this to have a look at it and voice their opinions.

Previously, I've found a kind of Diverge -> Converge -> Decide process to come up with good ways to phrase what we want to communicate.

In diverge step, we could come up with different sentences, in converge step, we could compare them and decide on one sentence (maybe by merging ideas from the ones we came up with)