Commits should generally not be made directly to master - only organisation and repository administrators have the ability to, and should avoid doing so if at all possible.
I understand phase 1.2 Skeleton is not started yet, but that’s something we need to come to a consensus on before it does.
Creating a pull request for the main branch and committing to the main branch are not the same. I’m assuming that an external contributor would pull request the master branch but whoever was reviewing it would either change it to the proper branch before committing or an organisation or repo administrator will push it to the master if it’s the best course of action.
Also regarding the Wiki Guidelines, there will be an announcement and review phase soon (next few days). This can (and should) be brought up then, too, unless clarified by this topic.
I’ve updated the CONTRIBUTING document to say pull requests should target development instead. While we haven’t completely finalised the contribution model yet, the usual method for a project like this is to have master as a stable channel - that is, tested, production-ready versions only. The development branch is for active development. Contributors work on features in feature branches (or forks), then once they’re complete they get merged into development and any conflicts or integrations between features get worked out there. This means that versions on development are not always safe for production; once a version has been confirmed working, it can be merged onto master.