michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: Remove communication section.

Browse source 
The communication section is being removed.
The content will be available elswhere.

Change-Id: Idca52a7d3bc2f0607f108d639e2edf931bf99ffd
Signed-off-by: Rodrigo Caballero <rodrigo.caballero.abraham@intel.com>
This commit is contained in:
Rodrigo Caballero 2016-04-15 11:02:15 -05:00 • committed by Anas Nashif
commit 97db3c380f
2 changed files with 0 additions and 87 deletions
Download patch file Download diff file Expand all files Collapse all files

1
doc/collaboration/collaboration.rst
View file

@ -9,4 +9,3 @@ best ways to collaborate with the team. Read them carefully before submitting an
.. toctree::
:maxdepth: 1
communication/communication

86
doc/collaboration/communication/communication.rst
View file

@ -1,86 +0,0 @@
.. _communication:
Communication Tools
###################
Open source is about sharing development information among all contributors
on a given project. Maintainers and contributors have the opportunity to
communicate with each other using open source collaboration tools: the
mailing list, Gerrit and JIRA. We strive to be open about our work with
stakeholders through the community mailing list.
In this spirit, the standard open source community practice is to not send
private feedback through email. Instead, please send feedback to the mailing
list with 'Reply-to-all', and keep the CC list intact. While the mailing list
can be used to hold design discussions, remember to submit all changes using
Gerrit.
The following sections contain information about the communication tools
used with the Zephyr Project.
.. _mailing:
Open Source Mailing List Collaboration Tips
*******************************************
Below are some recommended guidelines for using the Zephyr Project's mailing list.
When submitting feedback and contribution ideas to the listserv, please follow
these guidelines:
* Use the mailing list as much as possible.
* Learn the rules.
* Read the archives when in doubt.
* Choose a meaningful subject line.
* Ask questions and write to the subject matter experts directly and
CC the mailing list.
* Before doing any large-scale code changes, send a design document with
the proposed changes to the mailing list. This will prevent wasted
time implementing a solution that the community may reject.
* Write briefly and to the point, yet give enough context for someone
to respond without re-creating your thought process.
* Be persistent, but measured, if you are not getting a response.
* Write a separate email for each work item. If work items are connected,
explicity state so in each email.
* Don't rehash old issues.
* Reply only when you're offering new information or a new perspective;
avoid "me-too" posts.
* When replying in-line to message that was CC'ed to the list, trim out
unnecessary context between replies and at the end of your message.
* Refrain from using capital letters to emphasize a point.
* Check your line length; keep it under 72-76 characters.
References
**********
* General info:
+ http://linux.sgms-centre.com/misc/netiquette.php
+ http://www.ietf.org/rfc/rfc1855.txt
+ http://www.infradead.org/~dwmw2/email.html
+ http://www.arm.linux.org.uk/mailinglists/etiquette.php#e3
+ http://lifehacker.com/5473859/basic-etiquette-for-email-lists-and-forums
* Why top posting is considered harmful:
+ https://lkml.org/lkml/2005/1/11/111
+ http://www.dickgaughan.co.uk/usenet/guide/faq08-topp.html
+ http://www.mail-archive.com/brin-l@coollist.com/msg00178.html