[DOC] Improve development guide for better getting started experience

[rohanKanojia]

Component

Development Documentation

Task description

Currently, for a beginner, these documents are sources to get information about the project and how to start developing it:

• https://github.com/crc-org/crc/blob/main/README.adoc
• https://github.com/crc-org/crc/blob/main/developing.adoc

However, I still see some areas of improvement especially for development docs so that onboarding new developers can be made faster. In my opinion, these sections should be added to the development guide:

• Preferred IDE for development, any additional configuration required?
• How to use a development build of CRC?
• How to run CRC in debug mode?
• Style conventions used by the project, how to apply them (IDE configuration)?
• Building the documentation (should be moved from README.adoc to developing.adoc)
• Commit Conventions (Do we use conventional commits?)

I've taken some points from Eclipse JKube Contributing guide. I think we can add these points to improve onboarding time for newcomers.

Acceptance Criteria

• Developer getting started guide is improved by addressing the abovementioned points (subject to change as per discussion)

[gbraad]

I agree we need to update the getting started guide from a development perspective, and I have started to convert some files to markdown (developing.adoc and the wiki), to a new repo. These suggestions will be considered

Preferred IDE for development, any additional configuration required?

I do not think we should 'prefer' an IDE. It is Go, so anything will do. And as on the team, people use Vi, VSCode, Goland, etc. I am more for describing the recommended tools around it, like Go version; how to install. I personally modify the UBI8/9 images to create a development environment that can be remotely used.

Style conventions used by the project, how to apply them (IDE configuration)?

make fmt

Commit Conventions (Do we use conventional commits?)

Gnarly conversation. I think a consensus was reached. But I, especially with the use of Jira, think that we should always refer to an issue in the title and/or description.