I'm missing trivial plan / workflow / guidelines related to the changed way to contribute.
In the end, nothing is changed except that people should submit PRs instead of Gerrit reviews. Then it's up to committers to take care of validating the change as usual. CI and other tools will shine in and add their votes as they do with Gerrit.
Shouldn't be there some? or we just let the things "flow" and see if that will be enough, because we are "standing on the giant's shoulders"?
I think the later is the most realistic.
Here is the very first example where a policy should exist IMHO, it was the first thing I've stumbled upon looking on a new repo in git:
See, this was is not anticipated, so having a policy beforehand at that stage wouldn't have covered it either. So letting this flow and reacting to them seems best.
Surely we don't want that our git history contains some vendor specific "committers"?
What matters is more the Author in term of IP. I don't see it as a particular issue that a commit states it has been merged by GitHub, although it's indeed not very useful.
E.g. should anyone "fork" and create PR's from own fork or "clone" the main repo and create PR's from branches to master using main repo clone?
Both is possible, but shouldn't there be a guideline?
This is documented in
https://docs.github.com/en/get-started/quickstart/fork-a-repo . FWIW, this is nowhere documented in other GitHub projects I work with (and there are dozens of them), and everyone surprisingly handle things very well, as suggested by GitHub and as desired by the projects. I think the desire for more guidelines here is more caused by some fear or changes and lack of habits with GitHub, but everything is in place at GitHub to make people do things well, and eventually, Platform contributors will also be successful here without requiring an extra layer of policies or guidelines.
I'm not against someone adding guidelines, but I'm advocating that it's not really necessary and thus investing in them wouldn't much profitable.
