<div class="xblock xblock-public_view xblock-public_view-vertical" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="VerticalStudentView" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="vertical" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@vertical+block@chap-05-seq-02-ver-03" data-request-token="140a0374902b11ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<div class="vert-mod">
<div class="vert vert-0" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-05-seq-02-ver-03-html-01">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-05-seq-02-ver-03-html-01" data-request-token="140a0374902b11ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/chap-05-seq-02-ver-03-html-01.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><p>To be able to communicate effectively with a community, we need to look for the communication channels and process it uses. They are so fundamental to any online community that needs to collaborate, that they are usually discoverable in a few places - from community or developer sections of the projects website; perhaps in a README.md or a CONTRIBUTING.rst file in the repository for the project; sometimes there is a section in the contribution manual or guide outlining the tools to communicate. Finding the tools the community uses and getting them setup is crucial to being a contributing member because open source is all about collaboration with the other individuals in the community. Being able to introduce yourself, ask questions, give and accept feedback are all activities you will need to be able to communicate with the project's community for. </p>
<p>Obviously, every FLOSS community is different and so there are a wide variety of tools they may use to communicate. However, there are two main categories of communication - synchronous and asynchronous. </p>
<p><strong>Synchronous Communication </strong></p>
<p>An easy way of thinking about this kind of communication is simply, 'real time.' It does not have to be face to face to be instantaneous and there are many many tools that are used for this kind of communication. A community might make use of an IRC or Slack network. They might use Matrix or Discord or Rocket.Chat or Zulip. There are so many different chat platforms these days that the options for any community are just about endless. The culture of the community, the ideals they hold (for example, using open source tools to support their open source community), the size and requirements of the community help narrow down the options. Its also possible that different sections of the community primarily use different tools. It's also possible that a community might opt to not have a synchronous way of communicating or be making use of some other community's tools and channels because there is overlap between the communities. </p>
<p>When communicating with a FLOSS community synchronously, its important to be cognizant of the geographic regions the community members you're talking to reside in and be patient. </p>
<p>Aside from synchronous, online communication, many communities have in person events like meetups or conferences. These in person events give communities the opportunity to not only present on features, discuss upcoming work to be done, etc, but also to provide a place for a community to come together and match faces with names. If you have the opportunity and means to attend an event, it can be a very good experience. </p>
<p><strong>Asynchronous Communication</strong></p>
<p>Its not always possible to have instantaneous access to community members - likewise, you might not be constantly available. For communication that is not always immediate, there are asynchronous options like mailing lists and forums. Depending on the community, the time of year, the point in a release schedule, etc the wait times on responses to communications you send these asynchronous ways will vary. </p>
<p>In some communities use of asynchronous communication is encouraged over using synchronous chatting to ensure a higher level of inclusiveness of other timezones. Since a synchronous conversation being had is likely only accessible to half of the world, one half will consistently be left out simply because they are sleeping or just not working; to avoid this exclusion, use of mailing lists and forums gives a more balanced opportunity to reply to a given conversation to all contributors. </p>
<p><strong>Other Information and General Communication Tips</strong></p>
<p>Communication is the most important and yet most difficult part of contributing to any FLOSS community. It doesn't matter if the community is big or small, regional or global, communication with other members is what yields progress for the software. One of the best things we can do when participating in an open source community is to be patient. The reply might not come right away even when we are using a synchronous form of communication. The contributor on the other side of the message might not be using their first language and they need more time to reply; or they might ask questions that we thought were already answered. Whatever the case, patience and kindness will take us a long way, and ensure we are good open source citizen. </p>
<p>Another thing to remember is that we rarely are the only person to ask a particular question. While it might be uncomfortable, asking questions in as public a setting as possible is generally a good idea because there could be another new contributor looking for the same answer. By asking the question in the open, as opposed to a private message or similar, it will help more people. Also, the more open we are, the more people recognize our name, which is good for establishing a presence and building up trust in the community. </p>
<p></p></div></div>
</div>
</div>
</div>
<script type="text/javascript">
(function (require) {
require(['/static/js/dateutil_factory.a28baef97506.js?raw'], function () {
require(['js/dateutil_factory'], function (DateUtilFactory) {
DateUtilFactory.transform('.localized-datetime');
});
});
}).call(this, require || RequireJS.require);
</script>
<script>
function emit_event(message) {
parent.postMessage(message, '*');
}
</script>
</div>
<div class="xblock xblock-public_view xblock-public_view-vertical" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="VerticalStudentView" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="vertical" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@vertical+block@chap-05-seq-02-ver-01" data-request-token="140a0374902b11ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<div class="vert-mod">
<div class="vert vert-0" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-05-seq-02-ver-01-html-01">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-05-seq-02-ver-01-html-01" data-request-token="140a0374902b11ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/chap-05-seq-02-ver-01-html-01.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><p>The <strong>code of conduct</strong> is a document formalizing rules for interactions within a project. </p>
<p>Nowadays most big free software projects and communities have them, while some small self-mediated communities haven't had the need to formalize these rules yet. It is becoming one of the funding steps of a community, and is in particular usually mentioned in the document detailing how to contribute to the project and how to become part of a community.</p>
<p>These codes of conduct define the "explicit" rules for the community, but they don't include all the rules. While they usually describe more of an ideal world, they rarely include practical advice, and some rules remain implicit and are reminded on the moment, eg. around trolling, community interactions, etc.</p>
<p>Additionally, if you never participated in an interest group online, with people that you don't know, it could maybe be a shocking experience in some cases. Be prepared for something that is more fuzzy, more bizarre, than what the theory from the formal code of conduct, or that can be read in books. Joining a community is like joining a new culture - it requires a lot of openness and acceptance, within reason. It's also important to not be a stickler with the rules -- contributing to a community is supposed to be fun.</p>
<h4>Why a code of conduct ?</h4>
<p>Part of the reasons why code of conduct exist is the need to correct for a lack of diversity, which generated bias and discriminatory attitudes towards those not part of the majority. Which is usually white males in their 30s, from Europe and North America, focused mainly on tech and code. If you're not from that group, or not contributing code, it was often implicitly considered that the contribution or the contributor was worthless, and could be treated accordingly. Just like the origin of a contributor should not be a factor of discrimination, the type of contribution should not either: code, documentation or design contributions, for instance, are equally important.</p>
<p>With this new framework, potential contributor will, even before trying to interact, have <em>expectations</em> about how the project treats people and interactions. That the interactions they will have have rules, and that they should follow them as well as expect them to be followed by others. For new contributors, following these rules and respecting other contributors and their time, can only help in getting productive discussions and reviews: being rude or impatient with others is usually a good way to end up ignored, while part of the goal of a contributor is to make others want to respond and collaborate with them.</p>
<h4>Enforcing the code of conduct</h4>
<p>Ideally, the code of conduct is the last resort when everything else did not work. Referring to a code of conduct and respecting it is a useful step, but not sufficient by itself. You know you're doing it right when nobody needs to refer to it, i.e. when the mediation ahead of the rules enforcement is sufficient. Most big communities have a code of conduct, but almost never have to use it. Not to say that open source project communities always follow all the rules: like in all communities, there are tension at times, confrontations, passive-aggressiveness, cliques and disputes, but the code of conduct creates a canvas to keep discussion as civil as possible.</p>
<p>Newcomers to a project can be easy targets for abusive behaviors, so it's important to recognize those situations. Being new to a community, there is a strong incentive to try fit in, and it's harder to know what's exactly accepted behavior or not. As newcomers, we generally want to avoid looking confrontational or problematic, so questioning the behavior of established community members can be difficult -- for fear of getting our questions left unanswered, or our contributions unmerged. When we are the recipient of abuse, there can be a lot of pressure to just comply and go with it.</p>
<p>It's thus important to identify whether there is someone within the community who is going to make sure that people who are a bit hostile or aggressive do not bother newcomers. Having someone handling the type of mediation mentioned above can make a huge difference, and ensures that contributing doesn't become an unpleasant experience.</p>
<p>It's also important to keep in mind that feedback about the atmosphere of a community is a contribution - one of the most difficult ones, actually. It's harder for established members to remember how it feels like to be a newcomer in their community.</p>
<p>And remember that if a community is problematic, <em>walking away is always an option</em>, and a form of feedback by itself.</p>
<p>However, the most likely scenario here is that you will not have to deal with these concepts in your interactions: Most FLOSS communities are welcoming and inclusive, and many people will go into great lengths to explain concepts to new contributors.</p></div></div>
</div>
</div>
</div>
<script type="text/javascript">
(function (require) {
require(['/static/js/dateutil_factory.a28baef97506.js?raw'], function () {
require(['js/dateutil_factory'], function (DateUtilFactory) {
DateUtilFactory.transform('.localized-datetime');
});
});
}).call(this, require || RequireJS.require);
</script>
<script>
function emit_event(message) {
parent.postMessage(message, '*');
}
</script>
</div>
<div class="xblock xblock-public_view xblock-public_view-vertical" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="VerticalStudentView" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="vertical" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@vertical+block@chap-05-seq-02-ver-02" data-request-token="140a0374902b11ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<div class="vert-mod">
<div class="vert vert-0" data-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-05-seq-02-ver-02-html-01">
<div class="xblock xblock-public_view xblock-public_view-html xmodule_display xmodule_HtmlBlock" data-course-id="course-v1:MOOC-FLOSS+101+2021_1" data-init="XBlockToXModuleShim" data-runtime-class="LmsRuntime" data-runtime-version="1" data-block-type="html" data-usage-id="block-v1:MOOC-FLOSS+101+2021_1+type@html+block@chap-05-seq-02-ver-02-html-01" data-request-token="140a0374902b11ee8c631237928d7ffd" data-graded="False" data-has-score="False">
<script type="json/xblock-args" class="xblock-json-init-args">
{"xmodule-type": "HTMLModule"}
</script>
<div class="edit-link-wrapper"><div class="edit-link"><p style="text-align: right;"><a href="https://gitlab.com/-/ide/project/mooc-floss/mooc-floss/edit/master/-/course/html/chap-05-seq-02-ver-02-html-01.html" target="_blank"><i class="fa fa-pencil mr-1"></i> Edit on Gitlab</a></p></div><div class="edit-link-original-content"><p>In addition to behaving nicely, it's important to know how to communicate efficiently with (and within) a project. This involves both the place and time of the communication, and its contents</p>
<h4>Right place, right time</h4>
<p>For asynchronous communication channels like mailing lists, make sure you read some of the <strong>history</strong> to get a grasp of what gets discussed there and the way people get answers. If synchronous communication channels have <strong>logs</strong>, you may also want to go through part of it to make sure you're at the right place for your questions. It will also give you an idea on how people interact, ask questions, etc. </p>
<p>Once you have this idea of the contents of the channel contents, if your plan is to interact, don't stay lurking and participate! A helpful metaphor is that of the party:</p>
<blockquote>
<p>Entering the room and starting blurting anything that comes to your mind immediately, without regard for the others, is unlikely to be appreciated. On the other side, just sitting in a corner the whole evening without talking to anyone wouldn't bring anything good either.</p>
</blockquote>
<p>The most often cited reference on communication in development channels is <a href="http://www.catb.org/~esr/faqs/smart-questions.html" target="[object Object]">How to ask questions the smart way</a>, by Eric S. Raymond. However, this reference is a bit hostile to newcomers, and more accessible resources can be found on Julia Evans blog: <a href="https://jvns.ca/blog/good-questions/" target="[object Object]">How to ask good questions</a>. </p>
<p>The main mistakes people do on chats are the following:</p>
<ul>
<li><em>Don't ask to ask</em>: « Can I ask a question? » is not a good conversation starter: likely no one knows about the entirety of the project, so no one can commit to answer <em>any</em> question you can have, so likely this will get ignored. <em>Yes, you can ask a question</em>.</li>
<li><em>Do your homework</em>: Asking a question when the answer can be found by typing the question in a search engine or by looking at the documentation, can make people who wrote the documentation feel disrespected. They invested time into writing in the FAQ so that people helping others on the chat don't have to repeat themselves.</li>
<li><em>Avoid big chunks of text</em>: If you have error messages to paste, put them in a pastebin and link them.</li>
</ul>
<h4>Additional ressources:</h4>
<ul>
<li><a href="https://producingoss.com/en/setting-tone.html">https://producingoss.com/en/setting-tone.html</a></li>
<li><a href="https://producingoss.com/en/communications.html">https://producingoss.com/en/communications.html</a> - recognize rudeness, setting the tone, avoiding common pitfalls like the smaller the topic, the longer the debate, etc.</li>
<li>
<p><a href="https://datatracker.ietf.org/doc/html/rfc1855">https://datatracker.ietf.org/doc/html/rfc1855</a></p>
</li>
</ul>
<p></p></div></div>
</div>
</div>
</div>
<script type="text/javascript">
(function (require) {
require(['/static/js/dateutil_factory.a28baef97506.js?raw'], function () {
require(['js/dateutil_factory'], function (DateUtilFactory) {
DateUtilFactory.transform('.localized-datetime');
});
});
}).call(this, require || RequireJS.require);
</script>
<script>
function emit_event(message) {
parent.postMessage(message, '*');
}
</script>
</div>