Yes yes, I'm breaking the guideine I just added. But I figure this is probably a good way to delineate README updates from other changes. So any changes to the README can be added to this branch moving forward, please don't delete this one.
To clarify the reasoning behind this, not creating new branches on the main repo keeps things relatively simple, otherwise you end up with several branches for minor changes because of the review restriction. Just do all your editing on your own fork and merge later. The review process (and please make sure you actually request a reviewer) makes sure we can all maintain code integrity, which is necessary on a collaborative project. I'm not doing this to be difficult, I promise.
Also, please note that the restrictions only apply to the master branch, so if it becomes absolutely necessary to move away from this community sourced model, you can always merge all the branches into a single branch on a new repo.
Yes yes, I'm breaking the guideine I just added. But I figure this is probably a good way to delineate README updates from other changes. So any changes to the README can be added to this branch moving forward, please don't delete this one.
To clarify the reasoning behind this, not creating new branches on the main repo keeps things relatively simple, otherwise you end up with several branches for minor changes because of the review restriction. Just do all your editing on your own fork and merge later. The review process (and please make sure you actually request a reviewer) makes sure we can all maintain code integrity, which is necessary on a collaborative project. I'm not doing this to be difficult, I promise.
Also, please note that the restrictions only apply to the master branch, so if it becomes absolutely necessary to move away from this community sourced model, you can always merge all the branches into a single branch on a new repo.