Contribution guidelines; moved .vscode/settings.json to settings.json.example; added extensions.json

[peter-lyons-kehl]

I also have a list of VS Code extensions for Rust development, and general code navigation, that is not documentation/Markdown-specific. Please ping me if you know of a better repo/file to share it.

[abdelhai]

hi Peter, thanks for the PR!
could you please explain more what the PR tries to achieve and the what the extensions do in detail?
also I'm not sure why we should have Rust specific language & extensions in this repo.

[peter-lyons-kehl]

• This PR helps make the source (especially Markdown) formatting more standardized (whatever line length or Markdown standard you choose).
• CONTRIBUTING.md gives short descriptions of the VS extensions, and links. None of them are Rust-specific, and I use all of them (which are the same as the ones I've added to .vscode/extenssions.json) when editing Markdown.
• Current space-docs' Markdown has some lines long 300+ characters. Too much for editing/reviewing. The old open source de-facto standard is 80. I find that often too little, and not using current wide screens (even with two editing columns).
  I believe VS Code (whether with Rewrap, or without) doesn't allow configuring the vertical ruler or wrapping or re-wrapping at different line lengths based on the source code/file type/MIME of the file being edited. Hence a need to pick one line length for all types of files across the whole code base.
  If Deta is interested in Rust, wouldn't it make sense to pick Rust's standard (which is 100 characters) - unless Golang has a different one? Either way, let's choose one.

While on the theme of source code contributions: I'm surprised that Deta uses GIT merging. It adds extra commits to the history. But much worse, if I remember right, it puts the burden of adjusting/fixing conflicts on the person doing the maintenance/merging.

Many large open source projects or companies use rebase instead. That moves the responsibility of solving the conflicts and updating ("rebasing") the PR branch to be up-to-date with main (or wherever it's being rebased on) to the contributor. If a PR is accepted, there is no extra merging commit, and the history is exactly the same on both branches.

It does mean more work for the contributors, and a little bit of learning. They love learning. And that amount of work has to be done by someone anyway. If they're motivated to get their PR accepted, they'll do so - and save Deta team's time.