More reasonable alternative to forking?

[PavanLuca]

Select Topic Area

Product Feedback

Body

I don't like having to fork a repository just to correct some typos. Since I can only do so (because I don't know how to code) to fix them I have to fork the whole repository, sometimes just to fix a few, or literally 1. In these cases it would be more reasonable to fork a single file, fix it, and make a pull request since the changes are really very limited.

[asdacosta]

Imagine the hassle if you had to navigate and fork different files if you wanted to make a lot of changes too. That will look messy and each file you fork must have a repo, so if you fork a single file from a repo then where will that file be placed in your repositories? GitHub set this convention to help in seamless workflow.

[PavanLuca]

In my idea each file that the user edits would be listed under a title that's the repository containing them and the user can manage them easily. There the user can view their details like the creation date, last edit date and applying actions (like changing notification option, delete the file and send it). The repository owner would receive a notification of the pull request that tells (Username) sent you a pull request, the quick options will be View, Mark as read and Notify me later. Repository owners will see a title per repository that they own with all notifications of pull requests, but if no pull request exists for a repository of theirs the page will contain no title (so there would be a screen like No pull requests for your repositories for now. Maybe later… 😄) while it will list titles for repositories that have at least 1 pull request. Tell me if it wouldn't be better for a repository owner, I don't have any so I don't know how a repository owner handles pull requests matters 😅.