Unverified Commit 6cbf6961 authored by Gabriel Engel's avatar Gabriel Engel Committed by gitbook-bot
Browse files

GitBook: [rafaelblink-patch-1] 144 pages modified

parent 9b3bb81d
This diff is collapsed.
description: >-
On this page, we're detailing how to optimize meetings in an all-remote
# Meetings
## Control your calendar
Reserve blocks of time to do focused work
Create meeting-free days every week
Just say no or delegate
Configure a 25 minutes default meeting duration
Define speedy meetings to have 5/10 minutes intervals
{% page-ref page="blocking-calendar-slots-and-meeting-free-day.md" %}
## Respect others' calendars
Always confirm if you are attending or not
Read the agenda and materials sent out in advance
Join the meeting on time
## Host good meetings
Prepare an agenda
Avoid the status meetings
Invite only the people who need to attend \(mark people as optional\)
Start and end on time
Don’t rehash materials sent out in advance
Send out a summary of the next steps
### Organizing recurrent meetings
Schedule recurring meetings to the beginnig of the week
{% page-ref page="recurring-meetings.md" %}
## References
{% embed url="https://sterlingmiller2014.wordpress.com/2019/09/25/ten-things-escaping-meeting-hell/" caption="" %}
{% embed url="https://hbr.org/2015/03/how-to-design-an-agenda-for-an-effective-meeting" caption="" %}
{% embed url="https://unito.io/blog/running-effective-meetings-tips/" caption="" %}
description: Guidelines on blocking calendar slots and setting meeting-free Thursdays.
# Blocking Calendar Slots and Meeting Free Day
## **Objective**
We highly encourage you to reserve slots on your calendar and have Thursday as a meeting-free day. This is focused on reducing the context-switching of the day-to-day activities and allows you to focus on critical items.
Please note we trust each Rocketeers' common sense on making the best use of guidelines presented here.
Having said this, the purpose of this page is to share general guidelines on these calendar slot blockers.
## **General Guidelines**
### **1. Blocking your calendar**
#### **1.1. Out-of-office**
In case you are setting slots of time on your calendar for unavailable periods \(e.g. take kids to school, doctor appointments, etc\) create an event for the given period using the **Out of Office** type of event.
#### **1.2. Focused individual work**
In case you are setting slots of time on your calendar for focused individual work, place an event calendar entry on your agenda starting with the title **Reserved** or **Blocked** and set its duration.
**Blocked** periods should never be used by others unless it's an emergency and no other slot is possible for the situation. When it happens it's important to talk to the person and ask permission to use the blocked slot.
**Reserved** periods can be used for meetings then no other available time is possible to be used, it indicates non-preferable periods for meetings in order to concentrate them in other moments but can be used for **non-recurrent** meetings if necessary \(e.g. recruiting meeting, training session, etc\).
### **2. Meeting-Free Thursdays**
For meeting-free Thursdays set a public **Out of Office** calendar entry for a **full day** starting on any given Thursday.
{% hint style="info" %}
Please note at this point this is being used only by **Engineering Area**.
{% endhint %}
You can set it to automatically decline meetings and the automatic message `Auto-Declined. Thursdays are Meeting-Free Days. See handbook for more details: https://go.rocket.chat/i/meeting-free-thursdays`
description: >-
Guidelines on recurring meetings and responsibilities for the different
parties involved as a way to take the most of them.
# Recurring Meetings
## Objective: <a id="docs-internal-guid-1ad054d7-7fff-9150-80e8-fa41451af442"></a>
We highly encourage you to use asynchronous communication and schedule meetings only if really necessary.
Also, note that [on this page](https://handbook.rocket.chat/company/our-culture/meetings) you’ll find how to optimize meetings in an all-remote environment.
Having said this, the purpose of this page is to share general guidelines on recurring meetings and responsibilities for the different parties involved as a way to take the most of them.
As you go through this document note that being responsible for items does not mean having to do them, but being accountable for the items mentioned.
## I - General Guidelines:
Below is a list of general guidelines for recurring meetings as a way to clarify expectations and generate alignment on Rocket.Chat recurring meetings.
### 1.Recurring meetings
Any meeting that happens with a regular frequency, consistent dynamic and where focus is on sharing information & generating alignment is considered a recurring meeting.
#### 1.1.Scheduling Recurring meetings:
Unless stated otherwise recurring meetings are to be scheduled on Tuesdays. If for any reason that is not possible, the meeting should be scheduled for Monday. If Tuesdays and Mondays are not available, meetings can be scheduled for Wednesdays.
Note that this is a guideline so that we make time and focus for recurring meetings while still allowing time on the week available for mission oriented meetings and other topics.
Agenda should be shared with all participants prior to meeting.
Participants list and meeting length should be set considering the shared agenda.
#### 1.2.Host Responsibilities:
Unless stated otherwise the host for a meeting is responsible for sharing the meeting agenda, setting the length and is expected to facilitate the meeting.
In case a new member is added to a recurring meeting, the host is responsible for sharing meeting dynamics.
#### 1.3.Participant Responsibilities:
Participants are expected to always respond to the meeting invites with a participation status within reasonable time prior to meeting.
If attending, participants should cover their views as applicable.
If not attending or partially attending, participants should communicate to the meeting host or any other confirmed participant in advance.
## II - Team Recurring Meetings:
Below are a couple team recurring meetings and information related to them.
### 1.One on one meetings \(1:1\):
Meeting between any 2 people \(normally consisting of a supervisor and a direct subordinate\) focused on building relationships, exchanging information, and addressing general questions & concerns \(career, technical or process related\).
Meeting is focused on the subordinate and ways to leverage subordinate potential.
In case 1:1 is not between subordinate and supervisor, please refer to general guidelines \(section I-1.2 and I-1.3\)
#### 1.1.Scheduling 1:1s:
1:1 meetings should be scheduled for Monday or Tuesdays as a way to keep all personnel available for mission oriented meetings and other topics during the other week days.
They should be scheduled for interactions where 2 people have a high interest in exchanging information on a topic or process that is not limited to an ah hoc situation.
Time on schedule should be enough to cover the topics for the meeting and can be agreed upon by the parties involved. Recommend 1 hours duration for the 1st and subsequent times can take the development of the 1st into consideration.
#### 1.2.Periodicity:
The periodicity should be agreed upon by the parties involved during the 1st 1:1 and can be changed at any point based on understanding from people involved.
Generally speaking 1:1 cycle should be for any period between 1 week and 1 month.
Highly recommend weekly 1:1s with any new subordinate during the initial 2 months or where there is a need for a tight alignment; for other situations bi-weekly or monthly should be considered.
#### 1.3.Subordinate Responsibilities:
The subordinate is responsible for proposing agenda, providing information, sharing issues & concerns and recording on tools meeting outcomes.
#### 1.4.Supervisor Responsibilities:
The supervisor is responsible for 1:1s to be scheduled, facilitate the meeting, provide mentoring or coaching, sharing information, and following up on items discussed during meetings.
### 2.General Team Meeting:
Meeting for supervisor to share high-level details and relevant information with all subordinates from a given team.
#### 2.1.Scheduling General Team meetings:
General team meetings should be scheduled for Mondays, Tuesdays or Wednesdays.
All team should be invited to the general team meeting.
Duration should be up to 1 hour.
#### 2.2.Periodicity:
General team meeting should be set for once a month or every time there is a relevant enough topic to be covered with the entire team.
#### 2.3.Supervisor Responsibilities:
Supervisor is responsible for general team meeting to be scheduled, planning & sharing meeting agenda and facilitating the meeting. If applicable, the supervisor is also responsible for follow up on meeting outcomes.
#### 2.4.Subordinates Responsibilities:
Subordinates should attend and participate in these meetings as applicable.
description: Please find details on how to report product issues here.
# Reporting Product Issues
To avoid the same product issue being reported in multiple channels, it's important to keep it centralized in one single place. This way, it's possible for the reporter to keep track of the progress and the product team to work on the issue in an organized way.
**To report an issue:**
1. [Check here](https://app.clickup.com/4207297/v/l/6-13517019-1) if the issue has already been reported. If it has, and you don't have anything new to add, keep track of the resolution progress.If it has already been reported and you have something to add, please add it as a comment in the task.
2. In case the issue has not been reported yet, submit your issue using this [form](https://forms.clickup.com/f/40cp1-8977/TD95VMUEGSZHV2IE7A).
## States for an Open Issue:
* **Issue opened:** Awaiting QA verification.
* **Issue confirmed:** QA has confirmed the issue and now it's waiting for impact and workload analysis.
* **Issue analyzed:** Impact and workload have been defined and it is waiting for prioritization.
* **Issue prioritized:** The product manager has already defined the prioritization of the item.
description: The Rocket.Chat Community Team
# Community
A large global open source community, vibrant and engaged, is at the very heart of Rocket.Chat's product-led-growth business strategy. It is the mission of the Community Team to nurture, build, engage and grow this community.
The Community Team is the result of an earnest investment made by Rocket.Chat back into the foundational community that contributed to its success.
Leveraging and learning from the community building work done during the formative years of Rocket.Chat and mixing in modern massive on-line community creation / management ideas and techniques, the team aims to fulfill two major objectives in 2021 and 2022:
* build a growing internal community that embraces and loves our growing external community
* embrace and engage our existing team-collaboration community; build and grow massive on-line communities around new innovation pillars including omnichannel, apps/marketplace, federation and others
We are approaching these goals while scaling together with the rapid company growth internally, and with accelerated community growth externally.
Working with communities at-scale, our approach is necessarily and increasingly data-driven. All our strategic initiatives will have measurable axis with succinct success indicators.
The team structure and cross-disciplinary focus is designed to scale with the growth of both our internal and external communities and their needs while respecting the level of investment in Community.
Currently the team is structured into the following disciplines:
* Community Management
* Developer Evangelism
* Training and Certification
* Deployment and DevOps
Learn about the team that is making this happen:
{% page-ref page="team/" %}
Learn about each of the disciplines in the Community Team:
{% page-ref page="community-management/" %}
{% page-ref page="developer-evangelism.md" %}
{% page-ref page="training-and-certification.md" %}
{% page-ref page="deployment-and-devops.md" %}
# Community Management
In Rocket.Chat, the area of Community Management encompasses the management and sustaining of direct touch-points with the existing community including but not limited to:
* forums.rocket.chat
* Github repositories
* open.rocket.chat \(Open community Rocket.Chat server that we have been operating 24 x 7 since inception\)
* email alias : community@rocket.chat
* other open source communities \(such as Cloudron community, DigitalOcean community, ubuntu snap community, and others\)
* other two way social network or forums \(such as Twitter, Reddit, Stack Overflow, HackerNews, and others\)
Members of the Community Management team assist, listen and respond to the community at these concrete touch-points directly on a daily basis. All Community Management team members need to have a nominal Rocket.Chat specific technical competency, to be confidently interacting with our current community of administrators and users of Rocket.Chat. Community Management team members are supported directly, as they engage the community answering their need and questions by:
* product team \(product managers of various verticals\)
* marketing team \(for public relations, demand generation, and content generation/management\)
* engineering management \(to improve quality of product by expediting bug fixes and expedite resolution/merge of Pull Requests\)
* engineering technology team \(for matters beyond the technical capabilities of the Community Management Team members\)
Throughout the second half of 2021 \(initial formation of the Community Management Team\), several processes in handling the above have been defined and are being refined by the Community Management Team and the cross-disciplinary teams listed above.
These living, evolving, processes are documented below:
{% page-ref page="github-repositories/" %}
{% page-ref page="open.rocket.chat.md" %}
# forums.rocket.chat - Discourse forum
Our forums, located at at [ forums.rocket.chat](https://forums.rocket.chat/) is a touch-point where Rocket.Chat community often visits. It is running on the SaaS platform of the popular [open source Discourse forum](https://www.discourse.org/) project.
For Rocket.Chat, it is a publication platform for long lasting important announcements. For some community members, it is a more traditional and comfortable environment to engage with Rocket.Chat and/or other members of the community.
The Community Team members handle queries on these forums with their individual style and finesse, as the incoming nature of these forum post is often unpredictable and rather eclectic.
All Community Team members are required to show the following in their exchange with community members on the forums:
\* show sincere empathy for the community member
\* behave in a respectful manner in all interactions and replies
\* do not engage in or support "flame" even if it is directly started / incited by a community member
\* be consistent with the current company direction in all public statements
\* seek next level or extended team intervention when in doubt
For certain important planned technical announcement where community reaction is expected to be intense and where more precise team alignment is required when responding -- a process has been defined and being evolved:
{% page-ref page="responding-to-forum-post-major-technical-change-annoucements.md" %}
# Responding to forum post \(Major technical/change annoucements\)
In some cases, when a major technical or change announcement is made, intense community participation and/or reaction is pre-anticipated. To handle these situations in a productive and consistent manner, the Community Management Team has established \(and is evolving\) the following process.
These announcements usually comprise of:
* an official announcement on forums.rocket.chat by CEO / CTO \(or other executives\)
* a detailed technical document, linked to via the announcement, that explore in total technical details the actual change or elements of the announcement
* an Frequently Answered Question document capturing the official answer to the most anticipated and most asked questions
These announcements also usually involve:
* product management team representing the need for change, or the rationale for the implementation
* product engineering team and members for the detailed technical interactions that are often required
* public relations team member to ensure responses are consistent with the voice of the company
* documentation team member to revise the technical document "Live", as well as tweaking the FAQ as more responses are created
* community team member to handle the actual response and to make sure community comments are adequately addressed and technical matter adequately resolved
Responding to forum posts - an evolving process
1. Transcribe : Community team member transcribe the forum post content onto the worksheet \(or Clickup\) to start the workflow
2. Draft Answer - Depending on the nature of the query, different team members should draft the initial answer: \* in-depth technical answer will require product engineering team member \* product feature related answers will require product management team member \* other queries are most likely answerable by community team member directly
3. One voice alignment - member of public relations team will review the draft answer and rewrite / modify to enforce the company one-voice alignment. This step can be done asynchronously depending on the situation. The one voice alignment may require an update of the response in an asynchronous case.
4. Final message tweak - the member answered in 2 can have a final message tweak based on the adjustment in 3.
5. Final approval - this approval before posting should be performed by a product team member.
6. Posting - this is done by a community team member.
7. FAQ edition - documentation team member will review the post to determine if a question should be added to the FAQ
A member of the Community Management Team should own, co-ordinate and run the process during the response period of the announcement.
# Github Repositories
With our current team-chat centric community, our 100+ Github repositories are the primary touch-points.
The Community Management team has established the following processes in handling these repositories.
{% page-ref page="resolution-of-github-pull-requests.md" %}
{% page-ref page="feature-requests-for-product-roadmap-inclusion.md" %}
{% page-ref page="expedite-bug-fixes-to-improve-product-quality-and-reliability.md" %}
# Feature requests for Product Roadmap Inclusion
Our Community has been, and always will be early adopters of our product and its innovative features. As such, feature requests originating from community deserves careful handling and consideration.
This process aims to collect, triage and manage the incoming feature requests from community members and where necessary, champion its conclusion with Product Management team to have them included into the product roadmap\(s0.
1. Community Team member collect community feature requests from the community, typically at one of these key touch-points: \* from Community Advocate meetings \* Github issue \* Github Feature Request repository \* from key community members on open.rocket.chat
2. Community Team member will either: \* encourage and ensure community member creation of Feature Request in the Feature Request repository \* create the feature requests her/himself
# Resolution of Github Pull Requests
Github Pull Requests are code contributions made by our code contributors \(both internal staff and community members\). The objective of this process is to expedite the resolution of Github PRs created by our community of contributors.
Most healthy open source project maintains a queue of PRs waiting to be reviewed and merged. Maintaining this queue at a reasonable length and avoiding heavy backlog from lead community contributors is the main goal of this process.
_The core of this process is asynchronous communication for faster resolutions._
## 1. Track Internally & Externally
A community team member adds him/herself as a reviewer on the PR.
Next the member adds the PR link to [this clickup list](https://app.clickup.com/4207297/v/li/43369911), assigns it to him/herself and adds a due date. This is to avoid any heavy backlog in the future.
## 2. Collision Detection
With each pull request recieved, the assigned team member assesses it to understand whether the PR overlaps with any internal development process \(ongoing/completed/planned\) or not.
Ideally the contributor should communicate and share what they want to work on prior to submitting a PR on our open community server's [dev](https://open.rocket.chat/channel/dev) channel. That way we can drive them to the right direction and avoid any potential overlap.
But in such a huge Open Source project like Rocket.Chat, overlapping PRs are a possibility. To resolve this situation, it is critical to understand with which stage of the internal development pipeline, the community PR crashes.
### Collision Resolution
We value all our contributions, but if a collision happens, generally the staff PRs get precedence over community contributions. Following is a step by step process of what to do at which stage.
* **Planning stage:-** If the community contribution overlaps any pre-planned development, the community PR is put on hold. The community team member then contacts the Product Manager or the Engineering Manager for feature implementations and bug fixes respectively as soon as possible to avoid it reaching any of the next two stages. _Whether the PR will be accepted or not stays inconclusive in the meantime._
* **Ongoing stage:-** If the PR overlaps an internally ongoing development process, the community PR is put on hold indefinitely. It is now upto the community team member to talk to the Engineering Manager or the respective Product Manager for bugs and feature implementations respectively and come up with a resolution. _90% of the time, it is safe to assume that the outside contribution will not be accepted._
* **Completed stage:-** _If the community PR collides with one of our staff PRs, the community contribution is to be politely rejected._
## 3. Review I
The assigned community team member now determines if the PR is immediately resolvable or not. There are two questions to be asked here -
### Is it a feature implementation?
If it is a feature implementation, does it conform to our product roadmap? _If not, the PR should be politely rejected._
If it conforms to our product roadmap, is the implemented feature planned to be EE only? _If so, the PR should be politely rejected._
If the previous two checks are passed - is there any visible overlap? Go to the previous section for an overlap resolution if there is. Otherwise,
1. Assign the task to the respective Product Manager on ClickUp.
2. Set the appropriate squad.
3. Assign the respective squal lead.
Is the feature planned to be implemented in the current release? If so extend the due date by two weeks.
If it is to be implemented some time in the future, extend the due date to sync with the planned timeline.
### Is it a bug fix?
If it is a bug fix, the community team member attempts to review the PR. If possible, he/she approves the PR for public visibility. Furthermore, he/she must also -
1. Assign the task to the Engineering Manager on ClickUp.
2. Set the appropriate squad.
3. Assign the respective squad lead on both ClickUp and GitHub.
4. Extend the due date by two weeks.
## 4. Review II
If the PR gets to this stage, one of the developers from the respective squad reviews the PR one more time for quality check. This review process can take a couple of days to weeks.
## 5. Final Resolution
Once upto satisfaction and if everything checks out, **the PR gets merged**.
description: >-
Grow the number of globally deployed servers by making Rocket.Chat installable
on the widest possible variety of systems everywhere.
# Deployment and DevOps
# Team
Team Members:
* Head of Community: Sing Li
* Community Manager: John Crisp
* Developer Evangelism Manager: Yashovardhan Agrawal
* Training and Certification : Muni Narayan
* Deployment and DevOps Specialist \(SuperTech Rocketeer\) in-training: Debdut Chakraborty
description: A Community + People team production for our beloved internal community
# Rocketeer Certification
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment