Skip to content
This repository has been archived by the owner on Apr 29, 2024. It is now read-only.

feat: Add "Effective Communication and Collaboration" chapter #25

Merged
merged 31 commits into from
Jan 19, 2024
Merged
Changes from 1 commit
Commits
Show all changes
31 commits
Select commit Hold shift + click to select a range
82662a1
feat: create effective-communication.md
adiati98 Jan 3, 2024
b2cf8ad
feat: add Effective Communication and Collaboration to sidebar
adiati98 Jan 3, 2024
ce86c5f
feat: add chapter 4 to README
adiati98 Jan 3, 2024
800adb3
feat: add intro paragraph
adiati98 Jan 3, 2024
6d46f75
feat: add Project Onboarding section
adiati98 Jan 3, 2024
286b7e8
fix: wording
adiati98 Jan 3, 2024
fde9047
feat: add Regular Communication section
adiati98 Jan 3, 2024
b241aad
add: Effective Communication and Engaging with Contributors sections
adiati98 Jan 5, 2024
9355466
docs: add Managing Expectations section
adiati98 Jan 5, 2024
f76c2c8
Resolve merge conflicts
adiati98 Jan 5, 2024
dfd0730
docs: add Boundaries point to Managing Expectations section
adiati98 Jan 9, 2024
544bba2
docs: add Handling Difficult Situations section
adiati98 Jan 10, 2024
12797d6
docs: improve Regular Communication section
adiati98 Jan 10, 2024
6407f05
docs: improve Managing Expectations section
adiati98 Jan 10, 2024
319a0e7
fix: adjust wording
adiati98 Jan 10, 2024
5d00e2e
Merge branch 'main' of https://github.com/open-sauced/maintainer-intr…
adiati98 Jan 10, 2024
acfc661
fix: apply suggestions and minor wording adjustment
adiati98 Jan 11, 2024
9185e3d
fix: edit Support section
adiati98 Jan 11, 2024
67969c5
docs: add live streams
adiati98 Jan 11, 2024
ec2cdd9
fix: paragraph format in Engaging with Contributors section
adiati98 Jan 11, 2024
f460d8d
fix: add sentences to point Timeline to maintainer powerups chapter
adiati98 Jan 12, 2024
609ec58
Resolve merge conflicts
adiati98 Jan 12, 2024
ad5f684
fix: improve Style Guide section
adiati98 Jan 12, 2024
465c27b
fix: update Chat Service App intro paragraph
adiati98 Jan 15, 2024
fb4f896
fix: change contributing guidelines to all lower case
adiati98 Jan 15, 2024
5451036
fix: rename file to be more descriptive
adiati98 Jan 17, 2024
384c7b4
fix: change link in sidebar.md and README to new file name
adiati98 Jan 17, 2024
e398263
Merge branch 'main' into feat/add-effective-communication
BekahHW Jan 19, 2024
c72418e
fix: change h1
adiati98 Jan 19, 2024
3481bd4
Merge branch 'main' of https://github.com/open-sauced/maintainer-intr…
adiati98 Jan 19, 2024
0eec647
Resolve merge conflicts
adiati98 Jan 19, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
docs: improve Managing Expectations section
  • Loading branch information
adiati98 committed Jan 10, 2024
commit 6407f05a729b85f418c65bb31484010793d5b80b
44 changes: 24 additions & 20 deletions effective-communication.md
Original file line number Diff line number Diff line change
Expand Up @@ -98,45 +98,49 @@ Maintainers are human. Sometimes, when you're tired or having a bad day, a discu

### 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.
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. So, how can you manage and communicate your expectations?

Here are some ways to help you manage expectations:
#### Small Issues

- **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.

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

- **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. So, don't expect your contributors to know what to do when contributing to your project. Consider communicating this in a clear styling guide they must follow.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be useful to share some examples of contributing styles. Maybe an example of conventional commits with a link.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean here adding a sentence after the first one that mention about conventional commits?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After the first sentence would work.

feat: add new feature for user authentication

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


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

- **Support**
What kind of support can you provide for your contributors? Where can they reach you? You can think of these amongst other supports:
adiati98 marked this conversation as resolved.
Show resolved Hide resolved

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.
- Where can contributors ask questions?
- Can you give them support in pair programming when necessary? How can contributors ask for one?
- Will you hold office hours? If so, would it be regular or based on request? Where will it happen, and how will you announce it?

- **Timeline**
You can add a section in your README or Contributing Guide to inform about the support you can give.

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.
#### Timeline

- **Boundaries**
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.
adiati98 marked this conversation as resolved.
Show resolved Hide resolved

As your project grows and gains popularity, it will attract more contributors. Creating and setting clear boundaries becomes essential to prevent you from getting burned out quickly and balance your life.
#### Boundaries

- **Take a Break**
As your project grows and gains popularity, it will attract more contributors. Creating and setting clear boundaries becomes essential to prevent you from getting burned out quickly and balance your life. Here are some ways to create boundaries:

You need to know that it's okay to take time off, step away from your project, and take care of yourself. You can inform your contributors that you will review their pull requests after you return. Here is an example of what you can say:
- **Take a Break**

> "Hey {username}, thank you for your PR. I will take two weeks off starting tomorrow and review this upon my return. You may ask about the status of your PR if I haven't responded to it in the next three weeks."
You need to know that it's okay to take time off, step away from your project, and take care of yourself. You can inform your contributors that you will review their pull requests after you return. Here is an example of what you can say:

When pull requests come during your days off, you can apologize and thank them for their patience after you return. Consider to say something like this:
> "Hey {username}, thank you for your PR. I will take two weeks off starting tomorrow and review this upon my return. You may ask about the status of your PR if I haven't responded to it in the next three weeks."
adiati98 marked this conversation as resolved.
Show resolved Hide resolved

> "Hey {username}, I apologize for the late response, as I just got back from my days off. Thank you for taking on this! I need time to review it and will get back to you soon. I appreciate your patience."
When pull requests come during your days off, you can apologize and thank them for their patience after you return. Consider to say something like this:

- **No Private Message**
> "Hey {username}, I apologize for the late response, as I just got back from my days off. Thank you for taking on this! I need time to review it and will get back to you soon. I appreciate your patience."
adiati98 marked this conversation as resolved.
Show resolved Hide resolved

Another boundary you can set is for contributors not to send you private messages on chat service apps like Discord or social media.
- **No Private Message**

The culture of open source is open communication and transparency. It is best to keep all contributors in the loop by communicating anything related to the project in the open so everyone knows what's happening and what to expect. It will also give you the necessary privacy, separating your project from your personal life.
Another boundary you can set is for contributors not to send you private messages on chat service apps like Discord or social media.

The culture of open source is open communication and transparency. It is best to keep all contributors in the loop by communicating anything related to the project in the open so everyone knows what's happening and what to expect. It will also give you the necessary privacy, separating your project from your personal life.
adiati98 marked this conversation as resolved.
Show resolved Hide resolved

### Handling Difficult Situations

Expand Down