[elbe-devel] [PATCH v2 1/1] CONTRIBUTE: Add documentation

[Viraj Shah]

* Add initial documentation for contribution guideline.

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

diff --git a/CONTRIBUTE b/CONTRIBUTE
new file mode 100644
index 000000000..9b4218d6b
--- /dev/null
+++ b/CONTRIBUTE
@@ -0,0 +1,61 @@
+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 pylint code analyzer 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.
+
+[1] https://pylint.pycqa.org/en/latest/
+
+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 1 month 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, a user
+  can dive into initvm using "elbe initvm attach", the default user id and
+  password are  "root". The project files would be located in
+  /var/cache/elbe/{PROJECTID}
+
+- 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.
+
+- Use spaces always in the python program. And restrict Makefile for tabs.
-- 
2.30.2