feat: Add "Effective Communication and Collaboration" chapter

[adiati98]

Description

This PR adds the Effective Communication and Collaboration section.

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI
• 📦 Chore (Release)
• ⏩ Revert

Related Tickets & Documents

Closes #11

Mobile & Desktop Screenshots/Recordings

Steps to QA

Added to documentation?

• 📜 README.md
• 📓 docs.opensauced.pizza
• 🍕 dev.to/opensauced
• 📕 storybook
• 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?

[optional] What gif best describes this PR or how it makes you feel?

[adiati98]

@BekahHW I have some questions regarding to the subsections on the issue:

1. Providing Constructive Feedback and fostering a positive community culture

   • We touched this a little bit in the Effective Code Reviews subsections of Issues & Pull Requests. Do we still want to talk about it here too?
   • Fostering a positive community culture: would it be better to have this in the "Building and Nurturing a Community" section?

2. Creating boundaries

   I feel like creating/communicating boundaries is a part of managing expectations. So, we can make it part of "Managing Expectations" section (after Timeline) instead of making a new section. Any thoughts?

   maintainer-intro-course/effective-communication.md

   Lines 91 to 111 in f76c2c8

   	### Managing Expectations
   	The earlier you let contributors know what they can expect from you and what you expect from them, the better. Setting and managing expectations is the key to smooth contributions and project management.
   	Here are some ways to help you manage expectations:
   	- **Small issues**:
   	Just like maintainers, most open source contributors are volunteers. They are not required to, but they help you fix and enhance your project in their spare time. So you can't expect them to work on their issues promptly like a regular employee. With this expectation, you can, for example, break your issues into several small ones to prevent them from taking a long time to work on an issue.
   	- **Styling guide**
   	You might prefer contributors to add a prefix to issue, pull request titles, and their commit messages. Or you might select particular Markdown rules for your project. Every project has its own convention. Don't expect your contributors to know what to do when contributing to your project. Consider communicating this in a clear guide they must follow.
   	- **Support**
   	What kind of support can you provide, and where can they reach you? Think of answering questions, pair programming, or office hours, for example, on Discord. To inform this, you can add a section in your README or Contributing Guide.
   	- **Timeline**
   	You can let your contributors know how long they can expect you to review a pull request or to answer their questions. Inform them if you, for example, won't be available on weekends or after working hours.

TIA! 😄

[BekahHW]

@adiati98 I think all of your comments above are accurate. We don't want to repeat ourselves so your approach to where they should go is the one we should take.

[BekahHW]

This is great. I think the end is especially wonderful and does a good job applying the tips. I have some minor things throughout, but I'm happy with how this turned out! Thanks for putting it together.

[jdwilkin4]

Looks good.
left a few comments

[jdwilkin4]

This will probably need to be a separate PR but there are inconsistencies on how we are treating the word README.

The intro file and this file have README without backticks

the issues and prs file uses both README.md and README in backticks

There are also inconsistencies between whether to include the .md for file names like README, CONTRIBUTING and SECURITY.

we will need to open a new issue for that resolve it for all existing files

[adiati98]

From this, I also checked our intro to OSS course. There is no consistency too there. We have:

• README
• README file
• README.md
• a few README.md (without backticks)

As our courses would be massively used by GitHub users, for terms that related with GitHub, I think it would make sense to follow their style:

README

• README when talking about README in general.
• README file instead of README.md when referring to the file.

Here is an example on their docs.

CONTRIBUTING

• contributing / contribution guidelines (all lower case) to refer the guidelines in general.
• CONTRIBUTING file when referring to CONTRIBUTING.md.

Here is the example in their docs.

Would love to have yours and @BekahHW thoughts on this.

[BekahHW]

@adiati98 I think going with the GH style is the right move.

[adiati98]

I'll leave this unresolved for our reference. 👍

[jdwilkin4]

After the first sentence would work.

feat: add new feature for user authentication

https://www.conventionalcommits.org/en/v1.0.0/

[BekahHW]

@adiati98 all good to merge 🎉