Docs: The purpose and future of CONTRIBUTING.md after migration?

[pbodnar]

While it is great that finally some guidelines for the new GitHub-style contributions finally arise, I think I have found some issues or say unclear stuff:

1. Is it that this new docs should replace https://wiki.eclipse.org/Platform/How_to_Contribute in the near future? If so, shouldn't it be made explicit? It is fine that dfc5400 added a link to that wiki page, yet it is clear that page already contains some duplicated & not-up-to-date information right now. So maybe it is also time edit that page - add some deprecation note and link to the new docs here?
2. The Project description part de-facto duplicates the paragraph from the main README.md (READMEs actually, see Docs: Deduplicate information in README.md vs. in profile/README.md? #29) - again, I'm not sure if this is easily maintainable / comprehensible for readers (potential contributors!).
3. IMHO some important differences in the new way of contributing are not described yet. There is also no remark of that some migration from Gerrit & Bugzilla to GiHub PRs & issues has happened and how to cope with that (I only found a wiki page and a blog post on this topic).
   • Namely, I think it would be good to clarify the recommended Git(Hub) workflow for contributors regarding synchronizing their changes with the master (main) branch and resolving potential conflicts before their PR can be merged. I guess that with Gerrit workflow, it was not possible / didn't make much sense to have multiple commits and then squashing them at the contributor side, or to merge the main branch to the contributor's one (instead of doing a rebase, which is probably preferred as it keeps the history linear - simpler to read)...
   • Next, do the commit messages still have a line limit, or not? Some resources like this limit just the 1st line (to 72 characters), for example. (and was this ever actually enforced? I'm not a big fan of strict limits here myself.)
4. When at it, don't you plan to cover also some other topics which often cause confusion, like the Code Freeze Period (see for example the recent /Improve verifyFreezePeriod workflow eclipse.platform.releng.aggregator#272)?

I hope you guys get my point, it is all about making it easier for both the old & new contributors to get quickly on board & having a smooth workflow for both the contributors and the committers. Most sane companies have got 1 carefully-maintained "source of truth" for this very basic stuff like setting up a dev environment or committing to VCS - why couldn't Eclipse (Platform) have the same? :)

(See for example eclipse-platform/eclipse.platform.ui/pull/12 where I cope with some of the stuff mentioned above.)