[elbe-devel] [PATCH v1] CONTRIBUTE: Add documentation

[Viraj Shah]

* Add initial documentation for contribution guideline.

Signed-off-by: Viraj Shah <viraj.shah at linutronix.de>
---
 CONTRIBUTE | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 CONTRIBUTE

diff --git a/CONTRIBUTE b/CONTRIBUTE
new file mode 100644
index 000000000..0a8168f54
--- /dev/null
+++ b/CONTRIBUTE
@@ -0,0 +1,72 @@
+CONTRIBUTING
+============
+Contributions from everyone are welcome. Please follow the guidelines when
+filing a Github issue or sending the development patches.
+
+Filing Issues
+-------------
+- So far, Github issues are used to track bugs and feature requests.
+- Bugs are tracked from the latest version of released Elbe. It is still
+  recommended to test the master branch of github-elbe(elbe-mainline)
+  if the bug still persists there. So, please validate the issue with
+  master branch of elbe or atleast the latest version of elbe release.
+- When filing a feature request, please check in the master branch if
+  a similar feature is already available.
+- Give reproducing steps in detail for the issues. In the best case, having
+  an xml file would be good.
+- For a fail build, please give the exact error message.
+  In the best case, having a log file would be good.
+
+Submitting Patches
+------------------
+
+Before:
+~~~~~~~
+
+- We tend to follow the linux-kernel standards while accepting the patches.
+  So, please go through [1] before sending the patches.
+
+- Please describe the changes in the commit message. If it is a series of
+  patches, please consider explaining the change in the cover letter of the patch
+
+- One of the standard methods for generating a series of patches with a cover-letter
+  is using "git format-patch" tool. Also, "git send-email" tool can be used to send
+  a patch.
+
+- We tend to use the kernel coding style as much as possible for this project.
+  So, please go through [2] before sending the patches.
+
+- Please check your patches using checkpatch.pl tool from the linux scripts
+  repo. This will help both developer and reviewer in knowing the obvious style
+  errors. And consider having the patches checked using codespell linux package
+  to see the obvious typos.
+
+
+[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html
+[2] https://www.kernel.org/doc/html/latest/process/coding-style.html
+
+After:
+~~~~~~
+
+- Please be patient after submitting patches. Sometimes, maintainers are
+  working on multiple projects, so they might not find time to reply immediately.
+  Please give them a gracious time of 2 weeks before pinging the mailing list
+  about the status of the patch.
+
+Developer's guide
+-----------------
+- To retrieve the failed build artifacts after a failed build, please use
+  "elbe control get_file" tool. If that doesn't work for some reason, user
+  can dive into initvm using "elbe initvm attach", user id and password are
+  "root". Change directory to the project and scp the files to host. Please
+  note that port no. 5022 needs to be used for the ssh pipe.
+
+- Because we are developing the python code here, whitespace and tabs are
+  sensitive topics. Especially when it is difficult to detect because program
+  runs in initvm and development is done in host computer. Before testing the
+  program in initvm and a sending patch, run the program using python3 simply on
+  host to check for the indentation errors. That would save time for further
+  debugging.
+
+- To print the debugs, feel free to use "logging.info" tool from elbe.
+
-- 
2.30.2